Compression Dictionary Transport
Use a previously served response, or a dedicated dictionary, as a Brotli/Zstandard dictionary so updated assets compress to a fraction of their size. Pure progressive enhancement over ordinary compression.
What it is
Ordinary compression (gzip, brotli, zstd) shrinks each response against a small built-in dictionary. Compression Dictionary Transport, standardised as RFC 9842, lets the server nominate a custom dictionary — usually an earlier version of the same resource — so the next response only has to encode what actually changed.
A response advertises that it may serve as a dictionary:
Use-As-Dictionary: match="/app/*.js"
Content-Encoding: brOn a later request the browser sends the dictionary’s hash, and the server replies with a dictionary-compressed body:
Request:
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Accept-Encoding: dcb, dcz, br, gzip
Response:
Content-Encoding: dcb
Vary: Accept-Encoding, Available-DictionaryThe two new content codings are dcb (Dictionary-Compressed Brotli) and dcz (Dictionary-Compressed Zstandard).
Why it matters
Most deploys change a few lines in a large bundle. Against the previous build as a dictionary, the diff can compress an order of magnitude smaller than a standalone brotli pass — bytes for what changed, not the whole file. It is also pure progressive enhancement: a client that does not send Available-Dictionary simply receives the normal br or gzip response, so there is no fallback path to maintain and nothing breaks.
How to implement
Pick a dictionary strategy. Either let a versioned asset act as the dictionary for its own successor (match on the URL pattern), or ship a small dedicated dictionary referenced by a <link rel="compression-dictionary">.
Scope it with match / match-dest. Restrict each dictionary to the URL patterns and request destinations it actually helps, so the browser never offers an irrelevant dictionary.
Always vary on Available-Dictionary. A cache that ignores it will hand a dictionary-compressed body to a client that lacks the dictionary, which cannot decode it.
Lean on your CDN. This is server- and edge-layer behaviour; most sites enable it at the CDN rather than hand-rolling the headers.
Common mistakes
- Omitting
Available-DictionaryfromVary, poisoning shared caches with undecodable bodies. - Treating it as a substitute for ordinary compression. It is a layer on top — keep brotli/gzip on for the first, dictionary-less request.
- Over-broad
matchpatterns that nominate dictionaries the browser can never use, wasting a round of negotiation.
Verification
curl -H "Accept-Encoding: dcb, dcz, br" -H "Available-Dictionary: :<hash>:" -I https://example.com/app.js— check forContent-Encoding: dcb.- DevTools → Network → response headers: look for
Use-As-Dictionaryon the seed response anddcb/dczon the follow-up. - Browser support is still limited (Chromium-led); confirm your real audience benefits before investing in dedicated dictionaries.