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/CAPq58w6VXc-K%3DYaZkSryVj21z395qCBecvUu2zzbSm-ueCZD_g%40mail.gmail.com.
