jbr...@chromium.org, adit...@chromium.org, isab...@google.com, dom...@chromium.org, kenji...@chromium.org
https://github.com/WICG/nav-speculation/blob/main/triggers.md
https://github.com/w3c/resource-timing/issues/332
https://wicg.github.io/nav-speculation/speculation-rules.html
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
https://github.com/w3ctag/design-reviews/issues/721
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.
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:
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.
See https://wicg.github.io/nav-speculation/speculation-rules.html#security-considerations.
None that are specifically anticipated.
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).
At this time the constraints are believed to be minimal.
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
Yes
Yes
Origin trial name "SpeculationRulesPrefetchFuture", spanning multiple underlying feature flags.
False
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
110-118 (inclusive) on all Chrome platforms
if extension for milestones 116-118 (inclusive) is granted
https://chromestatus.com/feature/5112150536749056
https://chromestatus.com/feature/5069400512659456
https://chromestatus.com/feature/6347141115543552
Intents to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/3-0rLTZePzc/m/VNHWAdAGDQAJ
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.
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