For a small number (hundreds) of hand-curated static third-party script, stylesheet and compression-dictionary resources 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 resources that are very widely used while maintaining the privacy protections of the partitioned disk cache. This feature targets the resources 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.
Partitioning the HTTP cache solved the privacy concerns with shared resources but incurred a performance (and potentially revenue) impact on the web. This change claws back the bulk of the performance gains of a shared cache while maintaining the privacy protections of a partitioned cache.
Docs: https://docs.google.com/document/d/1xaoF9iSOojrlPrHZaKIJMK4iRZKA3AD6pQvbSy4ueUQ/edit?usp=sharing