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.
