demo · v146

Cache key explorer

Pick a top-level site and a sub-resource URL. The explorer shows the cache key Chrome would use before 146 (double-keyed, partitioned per top-level origin) and the key it uses now (single shared bucket if the resource is on the pervasive-resource allowlist). Same byte-identical jQuery, two completely different storage outcomes.

The change here is invisible to JavaScript — there is no navigator.cacheSharingState API. But the HTTP cache is keyed by a tuple, and the tuple changes shape for allowlisted URLs. This explorer makes the tuple visible.

0entries added
0shared keys
0duplicate fetches saved

Cache keys

Allowlist sample

Chrome ships and updates the allowlist itself. These are representative entries based on the explainer's "extremely pervasive" criteria (billions of cross-site loads, no third-party cookies set, content-hashed URLs).

What the explorer is showing

  1. Before 146 every entry uses the partitioned key (top-level site, resource URL). Two sites loading the same byte-identical file means two cache entries, two downloads.
  2. From 146 onward, when the resource URL matches the pervasive-resource allowlist, the key becomes (SHARED, resource URL). Every site uses the same bucket.
  3. The first site to load the resource fills the bucket; every later site gets a hit, regardless of which site is on top.
  4. Resources not on the allowlist keep the double-keyed behaviour — no privacy regression.
// Before 146 — partitioned
key = (topLevelSite, resourceURL)

// 146+ — pervasive resources only
if (pervasiveAllowlist.has(resourceURL)) {
  key = ("SHARED", resourceURL);
} else {
  key = (topLevelSite, resourceURL);
}

see also