Seonglae ChoBy using data that the client and server already know as a “dictionary,” this approach can dramatically reduce payload size by sending references to that dictionary instead of retransmitting duplicated data.
In real-world tests, YouTube’s JavaScript download size dropped by up to 90% compared to prior optimizations, and Google Search result HTML shrank by roughly 50%. This is especially effective for JavaScript bundles or API responses where the source changes incrementally.
Technically, it follows the IETF standard “Compression Dictionary Transport” and uses the dcb (Dictionary-compressed Brotli) and dcz (Dictionary-compressed Zstandard) encodings. Both Zstandard and Brotli now support custom dictionaries, and this is already available in Chrome 130+. For YouTube’s performance data, see:
compression-dictionary-transport
WICG • Updated 2025 Dec 29 6:15
There are two main ways to build dictionaries: a “delta” approach that reuses previous responses, and an approach that uses a separately trained dictionary file. Major platforms such as Google, Pinterest, Notion, and Shopify have already deployed this in production and are seeing meaningful bandwidth savings.
That said, there are important adoption considerations: privacy protections enforced by the same-origin policy, more complex cache control (e.g., the Vary header), and additional server-side compute cost. Also note that this technique only reduces network transfer size—it does not reduce client-side JavaScript parsing and execution time.
- Chrome 130+
- CDN support required
Available-DictionaryContent-Encoding: dcb/dczheader
Shared Dictionary Compression
SDCH (2008, Google): SDCH (Shared Dictionary Compression for HTTP) was an earlier attempt at this idea (using a shared dictionary file plus HTTP headers), but it ultimately failed.
- Based on the VCDIFF delta algorithm (a file-delta algorithm, not a general-purpose compressor)
- Shipped in Chromium from the earliest versions, but other browsers never implemented it
- Privacy/security issues: the dictionary ID could be abused as a cross-site tracking vector
- In non-HTTPS environments, middleboxes could modify headers or recompress traffic, causing major problems
- Additional concerns about compression-based attacks such as CRIME
- Lost momentum after Brotli (RFC, 2016) and was fully removed in 2017
Today’s standard is Compression Dictionary Transport (IETF):
- Uses general-purpose compressors with custom dictionary support: Zstandard (standardized in 2018; supported from day one) and Brotli (custom dictionary support added in 2023)
- An opt-in negotiation: the client sends the dictionary’s SHA-256 hash in the
Available-Dictionaryheader, and if the server agrees it responds withContent-Encoding: dcbordcz
- Restricted to same-origin, addressing SDCH’s tracking issue (no more than first-party-cookie-level tracking capability)
- Both sides opt in, so it can be deployed now without worrying about compatibility
In short: the idea (compressing with a shared dictionary) is similar, but the algorithms, negotiation protocol, and security model were redesigned from scratch as a separate standard.
Dictionary Compression is finally here, and it's ridiculously good
Dictionary compression could completely change how applications send data over the web. It's recently gained broad support, and offers absurd real-world...
https://httptoolkit.com/blog/dictionary-compression-performance-zstd-brotli/
