Shared Dictionaries: Compression that keeps up with the agentic web

Cloudflare believes that as the web grows heavier, gets redeployed more often, and is repeatedly hit by more agentic crawlers, existing compression alone can't reduce redundant transfers. Even when the same application undergoes only small edits, bundle names change and invalidate the cache, so almost the entire file gets sent again on every deployment.

Shared Dictionaries work by using a previously cached version as a dictionary and sending only the diff for the new version. The browser remembers a resource it previously received, and on the next request it sends Available-Dictionary; the server then performs delta compression based on that version. As a result, even a large JS bundle's changes can be reduced to just a few KB.

This idea isn't new. In the past, SDCH was introduced in Chrome in 2008, but it was discontinued in 2017 due to side-channel risks like CRIME and BREACH, as well as structural issues such as conflicts with Same-Origin Policy, CORS, and the Cache API. The current standard, RFC 9842: Compression Dictionary Transport, refined the security design by only allowing dictionaries within the same origin, and Chrome and Edge already support it, with Firefox following suit.

Cloudflare is rolling this into its platform in three phases.

• Phase 1: A passthrough where the origin directly creates dictionary-compressed responses and Cloudflare passes through Use-As-Dictionary, Available-Dictionary, and dcb/dcz encoding as-is
• Phase 2: Customers just specify rules, and Cloudflare handles dictionary storage, delta compression, and fallback on their behalf
• Phase 3: The Cloudflare network automatically detects versioned resource patterns and generates and applies dictionaries

In initial experiments, a 272KB JS bundle was 92.1KB with gzip, but with DCZ using the previous version as a dictionary, it dropped to as low as 2.6KB. In the same test, on a cache miss, TTFB was about 20ms slower than gzip, but download completion was much faster at 31ms vs 166ms, and on a cache hit the gap widened further to 16ms vs 143ms.

Cloudflare plans to offer the Phase 1 open beta on April 30, 2026. It targets origins that serve dictionary-compressed responses with the correct headers, and visitors need a browser that supports dcb/dcz and Available-Dictionary, such as Chrome 130+ or Edge 130+. The core goal is to bring the complex dictionary lifecycle to the edge, so that large assets that change frequently can still retain caching benefits.