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/CAJSLZa2U1-bEC69Ri08JOefO5EPZ95GWrVZ8OSQft2fDj%3DoQ_w%40mail.gmail.com.
