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).
On 4/29/25 2:20 PM, Patrick Meenan wrote:
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).
On Tue, Apr 29, 2025 at 10:52 AM Mike Taylor <miketa...@chromium.org>
wrote:
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
On 4/23/25 10:46 AM, Patrick Meenan wrote:
Contact emails
pmee...@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
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22>
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
<https://www.chromium.org/for-testers/providing-network-details/>
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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
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
<https://chromestatus.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+unsubscr...@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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w50QC8Vj9qUT_eyAdz2nFx2jEW0033KFeDeM6v%3D4J-mKw%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 blink-dev+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bace2afd-2bd8-4218-a459-fcf58b7ef46f%40chromium.org.
