Brotli compression
A general-purpose lossless compression algorithm — created by Google, standardized as RFC 7932 — that combines a modern LZ77 variant, Huffman coding, and second-order context modeling, plus a built-in dictionary of common web strings. It’s the delivery-side lever the wiki kept implying but never had a page for: shrinking the transferred bytes of text assets (HTML/CSS/JS) without changing the assets themselves.
Vs gzip
- Better compression ratio than gzip on text — especially HTML/CSS/JS, helped by its web-tuned built-in dictionary.
- Decompression speed comparable to deflate, but compression is slower than gzip — so the practical guidance is Brotli for cacheable static assets (compress once, serve many times, often at max level) and gzip for non-cacheable dynamic content.
- Broad modern-browser support (sent via
Accept-Encoding: br), with gzip as the universal fallback.
Why it matters here
This page closes a specific gap flagged in synthesis and web-almanac-page-weight-2024: HTTP Archive finds only ~70% of pages use text compression and that adoption has been roughly flat/declining — i.e. a large, free byte saving is being left on the table. Brotli is the concrete mechanism. It also sits on the delivery side of the wiki’s standing page-weight-vs-architecture tension (see synthesis contradictions): the same source bytes can transfer at very different sizes depending on the codec, so how bytes are compressed is part of real-user performance, not just how many you author. Complements the author-side levers (landing-page-14kb, bundle-size, squint) — they reduce the bytes you write; Brotli reduces the bytes you ship them as. (For images, the analogous “ship it smaller” lever is avif, not Brotli — already-compressed media gains little from a text codec.)
Related
page-weight · web-almanac-page-weight-2024 · bundle-size · performance-budget · avif · synthesis