Chrome 146 enables cross-site cache sharing for a curated set of extremely pervasive provider resources. Estimate how much bandwidth changes when eligible analytics, social, video, captcha, and ads scripts can reuse a shared bucket while common but excluded resources stay partitioned.
1. Select Resources
2. Traffic Parameters
40%
75%
3. Results
Partitioned Cache (pre-v146)
—
Total bytes transferred / day
Cross-site Cache Sharing (v146)
—
Total bytes transferred / day
Bytes Saved / Day
—
Reduction
—
CO₂ Saved / Day
—
Breakdown by Resource
Partitioned (pre-v146)Shared (v146)
Security Tradeoffs & Eligibility Criteria
Why only "pervasive" resources?
Cache timing attacks: Cross-site cache sharing can leak whether a user previously visited a specific site (by measuring load time). Chrome mitigates this by requiring resources to be used on many sites — so membership of the pervasive set reveals nothing meaningful about individual browsing.
Eligibility threshold: The allowlist is curated from high-volume HTTP Archive patterns. Common analytics scripts, social embeds, video player embeds, captcha providers, and ads libraries are the representative eligible categories.
Explicit exclusions: Self-hosted copies and manually version-pinned framework/library URLs such as React, Vue, jQuery, Lodash, or Tailwind via npm CDN paths remain partitioned even if they are common.
URL exactness: Public cacheability and stable bytes still matter. Personalised query parameters, cookie-varying responses, and private wrapper bundles do not move into the shared bucket.
Not a silver bullet: Cross-site sharing is a one-time-download win, not a round-trip win. TTFB and network latency still apply for first-timers in a new browser profile.