Contact [email protected], [email protected], [email protected]
Explainer https://github.com/WICG/nav-speculation/blob/main/no-vary-search.md#a-referrer-hint SpecificationTo 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 componentInternals>Preload <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload> 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 reviewNot yet required. TAG review statusPending 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?The plan is to build WPTs during the implementation. Flag namePrefetchNoVarySearchHint 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 <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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYKuRY%2B4SrbtUSsoVUT_s9D18Vt4U4fB3B-8-E1V3y3e5g%40mail.gmail.com.
