Intent to Extend Experiment: Speculation Rules - Document rules, response header, deliveryType
Jeremy Roman
Contact emails
jbr...@chromium.org, adit...@chromium.org, isab...@google.com, dom...@chromium.org, kenji...@chromium.org
Explainer
https://github.com/WICG/nav-speculation/blob/main/triggers.md
https://github.com/w3c/resource-timing/issues/332
Specification
https://wicg.github.io/nav-speculation/speculation-rules.html
Summary
Three enhancements to preloading, under a combined experiment:
An extension to speculation rules syntax that lets the browser obtain URLs for speculation from link elements in a page. They may include criteria which restrict which of these links can be used.
Currently developers can only specify speculation rules using inline script tags. The proposed feature provides an alternative through the "Speculation-Rules" header. Its value must be a URL to a text resource with "application/speculationrules+json" MIME type. The resource's rules will be added to the document's rule set.
Expose information about how a resource was delivered. For example, resources which were delivered from the cache (currently exposed through transferSize) and navigations which were prefetched by the previous page are useful to identify.
An overview of this experiment remains available here:
See also the previous intent: https://groups.google.com/a/chromium.org/g/blink-dev/c/3-0rLTZePzc/m/VNHWAdAGDQAJ
Blink component
TAG review
https://github.com/w3ctag/design-reviews/issues/721
TAG review status
Complete at this time. TAG has reservations about whether the use cases of this feature justify its complexity, as compared to a simpler solution which would address some but not all of the use cases.
Risks
Interoperability and Compatibility
Because authors cannot rely on speculation rules being evaluated (or preloading generally), applications which use them should function correctly in other browsers and should continue to function correctly were the feature to be deprecated. Of course, ideally other browsers do find it compelling to implement this feature.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/620)
WebKit: No signal (https://github.com/WebKit/standards-positions/issues/54)
Web developers: We built these enhancements specifically upon requests from partners that found the current speculation rules too hard to integrate into their sites, and have at least one partner lined up to participate in the origin trial.
Other signals:
Activation
Some developers might not be immediately aware of which URLs they can preload without side effects. This risk is reduced if they primarily use the feature for same-origin URL patterns they are familiar with.
Security
See https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations.
WebView application risks
None that are specifically anticipated.
Justification for extension
During the experiment, we have made improvements to these features, fixed bugs, and improved developer tools to make them easier to debug. We have some data from use of this showing benefits, but want to both make further improvements to our implementation and give more time for partners to engage (there were unforeseen delays in at least one instance).
Ongoing technical constraints
At this time the constraints are believed to be minimal.
Debuggability
Preloading and speculation rules fetches which occur are both visible in the Network panel and the in-development Preloading panel. Console warnings are logged when several types of issues are encountered.
See, e.g.
https://bugs.chromium.org/p/chromium/issues/detail?id=1384419
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
Yes
Flag name
Origin trial name "SpeculationRulesPrefetchFuture", spanning multiple underlying feature flags.
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1371522
https://bugs.chromium.org/p/chromium/issues/detail?id=1366940
https://bugs.chromium.org/p/chromium/issues/detail?id=1358591
Estimated milestones
110-118 (inclusive) on all Chrome platforms
if extension for milestones 116-118 (inclusive) is granted
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5112150536749056
https://chromestatus.com/feature/5069400512659456
https://chromestatus.com/feature/6347141115543552
Links to previous Intent discussions
Intents to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/3-0rLTZePzc/m/VNHWAdAGDQAJ
Mike Taylor
LGTM to extend to 118 inclusive.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13epuEiXzbO3HJq0O9eum5_parJYHWHuje7QztZRd-s56w%40mail.gmail.com.
Tim Vereecke
Hello,
During the summer of 2023 we tested both new API's (Header and Document rules) and compared it to a CDN implementation without the original trial.
(The Origin Trial was activated on my site Scalemates, and speculation rules were configured and delivered via Akamai.)
Summary:
- Document Rules: This is a game changer and makes implementations not only easier but increases the probability that next navigations will see the expected performance benefits. It removes the speculation and gambling aspects of the API.
- When using a CDN, the Header approach makes it easier to implement and avoids complicating caching and purging.
A bit more detail on each API:
A) Feedback on HTTP header version:
Although both work as expected, for a CDN based integration the HTTP header version comes with several advantages.
CDN Integration:
• Easier integration at the Edge
• No overhead/eco impact transforming HTML
CDN Cache efficiency:
• Allows A/B testing without poisoning the cache
• Purging speculation rules does not required purging all HTML pages
Edge logic without delaying HTML:
• Serve different speculation rules based on geo/connection/user/…
• Speculation rules delay (eg. lookup popular next navigations in RUM data) not in critical path
B) Feedback on Document rules:
Although both work as expected, the document rules makes the API an order of magnitude better.
Implementation:
• Easier
• Generic speculation rules possible
• Rules are more static
• Reduced risk of “speculation misses”
• No more gambling
No analytics data required to speculate:
• Works for long tail links
• Works for personalised links
• Works for new links/stops for removed links
• No A/B testing blind spots
• No cross internationalisation gaps/issues
Kind regards,
Tim Vereecke
Performance Specialist Akamai