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
On 4/30/25 11:34 AM, Patrick Meenan wrote:
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.
On Wed, Apr 30, 2025 at 11:29 AM Mike Taylor <miketa...@chromium.org>
wrote:
Yeah, probably. Jason, are you able to do some backend magic to
convert the chromestatus type?
On 4/30/25 10:33 AM, Patrick Meenan wrote:
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?
On Wed, Apr 30, 2025 at 7:01 AM Mike Taylor
<miketa...@chromium.org> wrote:
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/5d3027fc-e6a9-43d3-9df7-b947cf90cbed%40chromium.org.
