Brotli (RFC 7932) vs Gzip (RFC 1952): Compression Algorithms, Dictionaries, and Web Performance

1. The Classical Foundation: Gzip, DEFLATE, and RFC 1952

Gzip wraps the underlying DEFLATE compression algorithm (RFC 1951) with a 10-byte header, an optional filename field, and an 8-byte trailer containing a CRC-32 checksum and the uncompressed payload size modulo $2^{32}$.

DEFLATE operates via a two-stage pipeline combining LZ77 sliding-window dictionary substitution with canonical Huffman prefix coding. During LZ77 processing, the compressor scans the input byte stream through a 32 KB sliding window. When it identifies recurring sequences, it replaces the duplicate string with a `(distance, length)` back-reference pointer.

The resulting stream of literal bytes and back-reference tuples is then compressed using Huffman coding, which assigns shorter bit sequences to frequently occurring symbols and longer bit sequences to rare symbols. Because the sliding window is capped at 32 KB, DEFLATE cannot recognize repeated strings separated by more than 32,768 bytes—a severe limitation for multi-megabyte modern JavaScript bundles.

// RFC 1952 Gzip File Structure:
// [ ID1: 0x1F ] [ ID2: 0x8B ] [ Compression Method: 0x08 (Deflate) ]
// [ Flags: 1 byte ] [ MTIME: 4 bytes ] [ XFL: 1 byte ] [ OS: 1 byte ]
// [ Compressed DEFLATE Blocks ... ]
// [ CRC-32: 4 bytes ] [ ISIZE: 4 bytes (Uncompressed Size mod 2^32) ]

2. The Brotli Revolution: RFC 7932 and the Built-In Static Dictionary

Brotli advances compression science through three fundamental architectural breakthroughs: an expanded sliding window, 2nd-order context modeling, and a massive pre-built static dictionary.

First, Brotli expands the LZ77 sliding window from Gzip's rigid 32 KB up to 16 MB (or up to 1 GB in extended client implementations). This enables the compressor to reference recurring code patterns, function declarations, and boilerplate chunks across the entire span of large bundles.

Second, Brotli incorporates an immutable 122 KB static dictionary embedded directly into client decoders (every modern web browser). This dictionary contains over 13,000 words, HTML tags (`<script>`, `<div>`, `class=`), CSS properties (`margin`, `display: none`), common JavaScript identifiers, and pervasive web phrases in multiple languages. If an HTML or JS file contains standard web keywords, Brotli does not need to learn the pattern from the input stream; it simply issues a tiny reference pointer into the static browser dictionary.

Third, Brotli replaces classical Huffman coding with Asymmetric Numeral Systems (ANS) and Huffman tables adapted dynamically across contextual nibbles, achieving entropy encoding within fractions of a percent of theoretical Shannon limits.

// HTTP Content-Encoding Negotiation Flow:
// Client Request:
GET /assets/bundle.js HTTP/2
Accept-Encoding: gzip, deflate, br, zstd

// Server Response (Brotli prioritized):
HTTP/2 200 OK
Content-Encoding: br
Vary: Accept-Encoding
Content-Type: application/javascript; charset=UTF-8

3. Dynamic Compression vs Static Pre-compression: The Level Paradox

Brotli offers compression levels ranging from 1 to 11 (compared to Gzip's 1 to 9). However, the CPU complexity of Brotli is highly non-linear across these levels.

Levels 1 through 4 provide ultra-fast dynamic compression comparable to or faster than `gzip -6`, making them ideal for dynamic JSON APIs, server-rendered HTML, and streaming responses where compression must occur in real time without increasing TTFB.

Levels 9 through 11 deploy intensive tree search heuristics. While `brotli -11` achieves astonishing file size reductions (often shrinking JavaScript bundles 25% smaller than `gzip -9`), the compression process is roughly 100 times slower in CPU time. Running `brotli -11` on-the-fly during a dynamic HTTP request will spike server CPU to 100% and add hundreds of milliseconds of latency, totally negating bandwidth savings.

The gold-standard architectural pattern is: Pre-compress static assets (JS, CSS, SVG, WASM) during build pipelines (e.g., in Webpack, Vite, or Next.js) using `brotli -11` and `gzip -9` ahead-of-time (`.br` and `.gz` static files). Configure edge web servers (Nginx, Caddy, Cloudflare) to serve pre-compressed `.br` files directly without runtime CPU overhead.

4. WOFF2 and Image Media: Why Re-compressing Fails

Web performance engineers must also understand where HTTP compression must NOT be applied. Modern font formats like WOFF2 (Web Open Font Format 2.0) are already compressed using Brotli at the binary font-table level.

Similarly, images (JPEG, PNG, WebP, AVIF), videos (MP4, WebM), and ZIP archives already contain high-entropy compressed data. Applying Gzip or Brotli to already compressed binary assets not only wastes server and client CPU cycles, but frequently results in an expanded payload size due to framing header overhead.

Web servers should restrict `Content-Encoding: br` to text-based MIME types: `text/*`, `application/javascript`, `application/json`, `application/xml`, `image/svg+xml`, and `application/wasm`.

5. Safe Client-Side Inspection and Decompression Sandboxing

When analyzing HTTP network archives (HAR files), debugging API responses, or inspecting encoded telemetry payloads, developers require instant local decompression tools.

Browser-native Web Streams API (`DecompressionStream('deflate')` and `DecompressionStream('gzip')`) paired with WebAssembly-compiled Brotli engines allow users to drag-and-drop compressed `.br` and `.gz` binaries for immediate in-memory inspection. Processing decompression locally inside the browser guarantees that proprietary binaries and confidential HTTP transaction dumps remain completely private and isolated.

Summary & Best Practices

Brotli (RFC 7932) outperforms Gzip (RFC 1952) by 15–25% via larger sliding windows, static web dictionaries, and advanced context modeling. For dynamic responses, maintain Brotli levels 1–4 to preserve low TTFB; for static assets, pre-compress at Brotli level 11 during build steps to minimize transfer payloads across global CDNs.