Brotli vs Gzip: Faster Asset Transfer Speeds

Brotli compression improves web asset transfer speeds by reducing file sizes significantly more than Gzip, leading to lower bandwidth consumption and faster page render times. Developed by Google, Brotli optimizes text-based web assets like HTML, CSS, and JavaScript through modern compression algorithms, larger sliding windows, and a predefined static dictionary. This direct comparison explains how Brotli outperforms Gzip, why it accelerates data delivery, and how to effectively leverage it in modern web development.

Larger Sliding Window

Gzip relies on the Deflate algorithm, which restricts its sliding window to 32 KB. This means Gzip can only look backward 32 KB within a file to find repeated patterns and duplicate strings.

In contrast, Brotli allows sliding window sizes of up to 16 MB. This massive increase enables the algorithm to identify recurring code patterns and strings across much larger distances within bundled JavaScript or monolithic CSS stylesheets. As a result, Brotli captures redundancies that Gzip simply misses, generating noticeably smaller compressed files.

Predefined Static Dictionary

A primary advantage of Brotli over Gzip is its inclusion of a built-in static dictionary containing over 120 KB of frequently used web terms, common phrases, and HTML/CSS snippets in multiple languages.

When Brotli encounters standard web syntax—such as <html>, <!DOCTYPE html>, <div>, margin: 0 auto;, or common JavaScript keywords—it references them using short index pointers rather than encoding the strings from scratch. Gzip lacks a built-in static dictionary and must build its dictionary dynamically for each asset, which leads to larger payloads on initial occurrences of common web patterns.

Better Compression Ratios

Due to its enhanced LZ77 variant, context modeling, and 2nd-order entropy coding, Brotli consistently achieves better compression ratios than Gzip across standard web formats:

  • JavaScript: Typically 14% to 20% smaller than Gzip.
  • CSS: Often 17% to 25% smaller than Gzip.
  • HTML: Can be up to 21% to 25% smaller than Gzip.

Because compressed payloads are roughly 15% to 25% smaller overall, network transmission requires fewer round-trip times (RTT) across the TCP connection. This reduction directly accelerates the Time to First Byte (TTFB) and First Contentful Paint (FCP), especially over slow or high-latency mobile networks.

Decompression and CPU Efficiency

While higher compression algorithms sometimes trade smaller file sizes for intensive CPU overhead during decompression, Brotli maintains decompression speeds roughly equivalent to Gzip. Browsers can parse and decompress Brotli-encoded streams in near real-time without causing client-side CPU bottlenecks.

For the server side, Brotli offers 11 compression quality levels:

  • Static Assets (Pre-compressed): Build tools (e.g., Webpack, Vite) can pre-compress assets at level 11 during the build phase. This maximizes compression without incurring any runtime CPU load on the production server.
  • Dynamic Content (On-the-Fly): For dynamic responses generated at runtime, levels 4 to 6 offer a balanced compromise, yielding smaller files than Gzip level 6 while using comparable server CPU resources.

Browser Support and Fallback Strategy

Modern web browsers negotiate compression using the Accept-Encoding header. Current versions of Chrome, Firefox, Safari, and Edge send Accept-Encoding: gzip, deflate, br. When a browser advertises support for br, the web server serves the Brotli-compressed file alongside the Content-Encoding: br header over HTTPS. If an older client does not indicate Brotli support, servers fall back automatically to standard Gzip compression.