📅 Published 4 April 2026

HTTP compression is one of those optimisations where the effort-to-benefit ratio is absurdly favorable — configure it once and every text-based response gets 60–90% smaller with no application code changes. But the choice of algorithm matters more than most server operators realise, and the landscape has shifted. Gzip has been the default for two decades. Brotli has been the upgrade path since 2016. And now Zstandard is entering the HTTP compression conversation with browser support landing in 2024–2025. Each algorithm makes different trade-offs between compression ratio, CPU cost, and decompression speed.

This comparison is based on production measurements, not synthetic benchmarks. The Apache mod_brotli configuration guide on this site covers Brotli server setup in detail — this page focuses on the algorithm comparison to help you choose the right tool. This page is part of the web development section and connects to the web performance topic hub.

The algorithms at a glance​

Gzip (deflate) is the baseline. Every browser supports it. Every server supports it. Compression ratios are decent, CPU cost is low, and decompression is fast. There is nothing wrong with gzip — it is simply outperformed by newer alternatives on every dimension except ubiquity and simplicity.

Brotli was designed by Google specifically for HTTP content. It achieves 15–25% better compression ratios than gzip on typical web content (HTML, CSS, JavaScript, JSON) at comparable CPU cost. At its highest compression levels (10–11), Brotli produces significantly smaller output than gzip but at dramatically higher CPU cost — making those levels suitable only for pre-compressed static assets, not on-the-fly dynamic compression.

Zstandard (zstd) was designed by Meta (Yann Collet, who also created LZ4) as a general-purpose algorithm with an exceptionally wide speed/ratio range. At its lower compression levels, zstd matches gzip ratios at 3–5x the speed. At its higher levels, it approaches Brotli ratios with lower CPU cost. Its real-time compression performance is exceptional.

Compression ratio comparison​

Measured on a representative set of web assets (minified HTML, CSS, JavaScript, JSON API responses):

These numbers vary by content type. Brotli's advantage is largest on HTML and JavaScript because its dictionary includes common web content patterns. Zstd performs relatively better on JSON and structured data.

CPU cost comparison​

For dynamic compression (compressing each response on the fly), CPU cost determines how many concurrent requests your server can compress without adding latency.

Brotli at quality 4–5 uses roughly similar CPU to gzip at quality 6, while achieving better ratios. Brotli at quality 11 uses 10–50x more CPU than gzip — completely impractical for dynamic responses but excellent for pre-compressing static files during build.

Zstd at quality 3 uses approximately half the CPU of gzip at quality 6, while achieving comparable or better ratios. This is zstd's standout advantage for dynamic compression — it gives you Brotli-class ratios at less-than-gzip CPU cost.

Browser support in 2026​

Gzip: Universal. Every browser, every HTTP client.

Brotli: Universal in browsers (Chrome, Firefox, Safari, Edge all support br content encoding). Some older HTTP clients and bots may not advertise Brotli support.

Zstd: Chrome 123+ and Firefox 126+ support zstd content encoding. Safari support landed in late 2025. Coverage is approaching practical universality for browser traffic but is not yet at Brotli's level for the long tail of HTTP clients.

Server configuration strategy​

The practical recommendation in 2026:

1. Serve Brotli as the primary algorithm for all browsers that support it. Use quality 4–5 for dynamic content, quality 11 for pre-compressed static assets.

2. Use gzip as the fallback for clients that do not advertise Brotli support. Quality 6 is the sweet spot.

3. Consider zstd for API endpoints where you control both the server and the client, or for sites with heavy dynamic content where CPU cost matters. The CPU savings over Brotli at comparable quality are meaningful at scale.

4. Pre-compress static assets at build time in all three formats. Serve the best format each client supports via content negotiation.

The server negotiates automatically based on the client's Accept-Encoding header. A request with Accept-Encoding: br, gzip, zstd will receive the server's preferred algorithm. Configure preference order as br > zstd > gzip for the best balance of ratio and compatibility.

Pre-compression at build time​

For static sites, pre-compressing assets during the build process eliminates runtime CPU cost entirely. Generate .br, .gz, and optionally .zst versions of every static file:

# Brotli (quality 11, slow but maximum compression)
brotli -q 11 -o style.css.br style.css

# Gzip (quality 9, maximum for gzip)
gzip -9 -k style.css

# Zstandard (quality 19, high compression)
zstd -19 -o style.css.zst style.css

Configure your server or CDN to serve the pre-compressed version matching the client's accepted encoding. Nginx, Caddy, and Cloudflare all support this pattern.

The bottom line​

If you are starting from gzip only, add Brotli first — the ratio improvement is meaningful and the configuration is straightforward. If you are already serving Brotli and want to optimise CPU cost for high-traffic dynamic endpoints, explore zstd. If you are pre-compressing static assets, generate all three formats and let content negotiation do the work.

Compression is cumulative with other performance optimisations. A response compressed with Brotli and delivered over HTTP/3 on a CDN edge node represents the current best-case scenario for transfer efficiency. Each layer compounds — and unlike many performance optimisations, compression improvements apply to every single response without application changes.