Intent to Extend Experiment: Speculation Rules - Document rules, response header, deliveryType

Skip to first unread message

Jeremy Roman

May 24, 2023, 3:30:25 PM5/24/23
to blink-dev

Contact emails,,,,




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:

Blink component


TAG review

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.


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 (

WebKit: No signal (

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.



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.


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.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


Is this feature fully tested by web-platform-tests?


Flag name

Origin trial name "SpeculationRulesPrefetchFuture", spanning multiple underlying feature flags.

Requires code in //chrome?


Tracking bug

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

Links to previous Intent discussions

Intents to prototype:

Mike Taylor

May 25, 2023, 2:21:36 PM5/25/23
to Jeremy Roman, blink-dev

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
To view this discussion on the web visit

Tim Vereecke

Sep 11, 2023, 6:17:30 AM9/11/23
to blink-dev, Jeremy Roman


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.)


- 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.

• 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

Reply all
Reply to author
0 new messages