Re-shipping the whole web, every deploy
Web pages have been getting heavier by 6-9% every year for the past decade, and nothing suggests that trajectory will flatten. What is changing is how often those pages are rebuilt and how often clients request them—both are climbing sharply due to agents. Agentic crawlers, browsers, and other tools now account for just under 10% of all requests across Cloudflare’s network as of March 2026, up roughly 60% year-over-year. These clients hit endpoints repeatedly, fetching full pages to extract a fragment of information.
Agents aren't only consuming the web; they're helping build it. AI-assisted development means teams ship faster, which means more deploys, more bundle re-chunks, and new filenames. When a one-line fix lands, every user on earth can be forced to re-download the entire application—not because the code is meaningfully different, but because the browser has no way to know what changed. Traditional compression reduces the size of each download, but it can't address the redundancy. The server doesn't know the client already has 95% of the file cached, so every deploy sends those bytes again. Ship ten small changes a day and caching effectively becomes opt-out. That wastes bandwidth and CPU in an environment where hardware is becoming the bottleneck.
Shared dictionaries as a cheat sheet
A shared compression dictionary is a reference held by both server and client. Instead of compressing a response from scratch, the server indicates what the client already knows from prior caching and sends only what's new. The client reconstructs the full response during decompression using its stored copy.
Compressing against known content is how modern compression algorithms outperform their predecessors. Brotli ships with a built-in dictionary of common web patterns; Zstandard is designed for custom dictionaries, generating an optimized one from representative content samples. Gzip has neither, relying on real-time pattern discovery. These traditional algorithms are already available on Cloudflare.
Shared dictionaries push the concept further: the previously cached version of a resource becomes the dictionary itself. With delta compression, when a server first serves a resource it attaches a Use-As-Dictionary response header, instructing the browser to retain the file for future use. On the next request, the browser sends an Available-Dictionary header identifying what it holds. The server compresses the new version against the old one and transmits only the diff—no separate dictionary file needed.
This is where the payoff materializes for real applications. Consider versioned JS bundles or CSS files that change incrementally. A user caches app.bundle.v1.js; a developer deploys app.bundle.v2.js. Delta compression sends only the difference between them. The savings persist across the release history—version three compresses against version two, version 47 against version 46. A 500 KB bundle with a one-line change becomes a few kilobytes on the wire. At 100K daily users and ten deploys per day, that's the difference between 500 GB of transfer and a few hundred megabytes.
Community discussion continues around custom and dynamic dictionaries for non-static content. That remains future work, but the implications are substantial.
Why shared dictionaries aren't universal yet
The previous attempt failed. Google shipped Shared Dictionary Compression for HTTP (SDCH) in Chrome in 2008, with early adopters reporting double-digit page-load improvements. But it accumulated problems faster than they could be fixed.
Most memorable was a class of compression side-channel attacks—CRIME and BREACH. Researchers demonstrated that if an attacker could inject content next to something sensitive being compressed, the size of the compressed output could leak information about secret data like session cookies or tokens. An attacker could guess a byte at a time, observe whether the asset size shrank, and repeat until extracting the full secret.
Security wasn't the only obstacle. SDCH also surfaced architectural issues, including violations of the Same-Origin Policy and an inability to reconcile its cross-origin dictionary model with CORS. It lacked specification around interactions with the Cache API. By 2017, Chrome—the only browser supporting it—removed it.
It took a decade for the web community to pick up the baton. The modern standard, RFC 9842: Compression Dictionary Transport, closes key design gaps. It enforces that an advertised dictionary is only usable on responses from the same origin, mitigating many conditions that enabled side-channel compression attacks. Chrome and Edge have shipped support, with Firefox working toward implementation. Broader adoption is underway, though complete cross-browser support is still catching up.
The RFC addresses security, but dictionary transport remains complex to implement. An origin may need to generate dictionaries, serve them with correct headers, check every request for an Available-Dictionary match, delta-compress responses on the fly, and fall back gracefully when clients lack a dictionary. Caching adds another layer: responses vary on both encoding and dictionary hash, so each dictionary version creates a separate cache variant. Mid-deploy, clients may hold the old dictionary, the new one, or none—meaning the cache stores separate copies for each. Hit rates drop, storage climbs, and dictionaries must stay fresh under standard HTTP caching rules.
This complexity is fundamentally a coordination problem—exactly what belongs at the edge. A CDN already sits in front of every request, manages compression, and handles cache variants. Cloudflare is currently preparing support for shared compression dictionaries, with early testing underway and a beta planned for April 30, 2026.
Putting dictionary compression on the Cloudflare edge
Shared dictionary compression interacts with every layer of the stack between browser and origin. Some customers have already rolled their own implementations — for example, RFC author Patrick Meenan's dictionary-worker runs the full lifecycle inside a Cloudflare Worker with WASM-compiled Zstandard. Cloudflare's goal is to make the capability broadly available, and the rollout happens in three phases, starting with the foundational plumbing.
Phase 1 is passthrough support, currently in active development. Cloudflare will forward the headers and encodings shared dictionaries depend on — 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 cache correctly. This phase targets customers who manage their own dictionaries at the origin.
An open beta for Phase 1 is planned by April 30, 2026. To use it, you need a Cloudflare zone with the feature enabled, an origin serving dictionary-compressed responses with the correct headers (Use-As-Dictionary, Content-Encoding: dcb or dcz, Vary on Accept-Encoding and Available-Dictionary), and visitors on a browser supporting dictionary transport — today that means Chrome 130+ and Edge 130+, with Firefox support in progress. Watch the Cloudflare changelog for availability and documentation.
Internal passthrough testing has already begun. In a controlled test, two nearly identical JS bundles were deployed in sequence, with only localized changes between versions to simulate successive deploys of the same web app. 200 tests ran against the San Jose, California PoP, with the origin in Council Bluffs, Iowa serving the dictionary, JS bundle, and a precomputed dictionary-compressed bundle. TTFB and total download time were captured via curl.
The uncompressed asset is 272KB. Gzip reduces it to 92.2KB, a 66% reduction. With shared dictionary compression over DCZ, using the previous version as the dictionary, the same asset drops to 2.6KB — a 99% reduction from the uncompressed asset and still 97% smaller than gzip.
The same lab test measured two timing milestones from the client: time to first byte (TTFB) and full download completion. At P99 on a cache miss, DCZ TTFB is roughly 60ms faster than gzip. On a cache hit, the TTFB gap narrows to a negligible 10ms.
Download completion shows the sharper difference. Transfer time — total curl receiving time minus TTFB — for the DCZ response on a cache miss is 1ms versus 161ms for gzip (99.4% faster; the body essentially arrives alongside the headers). On a cache hit, it's 1ms versus 54ms (98% faster). The localized changes between versions were already captured by the dictionary, which is the point: for successive deploys of roughly the same application, shared dictionaries eliminate nearly all redundant transfer.
Initial lab results from simulating minimal JS bundle diffs; results will vary based on the actual delta between the dictionary and the asset.
Phase 2 moves the work onto Cloudflare. Instead of managing dictionary headers, compression, and fallback logic on the origin, you declare which assets should serve as dictionaries via a rule, and Cloudflare handles the rest. Cloudflare injects the Use-As-Dictionary headers, stores dictionary bytes, delta-compresses new versions against old ones, and serves the right variant to each client. The origin continues to serve normal responses; dictionary complexity shifts off your infrastructure.
To demonstrate Phase 2, Cloudflare built a live demo: Can I Compress (with Dictionaries)? at canicompress.com. The demo deploys a new ~94KB JavaScript bundle every minute, mimicking a typical production single-page application bundle where most code is static between deploys and only a small configuration block changes each time. When the first version loads, Cloudflare's edge stores it as a dictionary. On the next deploy, the browser sends the hash of the version it already has, and the edge delta-compresses the new bundle against it. The result: 94KB compresses to roughly 450 bytes — a 99.5% reduction over gzip, since only the actual diff goes on the wire. The demo site includes walkthroughs for verifying compression ratios via curl, browser, or agent.
Phase 3 removes configuration entirely. The dictionary is automatically generated on behalf of the website. Cloudflare's network already sees every version of every resource flowing through it — millions of sites, billions of requests, and every new deployment. When the network observes a URL pattern where successive responses share most of their content, that's a strong signal the resource is a good candidate for delta compression. If safe, Cloudflare stores the previous version as a dictionary and compresses subsequent versions against it. No customer configuration, no maintenance.
This phase is simple in concept but genuinely difficult in execution. Safely generating dictionaries that don't reveal private data, and identifying traffic where dictionaries will provide the most benefit, are real engineering problems. Cloudflare has the necessary pieces: traffic visibility across the entire network, an existing cache layer where dictionaries live, and a RUM beacon to clients that provides a validation loop to confirm a dictionary actually improves compression before committing to serve it. The combination of traffic visibility, edge storage, and synthetic testing makes automatic generation feasible, though many pieces remain to figure out.
Phase 3's performance and bandwidth benefits are the core motivation. This is what makes shared dictionaries accessible to everyone on Cloudflare, including the millions of zones that would never have had the engineering time to implement custom dictionaries manually.
Compression with a memory
For most of the web's history, compression has been stateless — every response compressed as if the client had never seen anything before. Shared dictionaries change that by giving compression a memory.
This matters more now than it would have five years ago. Agentic coding tools are compressing the interval between deploys while also driving a growing share of the traffic that consumes them. While AI tools today can produce massive diffs, agents are gaining context and becoming more surgical in their code changes. That, combined with more frequent releases and more automated clients, means more redundant bytes on every request. Delta compression helps both sides of that equation by reducing both bytes per transfer and the number of transfers needed at all.
Shared Dictionaries took decades to standardize. Cloudflare is building the infrastructure to make it work for every client that touches your site, human or not. Phase 1 beta opens April 30.
