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

241 views
Skip to first unread message

Noam Rosenthal

unread,
Jan 13, 2023, 1:13:10 AM1/13/23
to blink-dev

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

unread,
Jan 13, 2023, 11:56:00 AM1/13/23
to Noam Rosenthal, blink-dev
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

unread,
Jan 13, 2023, 12:19:11 PM1/13/23
to Rick Byers, Noam Rosenthal, blink-dev
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.

 

Noam Rosenthal

unread,
Jan 13, 2023, 11:11:53 PM1/13/23
to Yoav Weiss, Rick Byers, blink-dev
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

unread,
Jan 18, 2023, 9:54:10 AM1/18/23
to Noam Rosenthal, Yoav Weiss, Rick Byers, blink-dev

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.

Yoav Weiss

unread,
Apr 24, 2023, 9:02:09 AM4/24/23
to Noam Rosenthal, blink-dev, Daniel Bratell, Rick Byers, Noam Rosenthal
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

unread,
Apr 24, 2023, 11:58:20 AM4/24/23
to blink-dev, Daniel Bratell, Rick Byers, blink-dev, Noam Rosenthal, Yoav Weiss
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

unread,
May 1, 2023, 2:06:17 AM5/1/23
to blink-dev, Noam Rosenthal, Daniel Bratell, Rick Byers, blink-dev, Noam Rosenthal, Yoav Weiss
Additional LGTMs?

Mike Taylor

unread,
May 1, 2023, 10:15:46 AM5/1/23
to Noam Rosenthal, blink-dev, Noam Rosenthal, Daniel Bratell, Rick Byers, Yoav Weiss

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

Noam Rosenthal

unread,
May 1, 2023, 10:16:54 AM5/1/23
to Mike Taylor, Noam Rosenthal, blink-dev, Daniel Bratell, Rick Byers, Yoav Weiss
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

unread,
May 1, 2023, 10:19:27 AM5/1/23
to Noam Rosenthal, Noam Rosenthal, blink-dev, Daniel Bratell, Rick Byers, Yoav Weiss
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

unread,
May 1, 2023, 10:21:18 AM5/1/23
to Mike Taylor, Noam Rosenthal, blink-dev, Daniel Bratell, Rick Byers, Yoav Weiss
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.
 
Reply all
Reply to author
Forward
0 new messages