Thank you for the detailed explanation! I have some more questions below. On Thu, Jun 6, 2024 at 7:55 PM Liviu Tinta <[email protected]> wrote:
> > Do you have a sense of how often the failure cases happen? Also what is > the cost of this failure? > The discussion is limited to in-progress prefetches that have not yet > received headers when the navigation to a non-exact match URL happens. > > - With our partner, both hint and header are the same in a same site > navigation use case. It would be possible to have hint and header be > different and prefetch and navigation URLs still match by No-Vary-Search > header variance but the easiest way is to use the same hint and header. So > in this sense, waiting for headers is always successful in our experiment. > If the navigation URL doesn't match the prefetch URL by No-Vary-Search > header variance the cost is the time we blocked navigation waiting for > headers, so the portion of time to first byte of the prefetch between > navigation time and the prefetch receiving headers. This cost decreases > with how close to the prefetch receiving headers the navigation happens. > - Not having the hint, the cost is the fact that we could have used > the in-progress prefetch serving No-Vary-Search header but we didn't. This > cost is the portion of time to first byte from the beginning of the > prefetch request to navigation time. This cost increases with how close to > the prefetch receiving headers the navigation happens. > > Another alternative is to race the requests right? What are the downsides of that? My concern is that it seems like to use No-Vary-Search header properly in a prerender context, one _must_ specify expect_no_vary_search with exactly the same header values (or at least the ones that are consequential for a particular request). Otherwise, the site will experience the costs that you describe here. Without data (since No-Vary-Search for prerender has not yet shipped), we don't really know how often this happens. The site author also has to have a pretty good understanding of what headers the server returns and adjust as necessary when server. >From the API perspective, it feels like this is a knob that may not be well understood and I wonder if a browser can either do something automatically or at least have a default behavior that works in a vast majority of cases without the need for developer action. What are your thoughts on this? Thanks, Vlad > For a sense of scale for the above costs, time to first byte (TTFB > <https://web.dev/articles/ttfb>) is defined as "good" below 0.8s and > "needs improvement" up to 1.8s. > > The hint is useful for: > > - prefetch triggered independently from navigation. As an example, at > page load the page could prefetch most likely next links. In this case, the > prefetch might still be in progress when a user clicks one of these next > links immediately after page load. > - prefetch triggered based on user interaction leading to a navigation > (e.g. at hover or pointerdown) - these prefetches will very likely be in > progress when navigation happens (pointerdown to navigation is less than > one hundred ms and from hover to navigation a few hundred ms - see > https://instant.page/). The hint helps to trigger such prefetches > based on user interaction and thus deliver these gains to the navigation. > - having parity with navigation to a URL that exactly matches an > in-progress prefetch URL > > The above discussion about No-Vary-Search hint applies to prerender as > well. > > On Thursday, June 6, 2024 at 1:26:34 PM UTC-4 Vladimir Levin wrote: > >> From the explainer, expects_no_vary_search helps because when we're >> prefetching but have not yet received headers, we don't know if that >> request would match what the user is now navigating to. Do you have a sense >> of how often the failure cases happen? (ie we waited for that navigation >> request to finish but we shouldn't have, or vice versa). Also what is the >> cost of this failure? It seems like this is a good addition but it seems >> like a very fine-grained control for cases that may not be problematic or >> costly. >> >> On Thu, Jun 6, 2024 at 12:45 PM Chris Harrelson <[email protected]> >> wrote: >> >>> LGTM2 >>> >>> On Wed, Jun 5, 2024 at 9:58 PM Mike Taylor <[email protected]> >>> wrote: >>> >>>> LGTM1 >>>> On 6/5/24 11:21 PM, Liviu Tinta wrote: >>>> >>>> Contact emails >>>> >>>> [email protected], [email protected], [email protected] >>>> >>>> Explainer >>>> >>>> >>>> https://github.com/WICG/nav-speculation/blob/main/triggers.md#no-vary-search-hint >>>> >>>> Specification >>>> >>>> https://wicg.github.io/nav-speculation/prerendering.html >>>> >>>> Summary >>>> >>>> Adds a hint to speculation rules that informs the navigation prerender >>>> cache that the URL to be prerendered expects to receive the same >>>> No-Vary-Search header in the response. >>>> >>>> The hint is useful because prerenders that depend on No-Vary-Search to >>>> match to navigations do not benefit the user if the navigation happens >>>> before prerender 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. >>>> >>>> We would like to ship "No-Vary-Search Hint for Prerender Speculation >>>> Rules" together with "No-Vary-Search support for prerender >>>> <https://chromestatus.com/feature/5099218903760896>". >>>> >>>> Blink component >>>> >>>> Internals>Preload>Prerender >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload%3EPrerender> >>>> >>>> TAG review >>>> >>>> Not applicable. The TAG has already given a negative opinion on the >>>> overall complexity of speculation rules ( >>>> https://github.com/w3ctag/design-reviews/issues/721 ), so we >>>> anticipate it would not be a good use of their time to review additions to >>>> the syntax. The addition itself is small and any architectural questions >>>> about it would be covered under the general closed speculation rules >>>> review. >>>> >>>> TAG review status >>>> >>>> Not applicable >>>> >>>> Risks >>>> >>>> Interoperability and Compatibility >>>> >>>> None >>>> >>>> >>>> Gecko: No signal ( >>>> https://github.com/mozilla/standards-positions/issues/620#issuecomment-1608195274 >>>> ) >>>> >>>> WebKit: No signal ( >>>> https://github.com/WebKit/standards-positions/issues/54#issuecomment-1608197504 >>>> ) >>>> >>>> Web developers: 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. >>>> >>>> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> 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 >>>> >>>> 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/5190922953555968?gate=5148879099265024 >>>> >>>> Links to previous Intent discussions >>>> >>>> Intent to prototype: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B7y87rgssbBecLSY5fz03ATcAAjgy%3DjY322w_2roQdsehP4Dg%40mail.gmail.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 on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYJphk8wg8yLr-VFe2QJDZ4N%3D8Z%2BBAs9VL5scY-brTmRTg%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYJphk8wg8yLr-VFe2QJDZ4N%3D8Z%2BBAs9VL5scY-brTmRTg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> -- >>>> 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/457ce01c-56ea-42a9-b9ef-1d84216ccd90%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/457ce01c-56ea-42a9-b9ef-1d84216ccd90%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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/CAOMQ%2Bw9p78D28sGy7zBHQk1cij7PwDs7EE8GnDZ62hpudydOtg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9p78D28sGy7zBHQk1cij7PwDs7EE8GnDZ62hpudydOtg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/7bad86d7-3242-47f1-86fc-fdf1628bbc7bn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7bad86d7-3242-47f1-86fc-fdf1628bbc7bn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CADsXd2OZvUuz5hANQcceSQX6F8OU4pehBKGVFU7KmBVKhCPFFA%40mail.gmail.com.
