> Another alternative is to race the requests right? What are the downsides of that? This alternative has been mentioned in Intent to Prototype: No-Vary-Search Hint for Prefetch Speculation Rules <https://groups.google.com/a/chromium.org/g/blink-dev/c/HX2iHMBjg7s>. The downside is that sending duplicate requests will impose extra server load and compete for user's bandwidth.
> 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? One alternative I've considered was to wait for prefetch/prerender headers for navigation URL that matches prefetch URL without query / fragment and then check for No-Vary-Search variance equivalence between the two URLs if a No-Vary-Search header was received. This approach has the downside that it would slow down navigation to pages that do not use No-Vary-Search header. Example of such URL would be: a.com/product.html?id=123. a.com would want to prefetch/prerender the most popular products, but not all of them. Navigation to a less popular product page would be slowed down by waiting for headers for a prefetch/prerender of a popular product. The current default behaviour should work for most cases: use the prefetch/prerender that has an exact match URL or has already received a No-Vary-Search header that matches, wait for headers to make a decision if there is a hint that matches, otherwise fallback to normal navigation. This allows optimal behaviour for the special use cases that I described above (hover / pointerdown trigger, in-progress prefetch/prerender independent of navigation) where the page author has to specify the hint while providing a reasonable default in the absence of the hint. On Friday, June 7, 2024 at 11:36:02 AM UTC-4 Vladimir Levin wrote: > Thank you for the detailed explanation! I have some more questions below. > > On Thu, Jun 6, 2024 at 7:55 PM Liviu Tinta <liviuti...@chromium.org> > 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 <chris...@chromium.org> >>> wrote: >>> >>>> LGTM2 >>>> >>>> On Wed, Jun 5, 2024 at 9:58 PM Mike Taylor <miketa...@chromium.org> >>>> wrote: >>>> >>>>> LGTM1 >>>>> On 6/5/24 11:21 PM, Liviu Tinta wrote: >>>>> >>>>> Contact emails >>>>> >>>>> dome...@chromium.org, jbro...@chromium.org, liviuti...@chromium.org >>>>> >>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>> 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 blink-dev+unsubscr...@chromium.org. >>>> >>> 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 blink-dev+unsubscr...@chromium.org. >> > 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/324fa743-ba7f-47cc-aef0-3842907e8a2cn%40chromium.org.
