Shared Dictionaries: Why Cloudflare Just Solved the AI Era's Biggest Compression Problem
Site Owner
Published on 2026-07-20
Cloudflare is bringing shared dictionary compression (RFC 9842) to production on April 30 — a delta-compression technique that turns a 272KB JS bundle into 2.6KB after a one-line change. After 18 years of failed attempts (SDCH in 2008, abandoned by Chrome in 2017), the new standard finally fixes the security and CORS issues that killed the first attempt. Here's how it works, why it took so long, and what changes for high-deploy web apps.
Shared Dictionaries: Why Cloudflare Just Solved the AI Era's Biggest Compression Problem
On April 17, 2026, Cloudflare published lab results showing a 272KB JavaScript bundle compressed to 2.6KB after a one-line change — a 97% reduction over what gzip already produced (Cloudflare Blog, 2026-04-17). The technique is called shared dictionaries, and it is finally going mainstream after 18 years of failed attempts to make it work on the open web.
The broader context matters more than the number. Pages have grown 6–9% heavier every year for a decade, and agents now drive nearly 10% of all requests on Cloudflare's network, up about 60% year-over-year (Cloudflare Blog). AI-assisted development has turned every team into a high-frequency deployer. Traditional gzip is not just inefficient — it is the wrong abstraction for a web where every file gets re-shipped several times a day.
Shared dictionaries fix that by treating the browser's cache as part of the compression algorithm.
The Problem Gzip Can't Solve
Every deploy re-chunks the bundle. Filenames change. The browser sees a new URL and starts from zero. Gzip compresses each transfer from scratch. It does not know the client already has 95% of the file cached.
That redundancy compounds. Cloudflare's blog post does the arithmetic: a 500KB bundle, deployed ten times a day, served to 100,000 daily users, costs 500GB of transfer. With shared dictionaries, that same workload drops to a few hundred megabytes — a 99.9% reduction on the wire.
The cache hit rate suffers for the same reason. Responses vary on both encoding and dictionary hash, so every dictionary version creates a separate cache variant. Mid-deploy, you have clients with the old dictionary, clients with the new one, and clients with none. Hit rates drop. Storage climbs.
#Cloudflare#前端工程#AI 基础设施
Gzip cannot fix this. It has no concept of "the version the client already has." What the web needs is delta compression, where the previously cached version of a resource becomes the dictionary for the next one.
What Shared Dictionaries Actually Do
A compression dictionary is a shared reference between server and client. Instead of compressing a response from scratch, the server says "you already know this part of the file because you've cached it before" and only sends what is new. The client holds the same reference and reconstructs the full response during decompression.
The protocol looks like this. When the server first serves a resource, it attaches a Use-As-Dictionary response header, telling the browser to hold onto the file because it will be useful later. On the next request for that resource, the browser sends an Available-Dictionary header back, telling the server what it already has. The server compresses the new version against the old one and sends only the diff. No separate dictionary file. No origin-side bookkeeping required for the basic case.
The savings persist across the entire release history. Version three compresses against version two. Version forty-seven compresses against version forty-six. The bundle does not have to be the same kind of file each time — Cloudflare's internal test used a 272KB asset that came down to 92.1KB under gzip and 2.6KB under DCZ, the new content encoding for dictionary-compressed Zstandard.
The download times matter more than the file sizes. On a cache miss, the DCZ-compressed response finished in 31ms versus 166ms for gzip — an 81% improvement. On a cache hit, 16ms versus 143ms — an 89% improvement. The response is so much smaller that even when you pay a slight penalty at the start for dictionary lookups, you finish far ahead.
Why This Took 18 Years
Shared dictionaries are not new. Google shipped the first version, Shared Dictionary Compression for HTTP (SDCH), in Chrome in 2008. Early adopters reported double-digit improvements in page load times. SDCH then accumulated problems faster than anyone could fix them.
The most memorable failure was a class of compression side-channel attacks called CRIME and BREACH. Researchers showed that if an attacker could inject content alongside something sensitive — a session cookie, an auth token — the size of the compressed output leaked information about the secret. The attacker could guess a byte at a time, watch whether the asset shrank, and extract the entire secret.
Security was not the only problem. SDCH violated the Same-Origin Policy, which ironically was part of why it performed so well. Its cross-origin dictionary model could not be reconciled with CORS. It lacked specification around interactions with the Cache API. By 2017, Chrome — the only browser that supported SDCH at that point — unshipped it.
Getting the web community to pick up the baton took a decade. The modern standard, RFC 9842: Compression Dictionary Transport, closes the key design gaps that made SDCH untenable. It enforces that an advertised dictionary is only usable on responses from the same origin, which prevents many of the conditions that made the side-channel attacks possible. Chrome 130+ and Edge 130+ have shipped support. Firefox is working to follow.
RFC 9842 also specifies how dictionaries interact with HTTP caching properly. The remaining complexity is real but tractable: an origin may have to generate dictionaries, serve them with the right headers, check every request for an Available-Dictionary match, delta-compress on the fly, and fall back gracefully when a client has no dictionary. Cache variants multiply, and dictionaries must stay fresh under normal HTTP caching rules.
This is exactly the kind of coordination problem that belongs at the edge.
How Cloudflare Is Shipping It
Cloudflare is rolling out shared dictionary support across three phases, starting with the plumbing.
Phase 1 is passthrough support, planned for open beta on April 30, 2026. Cloudflare forwards the headers and encodings that shared dictionaries require — Use-As-Dictionary, Available-Dictionary, and the dcb and dcz content encodings — without stripping, modifying, or recompressing them. Cache keys are extended to vary on Available-Dictionary and Accept-Encoding, so dictionary-compressed responses are cached correctly. This phase serves customers who already manage their own dictionaries at the origin.
Phase 2 moves the dictionary lifecycle off the origin entirely. Site owners tell Cloudflare which assets should be used as dictionaries via a rule, and Cloudflare manages the rest. Cloudflare injects the Use-As-Dictionary headers, stores the dictionary bytes, delta-compresses new versions against old ones, and serves the right variant to each client. The origin serves normal responses.
Phase 3 (not detailed in the announcement) will likely handle the long tail — dynamic content, custom dictionary policies, and the cross-origin scenarios that RFC 9842 deliberately leaves to future work.
What changes for developers is small in Phase 1 and large in Phase 2. In Phase 1, you need a Cloudflare zone with the feature enabled, an origin that serves dictionary-compressed responses with the correct headers, and visitors on Chrome 130+ or Edge 130+. In Phase 2, you ship a normal web app and let the CDN handle the compression. The dictionary complexity moves off your infrastructure and onto Cloudflare's.
What This Means Beyond Compression
Shared dictionaries are a wedge. Once a CDN owns the dictionary lifecycle, it owns the relationship between versions of the same asset — which means it can do things gzip never could. Cache invalidation by content delta instead of URL. Per-user dictionary pinning for personalized responses. Long-tail compression for dynamic HTML, which is currently unworkable on the open web but is being discussed in the developer community.
The deeper shift is more uncomfortable. The 18-year gap between SDCH and RFC 9842 was not about algorithms. It was about who owns the complexity. The web tried to push dictionary management to origins and failed. Cloudflare is betting that the edge is the only layer where the coordination can actually work.
If Phase 2 lands cleanly, every team shipping a high-deploy web app will quietly inherit a compression system that knows the diff between every version of every asset. The browser cache stops being a passive store and becomes an active participant in transport.
The open question is whether the rest of the stack catches up. Firefox needs to ship. Origins need to opt in. And somebody — Cloudflare, Vercel, Fastly, or the IETF — needs to define how shared dictionaries interact with edge functions, server components, and the new generation of agentic clients that treat HTML as data instead of pixels.
The web spent 18 years waiting for an answer to a question it stopped asking. Cloudflare is shipping the answer anyway.
