Skip to content

SYSTEM Cited by 1 source

Cloudflare Shared Dictionaries

Cloudflare Shared Dictionaries is Cloudflare's edge implementation of RFC 9842: Compression Dictionary Transport, announced with an open beta opening 2026-04-30. The feature turns the previously cached version of a resource into the compression dictionary for the next version, so when a team ships a one-line fix to a 272 KB JS bundle, only the few-KB diff travels on the wire instead of the full re-gzipped bundle.

Launch framed as the compression response to 2026's colliding trends: pages growing 6-9 % heavier per year, ~10 % of Cloudflare requests in March 2026 from agentic actors (+60 % YoY), and AI-assisted development compressing the deploy interval so bundler re-chunking invalidates filenames on every push. See sources/2026-04-17-cloudflare-shared-dictionaries-compression-that-keeps-up-with-the-agent.

Three-phase rollout

Canonical instance of passthrough → managed → auto — each phase moves more of the protocol's coordination cost onto the CDN.

Phase 1 — Passthrough (open beta 2026-04-30)

  • Active development at post publication; open beta 2026-04-30.
  • Cloudflare forwards the RFC 9842 headers (Use-As-Dictionary, Available-Dictionary) and encodings (dcb delta-Brotli, dcz delta-Zstandard) without stripping, modifying, or recompressing.
  • Cache keys extended to vary on Available-Dictionary + Accept-Encoding so dictionary-compressed responses are cached correctly.
  • Customer origin owns the full dictionary lifecycle: generation, storage, header emission, on-the-fly delta compression, fallback when client doesn't have the dictionary.
  • Target customer: advanced teams with their own origin implementation, e.g. using Patrick Meenan's dictionary-worker (WASM-Zstandard in a Worker) as a reference.

Phase 2 — Managed Dictionaries (unscheduled)

  • Customer configures a rule naming which assets serve as dictionaries.
  • Cloudflare injects Use-As-Dictionary, stores dictionary bytes, delta-compresses new versions against cached old ones, serves the right variant per client.
  • Origin serves normal (uncompressed / gzip / br / zstd) responses — all dictionary complexity moves off customer infrastructure onto Cloudflare's.
  • Target customer: teams that know which assets are versioned but don't want to build lifecycle infrastructure.

Phase 3 — Automatic Dictionaries (unscheduled)

  • No customer configuration.
  • Cloudflare observes URL patterns across "millions of sites… billions of requests… every new deploy"; when "successive responses share most of their content but differ by hash" → infers the resource is versioned → auto-stores previous version as dictionary → auto-delta-compresses successors.
  • Safety is the hard problem: "Safely generating dictionaries that avoid revealing private data and identifying traffic for which dictionaries will offer the most benefit are real engineering problems."
  • Validation loop: the RUM beacon confirms a generated dictionary actually improves compression before Cloudflare commits to serving it (RUM-validated dictionary selection).
  • Target: long tail of zones that would never ship a custom implementation — "millions of zones that would never have had the engineering time to implement custom dictionaries manually."

Lab-test numbers

  • Two near-identical JS bundles simulating successive deploys.
  • Uncompressed 272 KB → gzip 92.1 KB (66 %) → DCZ with v1 as dictionary 2.6 KB (97 % reduction over gzip).
  • TTFB on cache miss: ~20 ms slower than gzip (origin has to compress against dictionary).
  • Download completion: cache miss 31 ms DCZ vs 166 ms gzip (81 %); cache hit 16 ms vs 143 ms (89 %).

canicompress.com — live demo

  • https://canicompress.com/ — Phase-2-shaped demo with a new ~94 KB SPA bundle deployed every minute.
  • First load: edge stores v1 as dictionary.
  • Subsequent loads after each one-minute re-deploy: browser sends v(n-1) hash, edge delta-compresses v(n).
  • Wire size ≈ 159 bytes — 99.5 % reduction over gzip.
  • Includes curl / DevTools walkthroughs for independent verification.

Browser support

  • Chrome 130+, Edge 130+ advertise dcb/dcz in Accept-Encoding and send Available-Dictionary.
  • Firefox tracking, not yet shipped.
  • Safari not mentioned.
  • Clients without support silently fall back to gzip / Brotli / Zstd — no benefit, no breakage.

Why "this belongs at the edge"

Origin-side complexity enumerated in the post: generate dictionaries, serve them with correct headers, check every request's Available-Dictionary on the hot path, delta-compress on the fly, fall back gracefully, manage cache variants (every dictionary version creates a new variant — cache-variant explosion), handle mid-deploy client-population splits. "A CDN already sits in front of every request, already manages compression, and already handles cache variants." Canonical edge-managed protocol complexity instance.

See also

Seen in

Last updated · 200 distilled / 1,178 read