Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prerender Speculation Rules

[Mike Taylor]

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 
".



Blink component

Internals>Preload>Prerender 




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.





De

Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prerender Speculation Rules

[Chris Harrelson]

LGTM2

On Wed, Jun 5, 2024 at 9:58 PM Mike Taylor  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
> ".
>
> Blink component
>
> Internals>Preload>Prerender
> 
>
> 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
> 
> ?
>
> 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 

Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prerender Speculation Rules

[Vladimir Levin]

>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 
wrote:

> LGTM2
>
> On Wed, Jun 5, 2024 at 9:58 PM Mike Taylor  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
>> ".
>>
>> Blink component
>>
>> Internals>Preload>Prerender
>> 
>>
>> 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

Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prerender Speculation Rules

[Liviu Tinta]

>  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.

For a sense of scale for the above costs, time to first byte (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  
> wrote:
>
>> LGTM2
>>
>> On Wed, Jun 5, 2024 at 9:58 PM Mike Taylor  
>> 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 
>>> ".
>>>
>>> Blink component 
>>>
>>> Internals>Preload>Prerender 
>>> 
>>>
>>> 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 unde

Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prerender Speculation Rules

[Vladimir Levin]

Thank you for the detailed explanation! I have some more questions below.

On Thu, Jun 6, 2024 at 7:55 PM Liviu Tinta  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
> ) 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 
>> wrote:
>>
>>> LGTM2
>>>
>>> On Wed, Jun 5, 2024 at 9:58 PM Mike Taylor 
>>> 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-Va

Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prerender Speculation Rules

[Liviu Tinta]

> 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 
. 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  
> 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 
>> ) 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 progres

Re: [blink-dev] Intent to Ship: No-Vary-Search Hint for Prerender Speculation Rules

[Vladimir Levin]

On Fri, Jun 7, 2024 at 12:18 PM Liviu Tinta  wrote:

> > 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
> . 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.
>

That makes sense. It seems like the expectation is that this hint would
only be used in cases where developers are optimizing on hover to save as
much time as possible, so it makes sense that racing or having wasted work
is undesired.

LGTM3

Thanks,
Vlad

>
>
> 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 
>> 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