Intent to Experiment: Cache sharing for extremely-pervasive scripts

[Patrick Meenan]

Contact emails

pme...@chromium.org

Specification

None

Design docs

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

Summary

For a small number (hundreds) of hand-curated static third-party scripts 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 scripts that are very widely used while maintaining the privacy protections of the partitioned disk cache. This feature targets the scripts 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 scripts is curated from the HTTP Archive dataset. 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.

Blink component

Blink>Network

TAG review

None

TAG review status

Not applicable

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?

None

Goals for experimentation

For the purposes of the experiment, we will target around a dozen of the most-impactful scripts (mostly ads and analytics) and work with the script owners to measure the resulting impact (on performance, reliability and business metrics).

If these scripts show minimal impact from using a shared cache then there is no value in the added complexity for the feature and it can be documented and closed.

If there is significant impact then it is likely worth pursuing further (and will also be documented for other similar efforts).

Ongoing technical constraints

None

Debuggability

The cache key used for any given resource is exposed in the netlog which can be used to verify if a given resource used the shared cache or not.

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?

No

Flag name on about://flags

None

Finch feature name

CacheSharingForPervasiveScripts

Non-finch justification

None

Requires code in //chrome?

False

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

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5202380930678784

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Hey Patrick,

This sounds related to a previous experiment (https://groups.google.com/a/chromium.org/g/blink-dev/c/9xWJK3IgJb4/m/SYLfUccOBgAJ) - could you describe how this experiment is similar or different (or perhaps builds upon the results from the previous experiment)?

thanks,
Mike

--
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/CAPq58w50QC8Vj9qUT_eyAdz2nFx2jEW0033KFeDeM6v%3D4J-mKw%40mail.gmail.com.

[Patrick Meenan]

The previous experiment required an exact match of a full URL and payload hash (on a path to automate allow-listing responses). Unfortunately, most of the interesting third-party resources are updated quite regularly (usually at least daily if not every few hours) so the URL list and payload hashes were both very stale by the time the experiment was run.

This experiment learned from those results and is targeting a MUCH smaller list of manually curated resources that are much more popular and uses a URLPattern to allow for versioned variants of the URLs (for things like the YT player JS or pubads_impl which include versions in the path) and removes the hash-matching requirement for the payload (for things like analytics.js which update in-place).

It won't impact as many third-party resources, by design, but the resources that it does impact are going to be MUCH more likely to be seen by most users multiple times within a browsing session (and within the update window for any of them).

[Daniel Herr]

Personally I'm not a fan of this idea of giving special performance boosts to big properties like YouTube or Google Ads. That's creating an unfair advantage over smaller players in the market. And I have to point out that Google is currently under antitrust scrutiny for allegedly doing such.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w5V%3DByzejfvmvPtWy_xMdQ39SGS-vBwAOq3HVtA2CCEng%40mail.gmail.com.

[Mike Taylor]

Thanks Patrick. It will be interesting to learn how the experiment goes, and any possible improvements, especially if resources are changing hourly.

I look forward to learning more about how sites will attest to always return the same payload, if the experiment proves successful.

One last question: which milestones are you requesting to run the experiment for? Your chromestatus entry doesn't indicate that - I think you need to add an experiment milestone (which is probably why this intent didn't show up in our review queue).

[Mike Taylor]

The design doc also links to https://docs.google.com/spreadsheets/d/1hW-xXj9zEdkTJMVE4b4qcflB00WxsOG72Y0LVtSjcWI/edit?gid=1602510613#gid=1602510613, and an HTTP archive query to produce it.

On 4/30/25 5:07 AM, Jxck wrote:

Experiment candidates in Design docs only includes

• google-analytics.com
• googlesyndication.com
• doubleclick.net
• googletagmanager.com
• googleapis.com
• youtube.com
• etc

Even if this list were based on a neutral data analysis, it can't help thinking that Chrome is intended to ship changes that are only benefits for Google's business.

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w50QC8Vj9qUT_eyAdz2nFx2jEW0033KFeDeM6v%3D4J-mKw%40mail.gmail.com.

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

[Patrick Meenan]

I'm hoping for 138 (code is in-flight now). I added 138 to the "dev trials section" but there doesn't appear to be any way to "experiment". The only stages that come after (or can be added) are shipping. Maybe because it's "No developer-facing change" for the feature type?

[Patrick Meenan]

As Mike mentioned, the design doc links to the spreadsheet with the full list of candidate URLs that should be considered IF this ever gets as far as shipping (as of February) as well as the query to generate the candidate list from the public HTTP Archive dataset for any month after January 2025 (when the response body hashes were added to the HTTP Archive dataset). There are scripts from a lot of different companies (Facebook, Microsoft, Wix, Wordpress, Yandex, Amazon, etc). The ones called out in the design doc are specific for running an experiment to gather data and see if there is any measurable benefit for even the most-pervasive resources from a partner that is well positioned to be able to measure the impact of something like a 1% Chrome experiment.

From the browser-side we're only likely to see small movement in some low-level metrics (like cache hit rate and bandwidth) but it's not likely to move LCP or other user-facing metrics that we observe but that doesn't mean there's no impact to the web (users, publishers and service providers) which is why we need a partner that can help fill in those details.

The partitioned cache was introduced in 2020 with the privacy benefits outweighing any potential performance impacts. This experiment hopes to quantify those impacts and see if there is a path to restoring the benefits while maintaining the privacy protections that came with the split cache.

If there is no impact (or it isn't enough to justify the complexity) then that's pretty much the end of the story for most of the efforts around shared caching (it keeps popping up in different contexts). It's not guaranteed that there will be significant benefits - it's not unusual for the disk cache to be slower than the network, even today.

If there IS an impact, then we can use the data from the result to weigh the benefits to the platform against the added complexity and determine what a path forward should look like (if there is one).

It's probably important to note that this is specifically only the HTTP disk cache for the request responses. The v8 code cache (where there are substantial benefits) continues to remain partitioned for security reasons (and was partitioned long before the HTTP cache).

On Wed, Apr 30, 2025 at 5:07 AM Jxck <jx...@chromium.org> wrote:

Experiment candidates in Design docs only includes

• google-analytics.com
• googlesyndication.com
• doubleclick.net
• googletagmanager.com
• googleapis.com
• youtube.com
• etc

Even if this list were based on a neutral data analysis, it can't help thinking that Chrome is intended to ship changes that are only benefits for Google's business.

On Wednesday, April 30, 2025 at 6:02:20 AM UTC+9 danielher...@gmail.com wrote:

[Mike Taylor]

Yeah, probably. Jason, are you able to do some backend magic to convert the chromestatus type?

[Patrick Meenan]

Is there a reason to change the chromestatus type? Presumably we'd want to be able to experiment with things that are internal and not developer-facing (and developers won't directly see any change from this). A lot of the Networking internals tend to fall into that bucket and it'd be nice (at least on some of them) to still go through the intent process for a heads-up.

[Jxck]

Experiment candidates in Design docs only includes

• google-analytics.com
• googlesyndication.com
• doubleclick.net
• googletagmanager.com
• googleapis.com
• youtube.com
• etc

Even if this list were based on a neutral data analysis, it can't help thinking that Chrome is intended to ship changes that are only benefits for Google's business.

On Wednesday, April 30, 2025 at 6:02:20 AM UTC+9 danielher...@gmail.com wrote:

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w50QC8Vj9qUT_eyAdz2nFx2jEW0033KFeDeM6v%3D4J-mKw%40mail.gmail.com.

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

[Mike Taylor]

No developer-facing changes implies no approvals[1], but you will need a mechanical API OWNER approval in the chromestatus entry to ship this change (and run the experiment). AIUI, the design doc mentions sites attesting to benefit from this feature, so there will be a new API involved at some point.

I'm happy to be wrong here, and welcome other API OWNERs to correct me.

[1] See https://www.chromium.org/blink/launching-features/#change-to-existing-code

[Patrick Meenan]

Sorry if the doc didn't make it clear - the "attesting" that the doc envisions isn't expected to be an API or anything in code - it's expected to be something along the lines of a legal agreement or at least manual verification and confirmation by the owners (process - whatever legal and privacy think would be appropriate for the few dozen companies it would apply to).