Intent to ship: Cache sharing for extremely-pervasive resources

[Patrick Meenan]

Contact emails

pme...@chromium.org

Specification

N/A

Design docs

https://docs.google.com/document/d/1xaoF9iSOojrlPrHZaKIJMK4iRZKA3AD6pQvbSy4ueUQ/edit?usp=sharing

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

No: https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.min.js

Blink component

Blink>Network

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?

N/A

Tracking bug

https://issues.chromium.org/u/1/issues/404196743

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

This intent message was generated by Chrome Platform Status.

[Ben Kelly]

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 <pme...@chromium.org>
Date: Friday, October 17, 2025 at 3:12 PM
To: blink-dev <blin...@chromium.org>
Subject: [blink-dev] Intent to ship: Cache sharing for extremely-pervasive resources

This Message Is From an External Sender

 

--
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+...@chromium.org.
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.

[Patrick Meenan]

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.

[Ben Kelly]

Thank you.  Do you expect the list of resources to change over time?  Will http archive data be analyzed for every milestone release?

[Patrick Meenan]

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 pervasi...@chromium.org 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.

[Alex Russell]

This is interesting, given all of the problems involved in governance and the way it cuts against platform progress. 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 pervasive-cache@chromium.org 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.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Patrick Meenan]

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 <sligh...@chromium.org> wrote:

This is interesting, given all of the problems involved in governance and the way it cuts against platform progress. 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 pervasi...@chromium.org 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.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Patrick Meenan]

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".

[Patrick Meenan]

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.

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