LGTM1; love to see this sort of performance-improving change that also improves standards conformance.
On Friday, September 26, 2025 at 1:29:44 AM UTC-7 Adam Rice wrote: > *Contact emails* > [email protected], [email protected] > > *Explainer* > https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md > > *Specification* > https://httpwg.org/http-extensions/draft-ietf-httpbis-no-vary-search.html > > *Design docs* > > > https://docs.google.com/document/d/1RS3q6qZ7-k9CvZsDYseGOXzcdQ9fGZ6YYnaW7fTPu7A/edit > > *Summary* > Enables the HTTP disk cache to use the No-Vary-Search response header to > share a cache entry between URLs that differ only in the query parameters. > Developers can use No-Vary-Search to specify query parameters that have no > impact on the user experience. A common example might be an id used to > track conversions. Supporting this header in the HTTP disk cache means that > if the user later goes back to that same page without the conversion id, it > can be used or revalidated from the cache rather than having to be fetched > from scratch from the network. Previously, No-Vary-Search support shipped > for the navigation prefetch cache, prefetch and prerender speculation > rules, and prerender. This launch makes it generally available to any > feature that uses the HTTP disk cache. > > *Blink component* > Internals>Network>Cache > <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ECache%22> > > *Web Feature ID* > Missing feature > > *TAG review* > https://github.com/w3ctag/design-reviews/issues/797 > > *TAG review status* > Issues addressed > > *Risks* > > > *Interoperability and Compatibility* > No-Vary-Search is a best-effort feature, meaning that servers cannot rely > on it being implemented by caches. As a result, it is quite easy to remove > if not widely adopted. > > *Gecko*: Positive ( > https://github.com/mozilla/standards-positions/issues/717) > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/106) > > *Web developers*: Positive ( > https://techshed.runbookdocs.com/docs/tips/6/no-vary-search) > > *Other signals*: > > *Ergonomics* > This feature will usually be used in tandem with the Cache-Control, > Last-Modified and/or ETag response headers that control the cacheability of > the response. The implementation design was carefully chosen to avoid > additional disk accesses and to minimize the overhead when it is not in > use. To avoid context switches, it must run synchronously on the IO thread > in the network service, so high performance is essential. > > *Activation* > Implementation is easy for developers who are able to customize their HTTP > response headers. The most time-consuming part is determining which query > parameters do not affect user-visible behavior. Developers who cannot > customize their HTTP response headers will have to wait for support from > the framework or hosting providers they are using. > > *Security* > The feature must not expose any information to the page that it would not > have had otherwise. For this reason, the implementation uses exactly the > same partitioning method as the HTTP disk cache. An overly-broad setting > for the No-Vary-Search response header can, in combination with other > server-side bugs, lead to an attacker being able to control the content > which is shown to the user. However, the risk is no worse than with > existing features that permit customizing responses like ServiceWorkers. > See the design document for more details. > > *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? None. > > > *Debuggability* > Beyond the usual display of headers in the Network section, integration > with DevTools is not currently planned, but may be added as a future > enhancement. > > *Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)?* > Yes The feature is implemented in //net, so all platforms that use the > //net layer for navigation & subresources will have it. > > *Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* > Yes > https://wpt.fyi/results/fetch/http-cache/no-vary-search.tentative.any.html?label=experimental&label=master&aligned > > *Flag name on about://flags* > None > > *Finch feature name* > HttpCacheNoVarySearch > > *Rollout plan* > (RARE) Ships disabled, then flips on for all users > > The feature behaves like a progressive enhancement, in that it improves > cache hit rate when enabled and used, but everything still works without > it. As there are a number of other features blocked on this one, it is > useful to launch in M141 rather than wait for M142. > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/382394774 > > *Launch bug* > https://launch.corp.google.com/launch/4373880 > > *Measurement* > Histogram HttpCache.NoVarySearch.UseResult collects information about what > proportion of requests use a different cache entry due to No-Vary-Search. > Histogram HttpCache.NoVarySearch.HeaderParseResult collects information > about what proportion of response have a No-Vary-Search header. It is also > tracked by HTML & JavaScript usage metrics at > https://chromestatus.com/metrics/feature/timeline/popularity/4425 (currently > around 1.5% of page loads). > > *Availability expectation* > Feature is available on Web Platform Baseline within 24 months of launch > in Chrome. > > *Adoption expectation* > Feature is considered a best practice for some use case within 12 months > of reaching Web Platform baseline. Feature is used by specific partner(s) > to improve performance within 3 months of launch in Chrome. > > *Adoption plan* > Internal experiments are already ongoing to use the feature. DevRel will > evangelise the performance benefits once the experiment results are > available. > > *Non-OSS dependencies* > > Does the feature depend on any code or APIs outside the Chromium open > source repository and its open-source dependencies to function? None. > > *Estimated milestones* > Shipping on desktop 141 > DevTrial on desktop 135 > Shipping on Android 142 > DevTrial on Android 135 > Shipping on WebView 142 > > *Anticipated spec changes* > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). None; everything in > https://github.com/httpwg/http-extensions/labels/no-vary-search is > editorial > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5808599110254592?gate=6604429773766656 > > *Links to previous Intent discussions* > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67ac01fe.2b0a0220.1b0c0.02a6.GAE%40google.com > > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/967b0037-05fc-4f97-927c-e41d894e5e56n%40chromium.org.
