Intent to Prototype: No-Vary-Search Hint for Prefetch Speculation Rules

[Liviu Tinta]

Contact emails

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

Explainer

https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md#a-referrer-hint

Specification

To be started soon.

Summary

Adds a hint to speculation rules that informs the navigation prefetch cache that the URL to be prefetched expects to receive the same No-Vary-Search header in the response. The hint is useful because prefetches that depend on No-Vary-Search to match to navigations do not benefit the user if the navigation happens before prefetch headers return from the server. Using the hint, the web browser will expect, but verify, that the No-Vary-Search hint matches with the No-Vary-Search header. If the No-Vary-Search hint does not match the No-Vary-Search header received then the web browser will send a new request.

Blink component

Internals>Preload

Motivation

No-Vary-Search as proposed and implemented requires the client to parse headers to match a prefetch to a navigation, at least for sites that will use the No-Vary-Search paradigm. This inherently requires the start of the response to be received on the client before the browser knows what URL will match the prefetch. Due to that behavior, a web browser can currently take three approaches when there is a prefetch path match before headers have come back for the prefetch:
a) Ignore unless the path and query are an exact match
b) Wait for the headers to come back on the prefetch then decide if it is a match when the path matches
c) Race the navigation request with the prefetch request and serve whichever finishes first assuming the prefetch matches

All three of these options have drawbacks.

Option a prevents a class of prefetches that happen directly before navigation, such as hover over or press down on the link. This class of prefetches will very likely not finish before the actual navigation occurs. The server will also see extra capacity of responding to a prefetch that is not served.

Option b is also unacceptable for this scenario. If a navigation is delayed to check a header on a prefetch, we will hamper the performance of the site when the prefetch does not match. Due to the lack of knowledge by the web browser on whether the site even supports No-Vary-Search, this option can negatively affect sites that will never even benefit from No-Vary-Search.

Option c is a hybrid of a and b. It removes the delay of option b, but the duplicate requests may impose extra server load and compete for the user's bandwidth. For this reason, it is less than ideal.

A No-Vary-Search hint would attach the same information as the No-Vary-Search header when the prefetch is started by the referrer. When adding a prefetch via speculation rules, the referrer would add something to the speculation rule for the prefetch in the form of:  "expected_no_vary_search":"params=(\"pf\")". This would be the exact same information as the No-Vary-Search header. The web browser would expect, but verify, that this matches with the header. When a prefetch matches a navigation based on the hint, the web browser would wait for the headers and verify that the headers truly allow the navigation to be served by the in-progress prefetch. If the headers don’t allow the prefetch to be served, the normal navigation request would be issued.

Using this strategy, the result generally becomes a combination of options a and b above, and becomes a lot more attractive. When the server agrees with itself, there is minimal loss in either latency benefit or capacity usage with this approach. The only risks are when the header and hint disagree, in which case it can pay the cost of either option a or b depending on how the disagreement occurs.

Initial public proposal

https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md#a-referrer-hint

TAG review

Not yet required.

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

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?

Debuggability

Will be possible to debug on the new preloading Dev Tools tab.

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

The plan is to build WPTs during the implementation.

Flag name

PrefetchNoVarySearchHint

Requires code in //chrome?

False

Estimated milestones

Expect to land the code in M113 and send Intent to Experiment.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4887338302308352

This intent message was generated by Chrome Platform Status.