Skip to content

PATTERN Cited by 1 source

Previous version as dictionary

Previous version as dictionary is the specific compression pattern in which the previously cached version of a resource — app.bundle.v1.js, say — becomes the dictionary used to compress the next version — app.bundle.v2.js. No separate dictionary file ships; the compression dictionary is the response the client has already cached.

The pattern is the core mechanic of shared-dictionary compression as standardised by RFC 9842 and deployed in Cloudflare Shared Dictionaries (open beta 2026-04-30).

The mechanic

  1. First fetch — server serves app.bundle.v1.js and attaches Use-As-Dictionary: match="/app.bundle.*.js", id="sha-256:abc...". Browser caches the response and records it as a dictionary usable for future URLs matching the match= pattern.
  2. Deploy happens — bundler emits app.bundle.v2.js (bundler chunk invalidation gives it a new filename).
  3. Next fetch — browser requests the new URL and sends Available-Dictionary: sha-256:abc... (the dictionary hash it has cached).
  4. Server compresses v2 against v1 using Zstandard / Brotli with v1 as dictionary; returns Content-Encoding: dcz (or dcb) with only the diff in the body.
  5. Browser decompresses the diff against its cached v1 → reconstructs full v2.

Persistent savings across release history

The dictionary lineage compounds:

v1 served raw             (dictionary seed)
v2 compressed against v1  (diff only)
v3 compressed against v2  (diff only)
…
v47 compressed against v46 (diff only)

Each successor re-uses the previous — "The savings don't reset, they persist across the entire release history."

Applicability

  • Versioned bundles with content-hashed URLs — the ideal case. Bundler re-chunks trigger filename changes; the previous-version-as-dictionary pattern absorbs the "new URL forces full re-download" failure mode.
  • Framework / library updates — most of a React / Vue / Svelte update is common plumbing; diffs compress well.
  • CSS framework updates — Tailwind, Bootstrap, etc. ship most of the same utility classes across versions.
  • Incremental JSON / HTML content — API responses or server-rendered HTML that changes incrementally across requests.

Non-applicability

  • Content that genuinely changes in full — dynamic personalised payloads, cryptographically signed responses where nonces rotate, per-request rendered content. Diff against previous version is large — the compression ratio degrades to ~plain-compression and the coordination overhead is net cost.
  • URLs that aren't versioned — if the same URL returns different content each request, the *"match=" pattern in Use-As-Dictionary doesn't discriminate well.
  • High-frequency / high-volume unique content — the dictionary-storage overhead at the edge is only amortised across many clients fetching the same resource.

Numbers from Cloudflare's 2026-04 lab + demo

  • Lab test: 272 KB bundle, v2 compressed against v1 → 2.6 KB DCZ (97 % reduction over gzip's 92.1 KB).
  • canicompress.com: 94 KB SPA bundle, new deploy every minute, only config block changes → ~159 bytes DCZ (99.5 % reduction over gzip).

Sibling patterns

  • Dictionary-against-representative-sample (traditional Zstandard dictionary use) — dictionary is a pre-computed sample of content, not a previous version. Orthogonal; complementary.
  • Content-addressed diff storage (Git, artifact stores) — objects stored as diffs against similar objects picked by heuristic (e.g. Git's path-trailing-16- chars pairing). Same idea at storage layer; different pairing policy.

Seen in

Last updated · 200 distilled / 1,178 read