Intent to Ship: removing the five-minute rule for <link rel=prefetch>

[Noam Rosenthal]

Contact emails

nrose...@chromium.org

Explainer

No specific explainer, but all the details are here:
https://chromestatus.com/feature/5087526916718592?context=myfeatures

https://bugs.chromium.org/p/chromium/issues/detail?id=1345207&q=5%20minute&can=3

Spec

This feature was never specified!

A new PR to the HTML spec to clarify how prefetch is supposed to work does not include this removed feature: https://github.com/whatwg/html/pull/8111

Summary

- Currently, when a document includes <link rel=prefetch> and then a resource tries to consume it, cache-control semantics (max-age, no-cache etc) are ignored for 5 minutes.

- This was originally introduced when prefetches were meant for cross-origin navigations (think search engine results), as the prefetching page had no control over the caching semantics of the prefetched page

- Since introducing partitioned caching, <link rel=prefetch> no longer works for cross-origin navigation anyway, so that initial use-case is irrelevant.

- Data from UMA shows that the vast majority of prefetch reuses don't benefit from this - only 0.05%. The rest are either anyway within the cache max-age, outside the 5 minutes, or reused past the first time. This makes this a niche feature that apart from adding a bit of confusion to the mix does very little.

- Additional supporting data from HTTP archive shows that the web dev community is not using prefetch for cross-origin navigations, but rather mainly for same-origin early fetching of styles and scripts (only 4% of pefetches are for cross-origin navigations). 

- The data shows that <link rel=prefetch> transitioned from being a feature for search-type pages into a feature for home/landing pages: e.g. you have a very fast landing page without scripts and a link to the full web-app page, and you prefetch the scripts and style of the heavy app to make it load faster once you click the link

Link to “Intent to Prototype” blink-dev discussion

Link to the blink-dev discussion about implementation. Here’s a link to the Google Groups page for blink-dev.

Link to Origin Trial feedback summary

There was no origin trial. Users would barely feel the impact of this.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link

N/A

Debuggability

Web devs can see the impact of this in their network panel.

Measurement

It's a removal, and current use of the feature is marginal at best (potentially arbitrary and inconsequential).

Risks

Interoperability and Compatibility

This fix is interoperable with firefox, and Safari folks are positive about implementing fetch with the proposed behavior (without the 5-minute rule);

Ergonomics

It's a feature removal that very few rely on. The new speculation-rules prefetch should be a replacement for cross-origin navigational prefetch.

Activation

The very few developers who currently rely on the 5-minute can explicitly make the same behavior work using Cache-Control headers.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

PR for prefetch behavior pending spec merging: https://github.com/web-platform-tests/wpt/pull/35707

Entry on the feature dashboard

https://chromestatus.com/feature/5087526916718592

[Rick Byers]

LGTM1 from an API owners perspective. It's arguable whether this is "web-exposed" at all, or just a browser performance heuristic you're tweaking.

From a performance perspective, your argument and UMA analysis is compelling to me. But I've learned the hard way not to trust predictions of performance impact and instead rely on experiments :-). Were you planning on launching this with finch and validating the CWV impact? I'm not saying that's necessary, it could be overkill given your analysis. But if not then I'd suggest working the speed tooling team to keep an eye on FCP metrics as it launches to ensure there aren't surprises.

Thanks,

   Rick

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYa7YN%3DdePW5E9LQ2Qpo72r2h3m%3DVKdXfTg910U7AC51_w%40mail.gmail.com.

[Yoav Weiss]

LGTM2 to launch this as a Finch experiment.

On Fri, Jan 13, 2023 at 5:55 PM Rick Byers <rby...@chromium.org> wrote:

LGTM1 from an API owners perspective. It's arguable whether this is "web-exposed" at all, or just a browser performance heuristic you're tweaking.

From a performance perspective, your argument and UMA analysis is compelling to me. But I've learned the hard way not to trust predictions of performance impact and instead rely on experiments :-). Were you planning on launching this with finch and validating the CWV impact?

I think launching this as a Finch experiment makes a lot of sense.

This is extremely unlikely to break content, but can result in a performance regression, so slow rollout seems like the best way to go here.

I'm not saying that's necessary, it could be overkill given your analysis. But if not then I'd suggest working the speed tooling team to keep an eye on FCP metrics as it launches to ensure there aren't surprises.

Thanks,

   Rick

On Fri, Jan 13, 2023 at 1:13 AM Noam Rosenthal <nrose...@chromium.org> wrote:

Contact emails

nrose...@chromium.org

Explainer

No specific explainer, but all the details are here:
https://chromestatus.com/feature/5087526916718592?context=myfeatures

https://bugs.chromium.org/p/chromium/issues/detail?id=1345207&q=5%20minute&can=3

Spec

This feature was never specified!

A new PR to the HTML spec to clarify how prefetch is supposed to work does not include this removed feature: https://github.com/whatwg/html/pull/8111

Summary

- Currently, when a document includes <link rel=prefetch> and then a resource tries to consume it, cache-control semantics (max-age, no-cache etc) are ignored for 5 minutes.

- This was originally introduced when prefetches were meant for cross-origin navigations (think search engine results), as the prefetching page had no control over the caching semantics of the prefetched page

- Since introducing partitioned caching, <link rel=prefetch> no longer works for cross-origin navigation anyway, so that initial use-case is irrelevant.

IIRC, `as=document` prefetches are cached in the resource's partition, so I think they are still relevant.

They seem to be used by 0.3% of page views.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-1NCvS0kjeN2-agq2o5q1gHY%2BW%2BVzVV4N9v7EQaC3NiA%40mail.gmail.com.

[Noam Rosenthal]

On Fri, Jan 13, 2023 at 7:19 PM Yoav Weiss <yoav...@chromium.org> wrote:

LGTM2 to launch this as a Finch experiment.

On Fri, Jan 13, 2023 at 5:55 PM Rick Byers <rby...@chromium.org> wrote:

LGTM1 from an API owners perspective. It's arguable whether this is "web-exposed" at all, or just a browser performance heuristic you're tweaking.

From a performance perspective, your argument and UMA analysis is compelling to me. But I've learned the hard way not to trust predictions of performance impact and instead rely on experiments :-). Were you planning on launching this with finch and validating the CWV impact?

I think launching this as a Finch experiment makes a lot of sense.

This is extremely unlikely to break content, but can result in a performance regression, so slow rollout seems like the best way to go here

Sounds good, will proceed with finching this.

Thanks!

[Daniel Bratell]

LGTM3

/Daniel

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYZn7wV35v8W8ZwQN9oGSgVXcNsG030E8-WEftWRkTz4zw%40mail.gmail.com.

[Yoav Weiss]

My LGTM still stands. Glad we're not seeing any related regressions!

On Sun, Apr 23, 2023 at 7:43 AM Noam Rosenthal <nrose...@google.com> wrote:

Following up on this.

I conducted a finch trial, which (expectedly) has shown no statistically significant performance impact.

Note that the flag which the finch is based on only tests pages that attempted to reuse a prefetch.

I would like to proceed with removing the 5 minute rule. Would be happy to provide more information.

Thanks

Noam

[Noam Rosenthal]

Following up on this.

I conducted a finch trial, which (expectedly) has shown no statistically significant performance impact.

Note that the flag which the finch is based on only tests pages that attempted to reuse a prefetch.

I would like to proceed with removing the 5 minute rule. Would be happy to provide more information.

Thanks

Noam

On Wednesday, January 18, 2023 at 4:54:10 PM UTC+2 Daniel Bratell wrote:

[Noam Rosenthal]

Additional LGTMs?

[Mike Taylor]

Hi Noam,

Given the results, I would say you have the LGTMs you need to ship. Are you currently launched at 100% via Finch? LGTM to enable in tip of tree if so.

later,
Mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cd0fb6e-defd-42c5-87b0-83b90d81c7a5n%40chromium.org.

[Noam Rosenthal]

On Mon, May 1, 2023 at 5:15 PM Mike Taylor <mike...@chromium.org> wrote:

Hi Noam,

Given the results, I would say you have the LGTMs you need to ship. Are you currently launched at 100% via Finch? LGTM to enable in tip of tree if so.

No, should I slowly enable finch until it's 100% before enabling?

[Mike Taylor]

Up to you - if you're enabled at some % on stable now, ramping up to 100% then ToT makes sense. But if you only did the experiment for some period of time (i.e., it's at 0% right now), enabling on ToT only is fine too.

[Noam Rosenthal]

Yes it's at 0% on stable (beta+dev for quite a while) but I don't see a reason to keep the experiment churn. If that's OK I'll proceed with a ToT CL.

 

[Domenic Denicola]

Hi all,

It appears we never actually proceeded to create the ToT CL to enable this. It turns out this is implemented in a way that impacts both <link rel=prefetch> and speculation rules prefetch, and the latter is causing bugs for a large speculation rules prefetch deployment. See this bug for more on the speculation rules case.

I plan to submit a CL to enable this on ToT, based on the LGTMs given here. If anyone has any concerns, let me know. I will update ChromeStatus with the proper shipping milestone as well.

[Yoav Weiss (@Shopify)]

Refreshing my memory, as it's been a while - shipping this means that web developers would need to set their HTML's caching headers to be cacheable (even with a short lifetime) to ensure that prefetches are actually useful?

Should we add some console logs (and maybe web-exposed reports) on prefetches that are not cacheable? (as a followup) 

[Noam Rosenthal]

On Thu, Nov 28, 2024 at 10:11 AM Yoav Weiss (@Shopify)
<yoav...@chromium.org> wrote:
>
> Refreshing my memory, as it's been a while - shipping this means that web developers would need to set their HTML's caching headers to be cacheable (even with a short lifetime) to ensure that prefetches are actually useful?

Correct.

>
> Should we add some console logs (and maybe web-exposed reports) on prefetches that are not cacheable? (as a followup)

I wouldn't use console logs for this kind of thing, that's a very
crowded piece of real estate. But some sort of performance-panel
insights perhaps?

[Yoav Weiss (@Shopify)]

Sure, I meant "console logs" as a generic term for "surfacing this info to developers in the lab". I have no strong opinions regarding the specific surface.

[Yoav Weiss (@Shopify)]

Also, seems worthwhile for +Barry Pollard or someone else to make some noise on that front..

[Yoav Weiss (@Shopify)]

One more question - this applies to both <link rel=prefetch> and speculation rules, right? Developers would need to set (at least) short lifetime cache-control headers for both?

[Barry Pollard]

+Tze Yi Tan 

Performance Panel Insight's is currently focussed more on the current navigation, and what insights we can give to improve that. Prefetches are normally for future resources/navigations so not that focus at the moment. Yes wasted resources can affect the current nav too, but Performance Insights hasn't even fully launched yet so we need to prioritise our efforts here and I don't think this one is liable to be a high priority.

Lighthouse does have some audits for unused preconnect resource hints, but they are more informational and don't currently fail the audit. Perhaps they should and it should be expanded to prefetch and preload? Currently we've scaled back pushing preload as advice except for LCP images, as developers were over using it. But warning against bad uses (like prefetching an uncached resource) seems less controversial. Saying that we've a few bugs (I've raised a few myself!) about false alerts on preload here so it's tricky. Though this prefetch use case seems less likely to cause false positives.

TLDR: It's complicated and I'm not convinced this will be actioned in the short term no matter how noisy I get :-)

They do show in Console logs as errors, but that is noisy enough as you say. But short term that may be the best place?

@Domenic Denicola , since we're discussing doing the same for Speculation Rules, we may want to surface that specifically in the Speculative loads panels since those developers should be looking at that to debug that?

[Domenic Denicola]

Thanks all for the comments here.

> One more question - this applies to both <link rel=prefetch> and speculation rules, right?

This mostly does not apply to speculation rules, which has its own prefetch cache separate from the HTTP cache. There is some interaction, which is that previously, if a non-2xx response was speculation rules-prefetched, we would still HTTP cache it for 5 minutes due to this code. (Because the request was categorized as a prefetch, and thus the 5-minute rule applied.) That was what caused web developer pain.

> Refreshing my memory, as it's been a while - shipping this means that web developers would need to set their HTML's caching headers to be cacheable (even with a short lifetime) to ensure that prefetches are actually useful?

To the extent that developers are using <link rel=prefetch> on HTML, yes. Yoav's data in the OP shows it's mostly being used for subresources, and best practice is already to set good caching headers for those.

(Also, note that even if they don't set a max-age, they can get some benefit from setting an Etag or Last-Modified.)

> Should we add some console logs (and maybe web-exposed reports) on prefetches that are not cacheable? (as a followup) 

I agree that signaling this might be useful. I've filed https://issues.chromium.org/issues/381742467 to track that.