Intent to Experiment: No-Vary-Search support in navigation prefetch cache

Skip to first unread message

Liviu Tinta

Dec 8, 2022, 5:20:39 PM12/8/22
to blink-dev

Contact emails,,




Enables prefetch to match even if URL query parameters change. The No-Vary-Search HTTP response header declares that some or all parts of a URL's query can be ignored for cache matching purposes. It can declare that the order of query parameter keys should not cause cache misses, that specific query parameters should not cause cache misses or that only certain known query parameters should cause cache misses. It could apply to multiple caches, but this entry refers to support for prefetch cache.

Blink component


TAG review

TAG review status



Interoperability and Compatibility

Gecko: No signal. Request for Standards Position:

WebKit: No signal. Informal positive signals from individual engineers at TPAC 2022. Request for Standards Position:

Web developers: Positive. Google Search is interested in experimenting with the header, specifically for the customizing server behavior use case.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No. This is a new opt-in feature.

Goals for experimentation

Verify that the No-Vary-Search HTTP response header's design is useful and solves a real world problem. 

Based on feedback, iterate on the design to increase functionality. 

Validate the impact of this feature.

Ongoing technical constraints

The No-Vary-Search header introduces a non-exact way to match the request URL with an already cached response. In theory this allows more possibilities to reuse responses in browser cache/s (if the browser implements this feature). If a browser does not implement the feature then it can simply ignore this HTTP response header and continue with an exact match between request URL and cached response. In implementing and defining the specification for this HTTP response header we made sure it follows RFC 8941 and also that it allows for extensibility in the future.

The prefetch version of this feature does not add any ongoing technical constraints, as the prefetch cache is small. It's possible a future version which also applies to the HTTP cache could have trickier interactions, due to the many entries in the user's HTTP cache requiring a different architecture. That is not under consideration for now.


The website owner can debug the feature in DevTools by making sure that, when navigating to a prefetched page by using a URL that matches under No-Vary-Search conditions, the navigation happens from the prefetch cache by looking at the Size column in the Network tab. In case of success, when hovering over the Size column in the Network tab of Dev Tools, they should see: "Served from prefetch cache, resource size: yyyB"

We are also working on a preloading panel ( which shows all ongoing preloads, including both the targeted URL and the cached URL, if they differ due to No-Vary-Search.

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?

Yes. WPTs will be landed before the experiment starts under external/wpt/speculation-rules/prefetch/no-vary-search folder.

Flag name


Requires code in //chrome?


Estimated milestones

Experiment to start in M110 and end in M115.

Link to entry on the Chrome Platform Status

Links to previous Intent discussions

Intent to prototype:

Yoav Weiss

Dec 12, 2022, 4:26:29 AM12/12/22
to Liviu Tinta, blink-dev
LGTM to experiment M110 till M115.

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
Reply all
Reply to author
0 new messages