Compression Dictionary Transport: The Future of Web Performance

How It Works: Beyond Traditional Compression

Standard lossless compression (like Brotli) works by finding repeating strings inside a file. For example, in a JavaScript file containing the word "function" dozens of times, the compressor replaces most occurrences with a short reference to the first one.

Compression Dictionary Transport supercharges this by providing a pre-shared, external list of common strings—the dictionary. This dictionary can be:

• • A previous version of a file (e.g., app.v1.js used to compress app.v2.js)
  • A purpose-built dictionary file containing common templates, boilerplate, or frameworks used across a site

How CDT Works: The Mechanics

CDT operates through a handshake of HTTP headers, ensuring secure, efficient dictionary sharing. Here’s the flow:

1. 1. Dictionary Provisioning: Servers expose dictionaries via Link: </dictionary.dat>; rel="compression-dictionary" in HTML or HTTP responses, paired with Use-As-Dictionary: "/app/*.js"; id="lib-v1" to specify applicable URLs.
   2. Client Advertisement: On requests, clients send Available-Dictionary: "sha256-abc123..." (SHA-256 hash) and Accept-Encoding: gzip, br, dcb, dcz (dcb for Brotli, dcz for Zstandard).
   3. Server Compression: The server validates the hash, compresses using the dictionary, and responds with Content-Encoding: dcb. Include Vary: Available-Dictionary, Accept-Encoding for caching.
   4. Decompression: The client reconstructs the response using the cached dictionary.

Security is paramount: Dictionaries must be same-origin or CORS-compliant, with cache partitioning to prevent cross-site tracking.

Code Example: Compressing with Brotli Dictionary

#!/bin/bash
# Compress data.txt using dictionary.txt (Brotli level 5+)
brotli --quality=11 --large --dictionary=dictionary.txt data.txt -o data.txt.dcb

For Zstandard:

zstd --train=dictionary.txt --ultra data.txt -o data.txt.dcz

Real-World Examples

CDT shines in scenarios with repetitive or evolving content. Let’s dive into practical cases.

Static Resource Flows: Updating JavaScript Bundles

For static updates, use prior versions as dictionaries. Example from YouTube’s desktop player (Jan to Mar 2023):

Similarly, CNN’s React bundle (Mar 2022–2023) saw 63% savings: 344KB to 128KB.

Test your own: Use the Static Dictionary Tester with Wayback Machine snapshots.

Dynamic Resource Flows: Product Listings

For dynamic pages, build external dictionaries from sample content (e.g., product HTML). Exclude user-specific data to avoid privacy issues.

Tool: Dynamic Dictionary Generator—input URLs, target size, and it trains via Brotli’s dictionary_generator, testing cross-page compression.

Google Search Implementation

Google rolled out CDT for search results in spring 2025, using a Brotli dictionary from representative pages. Delivered via Link: </dict>; rel=compression-dictionary and Use-As-Dictionary: /search*.

• • Average Savings: 23% HTML reduction; up to 50% on compressed pages (107KB → 60KB).
  • Performance Impact: 1.7% LCP improvement; 9% on high-latency networks.
  • Daily Updates: Automated pipeline keeps dictionaries fresh.

Inspect in DevTools or chrome://net-internals/#sharedDictionary.

How to Implement Compression Dictionary Transport

To get started:

1. 1. Generate Dictionaries: For static resources, you can pre-compress files using command-line tools. You’ll need the dictionary file and the target file. Use Brotli’s dictionary_generator.cc for static/dynamic sets.
   2. Serve Dictionaries: The server must send the correct headers to advertise and use dictionaries. Add Use-As-Dictionary headers; compress them too!
   3. Key Restrictions & Best Practices:
      • Same-Origin Security: Dictionaries must be from the same origin as the resource using them, or follow CORS rules.
      • Cache Partitioning: Dictionaries are partitioned by origin like other caches.
      • Privacy Considerations: Browsers may restrict the feature when cookies are disabled to prevent fingerprinting.
      • Progressive Enhancement: Browsers that don’t support it will ignore the headers and request normally compressed (br/gzip) resources.
      • Dictionary Selection: For updates, using the immediate previous version as a dictionary yields the best results.
   4. Client-Side: Browsers (Chromium+) handle Available-Dictionary automatically.
   5. Server Config (Nginx Example):

location /app/ {
    brotli on;
    brotli_comp_level 5;
    # Custom logic for dcb if dictionary available
}

Browser support: Experimental in Chrome; check CanIUse. Always fallback to standard compression.

Benefits and Considerations

• • Speed Gains: Faster loads on mobile/high-latency; SEO boosts via Core Web Vitals.
  • Bandwidth Savings: Ideal for CDNs and global audiences.
  • Caveats: Same-origin only; validate hashes; monitor cache hits. Privacy: Avoid user data in dictionaries.

Is It Ready for Production?

As of late 2025, Compression Dictionary Transport is an experimental technology. It is supported in Chromium-based browsers (Chrome, Edge, Opera) from version 130 onwards. Check current browser compatibility before widespread implementation.

However, as a progressive enhancement, it’s safe to implement. Browsers that don’t support it will simply fall back to standard Brotli or gzip compression. The potential performance upside for supporting browsers is enormous, especially for:

• • Single Page Applications (SPAs) with frequent framework updates
  • Content-heavy sites with consistent templates (e.g., news, e-commerce, search results)
  • Software-as-a-Service (SaaS) platforms where users receive frequent UI updates