Still Serving Gzip in 2024? Your Users Are Leaving Bandwidth on the Table

Let's be honest: most developers set up gzip compression once, confirm it's working with a Chrome DevTools network tab, and never think about it again. That's not laziness — it's just how infrastructure works. You configure the thing, it runs, you move on.

The problem is that "it works" and "it's optimal" are very different things. Gzip was standardized in 1992. The web it was designed for looked nothing like what you're shipping today. Meanwhile, two compression algorithms have emerged that routinely outperform gzip by significant margins — and most production servers are still ignoring them entirely.

Time to fix that.

What's Wrong With Gzip (Nothing, and Everything)

Gzip isn't broken. It's fast, universally supported, and still a massive improvement over uncompressed transfer. If you're running gzip right now, you're ahead of the teams shipping nothing.

But "ahead of nothing" isn't the goal. The goal is squeezing every unnecessary byte out of your transfers, and gzip's compression ratios — particularly at higher quality settings — trail behind what modern algorithms can do. More importantly, gzip's speed-to-ratio tradeoff has been superseded.

Here's where things get interesting.

Brotli: The Browser-Native Upgrade

Brotli was developed by Google and released in 2015. It's now supported by every major browser — Chrome, Firefox, Safari, Edge — and has been for years. When a browser that supports Brotli makes a request, it includes br in the Accept-Encoding header. If your server responds with Brotli-compressed content, the browser decompresses it natively. Zero client-side work required.

The compression numbers: At comparable CPU cost, Brotli typically achieves 15–25% better compression ratios than gzip on text-based assets — HTML, CSS, JavaScript, JSON. On some payloads, particularly JavaScript bundles, the gap is even wider. Google's own benchmarks showed Brotli compressing JavaScript files roughly 17% smaller than gzip at equivalent speeds.

The catch: Brotli is slower to compress than gzip at maximum quality settings. At quality level 11 (maximum), it can be 10-100x slower than gzip. This makes real-time Brotli compression impractical for dynamic content on high-traffic servers.

The solution: Pre-compress your static assets. Your build pipeline should generate .br files alongside your regular assets. Serve them statically. You pay the compression cost once at build time, and every subsequent request gets fast decompression with no CPU overhead at serve time. Nginx, Caddy, and most modern CDNs support this out of the box.

For dynamic content, Brotli at quality level 4–6 is fast enough for real-time compression and still beats gzip on ratio. Worth benchmarking for your specific workload.

Zstandard: The Server-Side Powerhouse

Zstandard (Zstd) is Facebook's compression algorithm, open-sourced in 2016 and now part of the Linux kernel. It's a different beast from Brotli — less focused on browser delivery and more oriented toward server-to-server communication, database storage, log compression, and internal API traffic.

Why it matters: Zstd's headline feature is its adjustable speed-ratio dial. At level 1, it's faster than gzip while matching or beating its compression ratio. At level 3 (the default), it's roughly comparable in speed to gzip but compresses 15–20% better. At higher levels, it can match Brotli's ratios while remaining faster.

More practically: Zstd supports dictionary compression, which is a game-changer for API responses. If your API returns similar JSON structures repeatedly — which every API does — you can train a Zstd dictionary on a sample of your responses and achieve dramatically better compression ratios on small payloads. JSON responses that are too small for gzip to compress meaningfully (under ~1KB) can see real gains with a trained Zstd dictionary.

Browser support for Zstd in HTTP transfer encoding is arriving — Chrome added support in 2023 — but it's not yet universal enough to rely on for public-facing web delivery. For internal services, microservice communication, and anything where you control both ends of the connection, Zstd should be your default in 2024.

Compression Algorithm Cheat Sheet

Rolling Out Modern Compression Without Breaking Anything

Here's the good news: you don't have to choose. Modern servers can serve multiple encoding formats and let clients negotiate what they support.

Step 1: Enable Brotli on your static asset pipeline. Add Brotli pre-compression to your build process. In webpack, compression-webpack-plugin supports Brotli. In Vite, the vite-plugin-compression handles it. Generate both .gz and .br versions of every static asset.

Step 2: Configure your server to serve the right encoding. Nginx with the ngx_brotli module will serve .br files to Brotli-capable clients and fall back to .gz for everyone else. Caddy has native Brotli support. AWS CloudFront supports Brotli and handles content negotiation automatically.

Step 3: Audit your dynamic content. For server-rendered responses and API payloads, benchmark Brotli at quality 4–6 against your current gzip setup. Use wrk or k6 to measure actual throughput impact under load. If your response times stay within acceptable bounds, ship it.

Step 4: Migrate internal services to Zstd. For microservice communication, background job payloads, and anything not going through a browser, evaluate Zstd. The migration is typically a library swap — most languages have mature Zstd bindings.

Step 5: Verify with real tooling. Use curl -H 'Accept-Encoding: br' -I https://yourdomain.com to confirm Brotli is being served. Check the Content-Encoding: br response header. Trust but verify.

The Numbers That Should Motivate You

A typical React application's JavaScript bundle, compressed with gzip at level 6: roughly 45KB. The same bundle with Brotli at quality 6: roughly 38KB. That's 15% smaller on every page load for every user. Multiply that by your monthly traffic volume and translate it to CDN egress costs. The math gets interesting fast.

Gzip did its job. It served the web well for three decades. But the tools have moved on, and there's no good reason your infrastructure shouldn't move with them.