Intent to Ship: No-Vary-Search support for prerender

408 views
Skip to first unread message

Liviu Tinta

unread,
Jun 5, 2024, 10:04:10 AMJun 5
to blink-dev

Contact emails

dom...@chromium.org, jbr...@chromium.org, liviu...@chromium.org


Explainer

https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md#prerendering-activation


Specification

https://wicg.github.io/nav-speculation/no-vary-search.html


Summary

Enables a prerender entry 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 prerender.



Blink component

Internals>Preload>Prerender


TAG review

https://github.com/w3ctag/design-reviews/issues/797


TAG review status

Pending


Risks



Interoperability and Compatibility

None



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/717)


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/106)


Web developers: No signals Below is the text from the I2S of the No-Vary-Search on navigational prefetch, and we believe the same applies to Prerendering. Google Search has been experimenting with No-Vary-Search header / Speculation Rules "expects_no_vary_search". This functionality helps Google Search to match prefetched content to the next user navigation. Developers can use parameters in the prefetched URL that are not needed when navigating to the actual link (e.g. the source of the link click). The server can customize behavior using these parameters without causing a cache miss in the browser. "expects_no_vary_search" addition to Speculation Rules allows the browser to completely handle the case where the user navigates to a URL that is currently prefetched by waiting for the ongoing prefetch instead of directly requesting the page from the server. Google Search conducted experiments prefetching Search results pages from the search box and other links that lead to another Search results page. There was significant latency improvement for navigating to Search result pages prefetched using No-Vary-Search header and "expects_no_vary_search".


Other signals: No-Vary-Search header has been discussed, together with No-Vary-Search Hint for Prefetch Speculation Rules at Web Perf WG meeting at TPAC 2023. https://docs.google.com/presentation/u/1/d/1GK92nCORW5vKd7LgGtTsgy35eqTV7P71l05pHsni8ok/edit#slide=id.g240fd6541f7_0_31


Ergonomics

(Text taken from Prefetch NVS I2S)


No-Vary-Search will be used in tandem with Speculation Rules (https://wicg.github.io/nav-speculation/speculation-rules.html). The default usage of No-Vary-Search will not make it hard for Chrome to maintain good performance.



Activation

This should be a natural extension to the previous feature launch "No-Vary-Search support in navigation prefetch cache" (https://groups.google.com/a/chromium.org/g/blink-dev/c/XnG5BF3uoeE/m/fwR6LDt4BQAJ )

Before this launch, No-Vary-Search was only respected for speculation rules targeting prefetch, so web author may have specified them without knowing that it wouldn't work. With this launch, No-Vary-Search header will be respected on all types of Speculation Rule Set https://wicg.github.io/nav-speculation/speculation-rules.html#speculation-rule-set , so it is more consistent.



Security

See: https://github.com/WICG/nav-speculation/blob/main/no-vary-search-security-privacy-questionnaire.md





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?

We are closely working with Android WebView team, and the broader prerender feature is gated through new AwSettings API (currently @RequiresOptIn) so there's zero risk that it will break existing WebView apps.



Debuggability

None



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

Yes


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

Yes

https://wpt.fyi/results/speculation-rules/prerender?label=experimental&label=master&aligned

(The test files starting with no-vary-search)



Flag name on chrome://flags

None


Finch feature name

Prerender2NoVarySearch


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/issues/41494389


Estimated milestones

Shipping on Desktop

127


Shipping on Android

127


Shipping on WebView

127




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


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5099218903760896?gate=5171022636777472


Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqY%2B13miDT4YS3%3DjhgW4V6Cv8FZ3E_QT2Tj6aq1yy%3DJgsyw%40mail.gmail.com


This intent message was generated by Chrome Platform Status.


Domenic Denicola

unread,
Jun 5, 2024, 10:42:29 PMJun 5
to blink-dev, Liviu Tinta
I will abstain from approving this feature as an API Owner, as one of the people responsible for it. But I will urge other API owners to approve it, and give a bit of reasoning.

In my opinion, this is a straightforward extension from prefetch to prerender which makes the web platform more uniform. It is good that it is being done as a separate intent, since it is shipping at a different time, and thus need to appear separately in e.g. beta blog posts and other developer-facing documentation. But I think the same considerations that helped the prefetch version get a prompt approval should apply here.

BTW, looking back on that previous thread, some of the non-blocking discussion raised there was about engaging the HTTPWG. I'm happy to report that we've started this process, producing a draft RFC and getting some discussion started on the relevant mailing list, which seem relatively positive to me. There was also some concern about ensuring that compression dictionaries and this header aligned on the same naming; as far as I can tell that issue no longer exists as the latest compression dictionaries draft only has "match", and no longer "match-query".

Mike Taylor

unread,
Jun 6, 2024, 12:56:13 AMJun 6
to Domenic Denicola, blink-dev, Liviu Tinta

LGTM1 - I'm very happy to see this ship.

--
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/65609d80-3c17-4853-bae6-e9576cf4582fn%40chromium.org.

Chris Harrelson

unread,
Jun 6, 2024, 12:45:52 PMJun 6
to Mike Taylor, Domenic Denicola, blink-dev, Liviu Tinta
LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6aeadef-3cf7-4397-b936-3031b1092d70%40chromium.org.

Vladimir Levin

unread,
Jun 6, 2024, 1:22:05 PMJun 6
to Chris Harrelson, Mike Taylor, Domenic Denicola, blink-dev, Liviu Tinta
LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_qGedddYf6siEo6HLMaftfjB-0mvj%2BH8%3Dg27LTJM4q_w%40mail.gmail.com.

Daniel Bratell

unread,
Jun 12, 2024, 7:42:05 AMJun 12
to Vladimir Levin, Chris Harrelson, Mike Taylor, Domenic Denicola, blink-dev, Liviu Tinta

Now, when it looks like this will be shipped, can you please update the stalled standard-position issues for Mozilla and WebKit so that they know that we'll proceed with it.

/Daniel

Liviu Tinta

unread,
Jun 12, 2024, 11:06:48 AMJun 12
to blink-dev, Daniel Bratell, Mike Taylor, Domenic Denicola, blink-dev, Liviu Tinta, Vladimir Levin, Chris Harrelson
> Now, when it looks like this will be shipped, can you please update the stalled standard-position issues for Mozilla and WebKit so that they know that we'll proceed with it.
The standard position issues for both Mozilla and WebKit were updated.

LGTM3

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
Reply all
Reply to author
Forward
0 new messages