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/CAPq58w6mrXxsywCU%3DmR2_f5H74rvoOZoQ7GYn%3DzqGhGEjAfwnw%40mail.gmail.com.
