The level of importance for the healthy operation of the web is opinion and debatable but for everything that is determined to be pervasive and safe to include, it will marginally increase the reliability and/or performance of that item loading. Likely fractions of a percent improvement in things like conversion measurement, successful checkouts or recaptcha challenges succeeding. Unlikely to be noticed in individual samples but meaningful for the web at scale. My personal opinion is that these marginal improvements are important for the overall health of the web but others may disagree (or determine that the benefits are not worth the complexity).
As far as disk space goes, the overall cache size is a concern on lower-end devices but it's not clear how much this will improve any individual user's cache. There is probably a lot that could be done in that space to age-out stale versioned resources and prioritize render-blocking resources but it's another marginal cost that we can recover. As far as maintaining the list long-term, there has been a fair bit of thought put into the process. The list itself has an expiration to make sure we don't get stuck with stale copies if, for some reason, it stops being maintained (yeah, I'm still sore about reader). There is tooling to automate the building of the candidate list and there are plans to improve the automation around filtering the list for patterns to make it much easier to update. It will also be in the git repo so it's not restricted to the core maintainers to keep it updated (i.e. if a provider has a pattern that is in the candidate list but hasn't been added yet, they can submit a CL). The list of patterns is expected to be pretty stable once the initial build-out has been completed though since the patterns are expected to be long-lived and popularity at that scale doesn't change quickly (the privacy protections require the stability to prevent history sniffing). On Wed, Oct 22, 2025 at 11:49 AM Daniel Bratell <[email protected]> wrote: > Thanks for pointing out Mozilla's response. I think they have some fair > points. > > If we look at the list, it is clear from domain names, that some sites, or > entities, will benefit more from others from faster first-loads. I mean, > something like 30% of the list are from Google entities, from very harmless > (IMHO) hosted fonts to analytics, ads and video hosting (YouTube). Some > other big sites like Shopify and Wix/parastorage combine to another 15%. > > Having your key resources on that list may not matter very much, or it > may. The existence of the list is scary and I lack the data to understand > what the pros are both in scale and area. Is the disk space issue a real > problem or just something that is a potential concern lacking > investigation, for instance? > > I understand that the published list is not a final, set-in-stone, item, > so I will not comment on individual items, but what thought have there been > on maintaining such a list long term? It seems to me that it might become > an area of contention that would be nice to avoid. > > In the initial intent, the claim was that this is important for the > healthy operation of the web. But is it really? > > /Daniel > On 2025-10-22 15:43, Patrick Meenan wrote: > > FYI, I updated Chromestatus with Mozilla's position on the feature > (strongly negative). It's not a platform-exposed feature but they do have > concerns that they wanted to note in a position issue > <https://github.com/mozilla/standards-positions/issues/1231>. > > On Sat, Oct 18, 2025 at 8:34 AM Patrick Meenan <[email protected]> > wrote: > >> Sorry, I missed a step in making the candidate resource list public. I >> have moved it to my chromium account and made it public here >> <https://docs.google.com/spreadsheets/d/1TgWhdeqKbGm6hLM9WqnnXLn-iiO4Y9HTjDXjVO2aBqI/edit?usp=sharing>. >> >> >> Not everything in that list meets all of the criteria - it's just the >> first step in the manual curation (same URL served the same content across >> > 20k sites in the HTTP Archive dataset). >> >> The manual steps frome there for meeting the criteria are basically: >> >> - Cull the list for scripts, stylesheets and compression dictionaries. >> - Remove any URLs that use query parameters. >> - Exclude any responses that set cookies. >> - Identify URLs that are not manually versioned by site embedders (i.e. >> the embedded resource can not get stale). This is either in-place updating >> resources or automatically versioned resources. >> - Only include URLs that can reliably target a single resource by pattern >> (i.e. ..../<hash>-common.js but not ..../<hash>.js) >> - Get confirmation from the resource owner that the given URL Pattern is >> and will continue to be appropriate for the single-keyed cache >> >> >> >> On Fri, Oct 17, 2025 at 7:02 PM Patrick Meenan <[email protected]> >> wrote: >> >>> Assuming we have the privacy and security concerns under control (which >>> we're pretty confident is the case for the extremely small subset of >>> resources we are talking about), the main discussion point is the balancing >>> of incentives and "playing favorites". >>> >>> As you noted, the performance impact is relatively small but it's not >>> non-zero when you get to the scale of some of the resources we are talking >>> about (like https://www.google-analytics.com/analytics.js which is on >>> 10M of the pages in the 50M page HTTP Archive dataset). This isn't really a >>> framework discussion because those kinds of resources aren't a good fit for >>> the restrictions that are in place for the privacy and security protections >>> but there is a discussion about providing network benefits to specific >>> third-parties that cross the pervasive threshold and meet the rest of the >>> conditions (for at least part of the library). >>> >>> The question is if the marginal performance benefit that can only be >>> realized at that level of scale (where a given user would be likely to have >>> the current version of that specific library in cache) would be a >>> meaningful competitive factor for a newcomer (vs features, ease of use, >>> pricing, mindshare, etc). >>> >>> That also gets balanced against the user benefit of not having to keep >>> re-downloading the exact same thing and from having to keep dozens of >>> copies of it in cache, cached with different cache keys (taking cache space >>> away from other resources). >>> >>> There's also a more nuanced benefit that allows for federation of a >>> feature across domains vs centralizing the experience. For example, Shopify >>> and Wix's platform libraries show up in the candidate list as they are used >>> by hundreds of thousands of sites in the CrUX dataset. Having a shared >>> cache for those libraries would put them into a more competitive position >>> against centralized platforms (Amazon, Etsy, Blogger, etc) while still >>> allowing sites to own the overall experience. >>> >>> I guess that's the long way of saying "it's complicated but we feel >>> pretty strongly that the theoretical risk in this case is more than offset >>> by the platform benefits". >>> >>> On Fri, Oct 17, 2025 at 5:15 PM Patrick Meenan <[email protected]> >>> wrote: >>> >>>> Nothing is being pre-populated (other than the list of URL patterns). >>>> When a "pervasive" resource is encountered naturally by a given user, it >>>> will be stored in a single-keyed cache instead of a site/frame/url-keyed >>>> cache (reducing storage duplication for that specific resource for that >>>> specific user). >>>> >>>> The linked doc has all of the mitigations in place, but the big one for >>>> explicit tracking is that it can only be used when full cookie access is >>>> also allowed, otherwise it falls through to the fully-partitioned cache. >>>> >>>> On Fri, Oct 17, 2025 at 4:58 PM Alex Russell <[email protected]> >>>> wrote: >>>> >>>>> This is interesting, given all of the problems involved in governance >>>>> and the way it cuts against platform progress >>>>> <https://infrequently.org/2022/03/cache-and-prizes/>. Will the full >>>>> set be downloaded before any pre-population is used? What controls will be >>>>> in place to make sure that this does not exacerbate cross-site tracking >>>>> via >>>>> timing? Will these caches be pushed in a versioned way? Who will make the >>>>> call about how much can be in the set? And are these delivered via >>>>> component-updater? >>>>> >>>>> Best, >>>>> >>>>> Alex >>>>> >>>>> On Friday, October 17, 2025 at 1:44:19 PM UTC-7 Patrick Meenan wrote: >>>>> >>>>>> I expect it will change over time but the changes should be pretty >>>>>> minor (as new resources increase or decrease popularity). Generally we'd >>>>>> want to include resources that have been common for a while and are >>>>>> likely >>>>>> to continue to be common. I'd expect small changes every milestone (or >>>>>> two). There's also the [email protected] mailing list >>>>>> that you can ping to give us a heads-up (or a CL to Chromium) if there's >>>>>> something specific you want to draw attention to. >>>>>> >>>>>> On Fri, Oct 17, 2025 at 4:33 PM Ben Kelly <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thank you. Do you expect the list of resources to change over >>>>>>> time? Will http archive data be analyzed for every milestone release? >>>>>>> >>>>>>> *From: *Patrick Meenan <[email protected]> >>>>>>> *Date: *Friday, October 17, 2025 at 4:30 PM >>>>>>> *To: *Ben Kelly <[email protected]> >>>>>>> *Cc: *blink-dev <[email protected]> >>>>>>> *Subject: *Re: [blink-dev] Intent to ship: Cache sharing for >>>>>>> extremely-pervasive resources >>>>>>> >>>>>>> This Message Is From an External Sender >>>>>>> >>>>>>> Yes. The list will be committed directly to the Chromium repository. >>>>>>> The list of candidate resources (before the manual vetting) is in a >>>>>>> sheet >>>>>>> here >>>>>>> <https://urldefense.com/v3/__https://docs.google.com/spreadsheets/d/1hXYVqwHQJJVTJ3LnKwMZiGF-eFGHc1J8y8k3Xc7h8zc/edit?usp=sharing__;!!Bt8RZUm9aw!5dVWGFYASzLWqT-IVHrc7lq1pVJyQ3AMs4O-AkEt6daUAkc_lPuOdm000ap-M0eOLyAF5EjjHFZsGcbwoQ$> >>>>>>> . >>>>>>> >>>>>>> On Fri, Oct 17, 2025 at 4:15 PM Ben Kelly <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> Will the list of manually curated scripts be published somewhere? I >>>>>>> did not immediately see something like this skimming the doc or chrome >>>>>>> status entry. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Ben >>>>>>> >>>>>>> *From: *Patrick Meenan <[email protected]> >>>>>>> *Date: *Friday, October 17, 2025 at 3:12 PM >>>>>>> *To: *blink-dev <[email protected]> >>>>>>> *Subject: *[blink-dev] Intent to ship: Cache sharing for >>>>>>> extremely-pervasive resources >>>>>>> >>>>>>> This Message Is From an External Sender >>>>>>> >>>>>>> *Contact emails* >>>>>>> [email protected] >>>>>>> >>>>>>> *Specification* >>>>>>> *N/A* >>>>>>> >>>>>>> *Design docs* >>>>>>> >>>>>>> https://docs.google.com/document/d/1xaoF9iSOojrlPrHZaKIJMK4iRZKA3AD6pQvbSy4ueUQ/edit?usp=sharing >>>>>>> <https://urldefense.com/v3/__https://docs.google.com/document/d/1xaoF9iSOojrlPrHZaKIJMK4iRZKA3AD6pQvbSy4ueUQ/edit?usp=sharing__;!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJhFCuXRtQ$> >>>>>>> >>>>>>> *Summary* >>>>>>> For a small number (hundreds) of hand-curated static third-party >>>>>>> script, stylesheet and compression-dictionary resources that are used >>>>>>> on a >>>>>>> large portion of the web, Chrome will use a single-keyed HTTP cache to >>>>>>> store those resources. >>>>>>> >>>>>>> This helps users and site owners with faster performance for those >>>>>>> resources that are very widely used while maintaining the privacy >>>>>>> protections of the partitioned disk cache. This feature targets the >>>>>>> resources that most users are likely to see multiple times across >>>>>>> multiple >>>>>>> sites in any given browsing session. They are usually not in the >>>>>>> critical >>>>>>> path of the page loading and may not impact the common performance >>>>>>> metrics >>>>>>> but they are still important for the healthy operation of the web. >>>>>>> >>>>>>> The list of candidate resources is manually curated from the HTTP >>>>>>> Archive dataset and updated on an ongoing basis. This includes >>>>>>> site-independent things like common analytics scripts, social media >>>>>>> embeds, >>>>>>> video player embeds, captcha providers and ads libraries. >>>>>>> >>>>>>> It allows for code that uses versioned URLs as long as the >>>>>>> versioning is not a manual process by embedders and that the same >>>>>>> version >>>>>>> is sent to everybody at a given point in time with the same contents. >>>>>>> This >>>>>>> does not include things like common Javascript libraries where they are >>>>>>> commonly self-hosted or where the URL references a specific version of >>>>>>> the >>>>>>> library and it is up to site owners to manually select a version. >>>>>>> >>>>>>> i.e. >>>>>>> >>>>>>> Yes: https://maps.googleapis.com/maps-api-v3/api/js/62/5d/common.js >>>>>>> <https://urldefense.com/v3/__https://maps.googleapis.com/maps-api-v3/api/js/62/5d/common.js__;!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJgSqmyqgQ$> >>>>>>> No: >>>>>>> https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js >>>>>>> <https://urldefense.com/v3/__https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js__;!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJj4u2iLCA$> >>>>>>> >>>>>>> *Blink component* >>>>>>> Blink>Network >>>>>>> <https://urldefense.com/v3/__https://issues.chromium.org/issues?q=customfield1222907:*22Blink*3ENetwork*22__;JSUl!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJhr_KK6BQ$> >>>>>>> >>>>>>> *Web Feature ID* >>>>>>> *No information provided* >>>>>>> >>>>>>> *Risks* >>>>>>> >>>>>>> >>>>>>> *Interoperability and Compatibility* >>>>>>> This change is internal to Chrome and should be completely >>>>>>> transparent to the web platform with no interoperability risks. >>>>>>> >>>>>>> *Gecko*: N/A >>>>>>> >>>>>>> *WebKit*: N/A >>>>>>> >>>>>>> *Web developers*: No signals >>>>>>> >>>>>>> *Other signals*: >>>>>>> >>>>>>> *Ergonomics* >>>>>>> N/A >>>>>>> >>>>>>> *Activation* >>>>>>> N/A >>>>>>> >>>>>>> *Security* >>>>>>> Cache partitioning added a level of privacy protection that is being >>>>>>> disabled for a small number of resources where it is deemed safe to do >>>>>>> so. >>>>>>> The linked document and issue provide the details on the protections >>>>>>> that >>>>>>> are in place to minimize the privacy exposure. >>>>>>> >>>>>>> *WebView application risks* >>>>>>> >>>>>>> *Does this intent deprecate or change behavior of existing APIs, >>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>> applications?* >>>>>>> *No* >>>>>>> >>>>>>> >>>>>>> *Debuggability* >>>>>>> N/A >>>>>>> >>>>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>> Yes >>>>>>> >>>>>>> *Is this feature fully tested by **web-platform-tests >>>>>>> <https://urldefense.com/v3/__https://chromium.googlesource.com/chromium/src/*/main/docs/testing/web_platform_tests.md__;Kw!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJhS1gEv1Q$>* >>>>>>> *?* >>>>>>> N/A >>>>>>> >>>>>>> *Tracking bug* >>>>>>> https://issues.chromium.org/u/1/issues/404196743 >>>>>>> <https://urldefense.com/v3/__https://issues.chromium.org/u/1/issues/404196743__;!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJiGnAFnbw$> >>>>>>> >>>>>>> *Measurement* >>>>>>> The success of this feature will be measured directly with the >>>>>>> owners of a small number of targeted scripts with a web-exposed >>>>>>> experiment. >>>>>>> >>>>>>> *Estimated milestones* >>>>>>> Shipping on desktop >>>>>>> 144 >>>>>>> DevTrial on desktop >>>>>>> 138 >>>>>>> Shipping on Android >>>>>>> 144 >>>>>>> DevTrial on Android >>>>>>> 138 >>>>>>> Shipping on WebView >>>>>>> 144 >>>>>>> >>>>>>> >>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>> https://chromestatus.com/feature/5202380930678784 >>>>>>> <https://urldefense.com/v3/__https://chromestatus.com/feature/5202380930678784__;!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJhn6bDIkw$> >>>>>>> >>>>>>> This intent message was generated by Chrome Platform Status >>>>>>> <https://urldefense.com/v3/__https://chromestatus.com/__;!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJhgyzRyUg$> >>>>>>> . >>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> To view this discussion visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w6%2BOj%2BOOHa1PHp-9auhEBJRGyyLZGWYaJeC3w-E9Y07-g%40mail.gmail.com >>>>>>> <https://urldefense.com/v3/__https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w6*2BOj*2BOOHa1PHp-9auhEBJRGyyLZGWYaJeC3w-E9Y07-g*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!Bt8RZUm9aw!-6GuUS4M8m3Eym1K4Y1Vts7sGxQ5HhifoRFNweoIoUZ-dzRbuYLifuL-fX5yWDeuNmOQnc25VJglThdCkw$> >>>>>>> . >>>>>>> >>>>>>> -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w73DpKeFRJ9jPEQ_jVZh0y01kZvx2iZzRg_Z8ZL%2B_f93Q%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w73DpKeFRJ9jPEQ_jVZh0y01kZvx2iZzRg_Z8ZL%2B_f93Q%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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w6txKVPW%3DZk%3Dv-tD3zHP%3Dg7531LxbpGA%3DwyP9VJRBV47A%40mail.gmail.com.
