v146 · Web APIs · HTTP Cache

Cache sharing for extremely pervasive resources

Chrome 146 re-enables cross-site cache sharing for a small set of extremely pervasive resources — provider-hosted scripts and embeds so widely deployed that sharing their cached copies is unlikely to be used for cross-site tracking.

background

Chrome 86 introduced partitioned HTTP caches, isolating each site's cache under a double-key (top-level origin + resource origin). This closed a timing-based cross-site tracking vector but also removed the performance benefit of sharing popular provider resources — every site that loads the same common analytics, social, video-player, captcha, or ads script normally fetches it separately.

Chrome 146 adds a narrow exception: an allowlist of resources so widely deployed (billions of loads per day across millions of sites) that cross-site cache sharing is granted because the tracking risk is negligible compared to the performance benefit.

concepts

  1. Cache Demo

    Uses the Cache API and fetch timing to illustrate cache hit versus miss behaviour — how a second load of the same resource can complete near-instantly when served from the shared cache.

  2. Pervasive Resources

    What makes a resource "extremely pervasive", which resources currently qualify, and the privacy/performance tradeoff that determines membership.

  3. Cache key explorer

    Pick a top-level site and a resource URL — the explorer shows the double-keyed partition before 146 next to the single shared bucket from 146, plus a running tally of duplicate fetches the allowlist saves.

  4. Resource Savings Calculator

    Select eligible provider resources and common-but-excluded rows with editable KB sizes. Enter daily visitor and pages-per-visit counts, then tune partitioned vs cross-site hit rates with sliders. The calculator shows bytes transferred under each regime, percentage reduction, CO₂ saved, and per-resource bar charts comparing partitioned versus shared cache performance.

the change

// Before Chrome 146: every site fetches its own copy
// Cache key: (site-A.example, www.googletagmanager.com/gtag/js)
// Cache key: (site-B.example, www.googletagmanager.com/gtag/js)
// → Two separate network requests, two cache entries

// Chrome 146+: pervasive resources share one cache entry
// Cache key: (SHARED, www.googletagmanager.com/gtag/js)
// → site-A fetches once; site-B gets the cached copy

// No developer action required — Chrome handles the keying.
// The allowlist is maintained by Chrome and updated over time.

// You can observe it via Resource Timing:
const [entry] = performance.getEntriesByName(
  'https://www.googletagmanager.com/gtag/js'
);
console.log(entry.transferSize); // 0 if served from cache

references