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. On Thu, Nov 28, 2024 at 8:03 PM Barry Pollard <barrypoll...@google.com> wrote: > +Tze Yi Tan <tze...@google.com> > > 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 <dome...@google.com> , 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? > > On Thu, 28 Nov 2024 at 10:26, Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> Also, seems worthwhile for +Barry Pollard <barrypoll...@google.com> or >> someone else to make some noise on that front.. >> >> On Thu, Nov 28, 2024 at 11:22 AM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> >>> >>> On Thu, Nov 28, 2024 at 11:19 AM Noam Rosenthal <nrosent...@chromium.org> >>> wrote: >>> >>>> On Thu, Nov 28, 2024 at 10:11 AM Yoav Weiss (@Shopify) >>>> <yoavwe...@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? >>>> >>> >>> 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. >>> >>> -- 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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_L8Ynh5ivgq7_RLNWA-4L1Ss6DcfFCgZbNHucLtNg4Rw%40mail.gmail.com.
