Shared Dictionary Compression

RFC 9842 lets browsers reuse a previous version of a file as a compression dictionary for the next version. When 95% of your JavaScript is unchanged between deploys, the transfer drops from tens of kilobytes to under a kilobyte.

1

First visit (dictionary registration)

Load app.v1. The response includes a Use-As-Dictionary header, telling the browser to store this file as a dictionary for future requests matching the same URL pattern.

2

Deploy ships (dictionary compression)

A new deploy changes 1.2% of the code. The browser sends Available-Dictionary, and gets back a Content-Encoding: dcz response — a tiny delta against the dictionary.

3

Another deploy

Yet another release with 1.5% code change. Same dictionary mechanism, same tiny transfer.

How does this work?
  1. Dictionary registration: When the browser fetches app.v1.js, the server responds with a Use-As-Dictionary header containing a URL match pattern (e.g. /assets/app.*.js). The browser caches this response as a compression dictionary.
  2. Dictionary use: On the next request matching the pattern (e.g. app.v2.js after a deploy), the browser sends an Available-Dictionary header with the SHA-256 hash of the stored dictionary, and adds dcz to Accept-Encoding.
  3. Delta compression: The server compresses the new response using the dictionary (the old version). Because 95%+ of the content is identical, the compressed delta is extremely small. The response comes back with Content-Encoding: dcz (Dictionary Compressed Zstandard).
How to verify in DevTools
  1. Open DevTools → Network tab
  2. Make sure "Disable cache" is OFF
  3. Click "Load v1" — look for Use-As-Dictionary in the response headers
  4. Click "Simulate deploy v2" — look for:
    • Available-Dictionary in the request headers
    • Content-Encoding: dcz in the response headers
    • A dramatically smaller "Size" in the Size column
  5. You can also check stored dictionaries at chrome://net-internals/#sharedDictionary
About the test bundles

Each bundle is ~144 KB of realistic JavaScript: a virtual DOM implementation, router, state management, charting library, form validation, i18n strings, CSS-in-JS runtime, markdown parser, HTTP client, date utilities, and geospatial functions.

Between versions, only 1–2% of the code changes: a few components get new features, a string table is updated, new routes are added. This mirrors real-world deploys where framework and library code stays the same.