Stop Using gzip: We Ran 108 Benchmark Passes Across gzip, Zstd, and Brotli

If you inspect the HTTP response headers of 90% of web servers and REST APIs deployed right now, you will almost certainly find this:

content-encoding: gzip

gzip (RFC 1952) was standardized in May 1996. It relies on the DEFLATE algorithm, written when a Pentium Pro with 64MB of RAM was considered an industrial-grade compute node.

Over the past decade, two modern algorithms have emerged to challenge it:

1. Brotli (RFC 7932) — Developed by Google, featuring a hardcoded 122KB static dictionary optimized for web payload syntax (HTML/CSS/JS).
2. Zstandard (RFC 8878) — Developed by Yann Collet at Meta, engineered for extreme asymmetric decompression throughput and parallel hardware execution.

Yet most production fleets still default to gzip. Why? Because most teams assume:

“Compression is just compression. A higher level saves more bytes, and decompression is free.”

To test whether this assumption holds up in real-world systems, we constructed an automated, reproducible benchmark lab. We ran 108 verified individual passes across 50MB identical datasets, measuring wall-clock latency, kernel CPU time, throughput in MB/s, memory RSS, and cryptographic SHA-256 integrity.

The empirical data revealed three unexpected findings that every backend, cloud, and systems engineer needs to know.

1. The Raw Empirical Data (108 Passes, Averaged)

All benchmarks were executed on an isolated 4-core Intel Xeon compute environment running Linux kernel 6.6 with 16GB RAM. Every test was repeated three times back-to-back to eliminate filesystem cache warming bias.

Dataset A: Source Code & Web Text (50.00 MB)

Simulates minified JS bundles, CSS sheets, HTML documents, and Markdown trees.

Dataset B: Structured API Payloads / JSON (50.00 MB)

Simulates real-world API responses with repetitive keys, timestamps, geographic metadata, and UUIDs.

Dataset C: High-Entropy Pseudorandom Binary (50.00 MB)

Simulates encrypted blobs, media containers, or already-compressed archives.

Finding #1: The “Brotli Quality Cliff” Will Destroy Your API Server

Look closely at the numbers for brotli on the JSON API payload:

• Level 1: Compresses at 210.0 MB/s in 0.43 seconds. Output: 10.12 MB.
• Level 4: Compresses at 44.9 MB/s in 1.28 seconds. Output: 10.18 MB.
• Level 6: Compresses at 10.9 MB/s in 4.73 seconds. Output: 10.08 MB.
• Level 9: Compresses at 2.3 MB/s in 22.28 seconds. Output: 10.02 MB.
• Level 11: Compresses at 0.3 MB/s in 169.67 seconds. Output: 8.10 MB.

Read that again: 169.67 seconds. That is nearly 3 full minutes of 100% CPU core pinning to compress a single 50MB JSON payload!

Brotli -q 1:  [████████████████████████████████████████] 210.0 MB/s  (0.43s)
Brotli -q 6:  [██] 10.9 MB/s  (4.73s)
Brotli -q 9:  [▏] 2.3 MB/s  (22.28s)
Brotli -q 11: [] 0.3 MB/s  (169.67s -> 394x slower!)

Why does this happen?

At quality levels 10 and 11, Brotli completely changes internal algorithms. It abandons fast hash-chains and executes exhaustive combinatorial modeling: searching through context models, evaluating secondary block splits, and computing multi-candidate entropy evaluations.

If someone configures their Nginx, Caddy, or Node.js reverse proxy with brotli_comp_level 11 for on-the-fly dynamic compression, a handful of concurrent API requests will completely saturate the server’s CPU, spiking TTFB (Time to First Byte) into catastrophic multi-second timeouts.

Production Rule: Never use brotli -q 7 through 11 dynamically. Brotli quality 11 is strictly a pre-compression build-step tool for static .js, .css, and .svg files inside your CI/CD pipeline.

Finding #2: Decompression Asymmetry (The Hidden Cloud Cost)

Most engineering benchmarks focus obsessively on compression ratio and compression speed. But in real distributed systems, data is typically compressed once and decompressed thousands of times.

Think about your infrastructure:

• An API server serializes and compresses a response once. Hundreds of clients or downstream microservices decompress it.
• A central logger compresses log batches once. Elasticsearch, ClickHouse, or Athena workers decompress billions of lines continuously.
• A Docker registry stores layer tarballs once. Kubernetes nodes decompress them on every container pull.

Look at the decompression throughput across our 108 runs:

DECOMPRESSION THROUGHPUT (Higher is better)
────────────────────────────────────────────────────────────
gzip (all levels):   [██] ~103 - 188 MB/s
Brotli (levels 4-9): [████████] ~685 - 811 MB/s
Zstandard (all lvl): [████████████] ~1,064 - 1,155 MB/s
────────────────────────────────────────────────────────────

Across every single data category, Zstandard decompressed at over 1,000 MB/s to 1,155 MB/s.

• Zstd is 6x to 10x faster to decompress than gzip.
• Zstd is 1.4x faster to decompress than Brotli.

What does 6x faster decompression mean in dollars?

If your Kubernetes cluster ingests 10 Terabytes of compressed logs daily, gzip decompression requires approximately 18 CPU core-hours just running DEFLATE bitstream unpacking loops.

Replacing that pipeline with Zstandard cuts the required compute time down to 2.5 CPU core-hours. That is an immediate 85% reduction in decompression compute spend, with zero infrastructure changes.

Finding #3: gzip -9 is an Anti-Pattern

Look at the standard gzip numbers for the JSON dataset:

• gzip -1: Compressed size: 12.42 MB | Speed: 61.1 MB/s | CPU: 1.27s
• gzip -6: Compressed size: 10.67 MB | Speed: 30.4 MB/s | CPU: 2.10s
• gzip -9: Compressed size: 10.23 MB | Speed: 13.8 MB/s | CPU: 4.07s

Going from gzip level 6 to level 9 consumes double the CPU time (2.10s vs 4.07s) and drops throughput from 30.4 MB/s to 13.8 MB/s—all to save a pathetic 0.44 MB (440 KB on a 50MB payload!).

Meanwhile, zstd -1 produced an output of 9.28 MB (smaller than gzip -9!) while running at 238.4 MB/s (17x faster than gzip -9) and using only 0.33 seconds of CPU.

Output Size Comparison (Smaller is better):
gzip -9 (Max):        10.23 MB  [Runs at 13.8 MB/s]
zstd -1 (Ultra-fast):  9.28 MB  [Runs at 238.4 MB/s -> 17x faster AND 1MB smaller!]

There is virtually no technical justification for running gzip -9 anywhere in 2026.

Finding #4: The Entropy Test (When Compression Fails)

What happens when your service receives an already compressed payload (like JPEG images, WebP assets, zip archives, or encrypted database snapshots)?

Look at the high-entropy binary results:

• gzip -6: Continues churning through the entire 50MB file at 20.5 MB/s, wasting 2.88 seconds of CPU before outputting a file that is actually larger than the input (50.01 MB).
• zstd -1: Detects the high entropy almost immediately, bypasses Huffman match trees, and finishes in 0.21s at 841.5 MB/s.
• brotli -q 1: Also detects non-compressible blocks and finishes in 0.12s at 739.5 MB/s.

Zstandard and Brotli have built-in entropy threshold pre-checks. If data redundancy drops below exploitable thresholds, they stop wasting cycles on brute-force search. Legacy gzip lacks this optimization and burns CPU blindly.

The 2026 Production Cheatsheet

Reproducibility & Methodology

All test scripts used in this benchmark were written in TypeScript and executed via the Bun runtime on Google Cloud Shell to ensure complete determinism:

• Datasets:
  • dataset_text_code.txt: 50MB concatenated source code, CSS flexbox layouts, HTML markup, and SQL queries.
  • dataset_api.json: 50MB array of 120,000 JSON records with repeated schema keys and random seeds.
  • dataset_random.bin: 50MB pseudorandom binary generated via Mulberry32 PRNG.
• Tools:
  • gzip 1.12
  • brotli 1.1.0
  • zstd 1.5.5
• Verification: Every decompression output was hashed with SHA-256 and matched against the uncompressed original to guarantee bitwise reproducibility.

Written by Shyam Charan Das for nshyam | stats — an empirical systems engineering lab.