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 On Fri, Jan 13, 2023 at 1:13 AM Noam Rosenthal <nrosent...@chromium.org> wrote: > Contact emails > > nrosent...@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 > <https://docs.google.com/spreadsheets/d/1iGYYbwaXUSxvPHH7Cl-IuxmIH6eMHDgWTLpH2pwDCUA/edit?usp=sharing> > 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 > <https://docs.google.com/spreadsheets/d/1N7fHysHI-Yx1taBppcGN3Z_DK8Y--fc4XZmtesIrMp4/edit#gid=0> > 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 > <https://groups.google.com/a/chromium.org/g/blink-dev/c/eduycCpm5ws/m/ddZufPhcAgAJ> > . > > 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 > <https://github.com/WebKit/standards-positions/issues/114> 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 <https://chromestatus.com/feature/5740655424831488> 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 > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? > 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 <http://www.chromestatus.com/> > > https://chromestatus.com/feature/5087526916718592 > > -- > 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/CAJn%3DMYa7YN%3DdePW5E9LQ2Qpo72r2h3m%3DVKdXfTg910U7AC51_w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYa7YN%3DdePW5E9LQ2Qpo72r2h3m%3DVKdXfTg910U7AC51_w%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/CAFUtAY-1NCvS0kjeN2-agq2o5q1gHY%2BW%2BVzVV4N9v7EQaC3NiA%40mail.gmail.com.
