demo · v142

Stable ID vs TTL

Compression Dictionary Transport has two levers for keeping CDN cache variants bounded: TTL (expire old dictionaries after N seconds so stale Available-Dictionary headers stop generating new cache variants) and stable ID (reuse the same id= across deploys so the dictionary fingerprint stays constant). The TTL field in Chrome 142 is one of two; ID stability is the other.

Deployment cadence

Deploys per week 5
Active users (thousands) 10k
Visit frequency (visits/user/day) 2

Dictionary TTL (both strategies)

TTL (seconds) 86400 (1d)

TTL controls when the browser stops treating a dictionary as eligible for compression. In the stable-ID strategy, TTL also controls how long the single dictionary stays fresh.

Strategy A — New ID per deploy
—
CDN cache variants at peak
—
days to converge (after last deploy)
—
dict hit rate at 2 weeks
Strategy B — Stable ID across deploys
—
CDN cache variants at peak
—
days to converge (after last deploy)
—
dict hit rate at 2 weeks

Active CDN variants over time (weeks after last deploy):

When to use each lever

Stable ID: ship Use-As-Dictionary: match="/app.js", id="app" on every release. The browser tracks one dictionary fingerprint per id value; CDN sees only ever one variant of the Available-Dictionary value. Works best when your dictionary changes slowly (e.g. you're shipping the same base framework).

TTL (Chrome 142+): ship Use-As-Dictionary: ttl=86400 to expire old dictionary entries after 1 day. The browser stops advertising them in Available-Dictionary, so CDN stops accumulating variants. Works best when your dictionary changes often and you want automatic clean-up without coordinating IDs across releases.

Chrome 142 adds the ttl= parameter specifically to complement the existing ID mechanism — authors now have both levers and can mix strategies per resource type.

see also