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: > 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. > > On Tue, Apr 29, 2025 at 2:20 PM Patrick Meenan <pmee...@chromium.org> > 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/CAPq58w5V%3DByzejfvmvPtWy_xMdQ39SGS-vBwAOq3HVtA2CCEng%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w5V%3DByzejfvmvPtWy_xMdQ39SGS-vBwAOq3HVtA2CCEng%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/990a0c7c-f508-4631-9077-f362d40458den%40chromium.org.
