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/b1889353-d4a3-41a1-9b51-9635a6943578%40gmail.com.
