Compression dictionary transport on a CDN lets a browser tell the edge which earlier file it already holds, so the next version of that file ships as a delta of a few kilobytes instead of a fresh Brotli stream. It is standardised as RFC 9842 (September 2025) and live in Chrome and Edge from version 130. On a CDN, though, it is a cache-key and origin problem before it is a compression one: until the edge does the compressing, your origin must produce the deltas, and the CDN must key on a header most configurations ignore.
How compression dictionary transport works
The origin marks a response as reusable with a Use-As-Dictionary header. Its required match parameter is a URL pattern such as /js/app.*.js; optional match-dest, id and type narrow it further, and raw is the only type defined. The browser stores the bytes. On the next request matching that pattern it adds dcb and dcz to Accept-Encoding and sends Available-Dictionary, a structured-field byte sequence holding the SHA-256 of the stored file, plus Dictionary-ID if the origin set an id.
A server holding that dictionary answers with Content-Encoding: dcb (Brotli against the dictionary) or dcz (Zstandard against it). Any other server ignores the header and sends ordinary br, so the fallback is free. A page can also prime a purpose-built dictionary with <link rel="compression-dictionary">, which the browser fetches when idle. Dictionaries are same-origin only.
What the savings look like
The win is largest for versioned bundles redeployed often, where the new build differs from the old by a few functions. Chrome's developer blog reports ratios of 90 per cent or better in some cases; DebugBear, compressing Bootstrap 5.3.3's minified CSS against 5.2.3, measured up to 76 per cent below the plain download. First visits gain nothing, and since Firefox and Safari do not ship it, a share of your traffic never will. Treat it as a repeat-visitor optimisation and size the prize from your returning-user share before you build anything. Our survey of Brotli and Zstandard at the edge covers the cold-cache baseline it improves on.
Who compresses: origin or edge
Today the delta is almost always made at the origin and carried through the CDN. That is the model in Patrick Meenan's CDN implementation notes, and it is what the first productised support does.
| Platform | Published position | What the origin must do |
|---|---|---|
| Cloudflare | Passthrough in open beta on all plans since 30 April 2026 | Produce dcb/dcz; Cloudflare forwards the headers, does not recompress, and varies its cache on them |
| CloudFront | Passes a custom Content-Encoding through and caches it, per Meenan's notes | All compression, with CloudFront's automatic compression switched off |
| Fastly | Its compression blog lists the feature as under evaluation | Everything, with key and Vary handling configured by you |
Cloudflare's documentation is explicit that passthrough generates no dictionaries and computes no deltas: switch it on without an origin that speaks dcb or dcz and nothing gets smaller. It also lists the setting as incompatible with its Version Management feature.
The cache key is where it breaks
A dcb body is undecodable without the exact dictionary it was made against. RFC 9842 therefore requires Vary: Accept-Encoding, Available-Dictionary on dictionary-compressed responses. A shared cache that drops that Vary, or keys only on a normalised Accept-Encoding, will hand one user's delta to another user and break the page. Read how Vary widens a cache key before you trust a default.
Two quieter failures follow. Some CDNs collapse Accept-Encoding to a short list such as gzip and br before keying; if yours does, dcb and dcz vanish before the origin sees them and the feature silently never fires. And keying on the raw hash invites fragmentation: every stale bundle version in the wild is a separate variant of the same URL. Serve deltas only against the last one or two releases, and where your edge can run logic, blank any Available-Dictionary value outside that allowlist so unknown hashes collapse onto the single br variant.
Older blog posts written against the drafts name sbr and Sec-Available-Dictionary. Those identifiers were replaced in the final RFC; configure for the standard names.
Should you turn it on in 2026?
Yes, if three things hold: you ship versioned JavaScript or CSS bundles at least weekly, a large share of your traffic is returning Chromium users, and your build can emit dcb or dcz deltas against the previous release. Then the work is a build step, a Use-As-Dictionary header, the Vary pair and an allowlist at the edge, followed by a check of the cache key with our guide to designing cache keys. If you deploy monthly, or your CDN cannot vary on Available-Dictionary, wait for edge-side compression: the savings are real, but a misconfigured cache costs more than the bytes it saves.
Not sure whether your bundles, your audience and your CDN's cache key make dictionaries worth it? The assessment works it out from your traffic.