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 <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. >> > 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% <https://chromestatus.com/metrics/feature/timeline/popularity/4314> of page views. > - 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-1NCvS0kjeN2-agq2o5q1gHY%2BW%2BVzVV4N9v7EQaC3NiA%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/CAL5BFfXX4NofaExOmp8eijA8Dxq5y5AX165_vgnoZ4OLC5L32Q%40mail.gmail.com.
