Gzip vs Brotli: Web Compression Compared

Why Compression Matters

Every byte transferred over the network costs time. A 500KB JavaScript bundle takes 100ms to download on a 40 Mbps connection — but compressed to 150KB with Brotli, it takes only 30ms. Multiply this across all resources (HTML, CSS, JS, JSON, SVG) and compression can reduce page load time by 50–70%.

Web compression works by finding redundant patterns in text-based files and replacing them with shorter representations. Both Gzip and Brotli are lossless — the original data is perfectly reconstructed on the client side. The browser advertises supported encodings via the Accept-Encoding header, and the server responds with the compressed version.

Gzip: The Established Standard

Gzip has been the default web compression since the mid-1990s. It uses the DEFLATE algorithm (a combination of LZ77 and Huffman coding). Virtually every browser, server, CDN, and proxy supports it.

# Nginx Gzip configuration
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 256;
gzip_types
    text/plain
    text/css
    text/javascript
    application/javascript
    application/json
    application/xml
    image/svg+xml
    application/wasm;

Gzip compression levels range from 1 (fastest, least compression) to 9 (slowest, most compression). Level 6 is the common default — it offers a good balance between compression ratio and CPU cost.

Brotli: The Modern Alternative

Brotli was developed by Google and released in 2015. It uses a combination of LZ77, Huffman coding, and a pre-defined dictionary of common web content (HTML tags, CSS properties, JavaScript keywords). This dictionary gives Brotli a significant advantage for web content specifically.

# Nginx Brotli configuration (requires ngx_brotli module)
brotli on;
brotli_comp_level 6;
brotli_min_length 256;
brotli_types
    text/plain
    text/css
    text/javascript
    application/javascript
    application/json
    application/xml
    image/svg+xml
    application/wasm;

Brotli levels range from 0 to 11. Levels 0–4 are comparable in speed to Gzip. Levels 5–9 are significantly slower but produce smaller output. Levels 10–11 are extremely slow and only suitable for static pre-compression.

Head-to-Head Comparison

Real-World Compression Results

Typical compression ratios for common web assets:

Static Pre-Compression

For static assets (CSS, JS, SVG), pre-compress files at build time with maximum compression. The server serves the pre-compressed file directly without compressing on each request:

# Pre-compress at build time
gzip -9 -k dist/app.js        # Creates app.js.gz
brotli -q 11 dist/app.js      # Creates app.js.br

# Nginx serves pre-compressed files automatically
gzip_static on;    # Serve .gz files if they exist
brotli_static on;  # Serve .br files if they exist

This gives you the best of both worlds: maximum compression ratio (level 11 Brotli) without any CPU cost at serving time. Build pipelines should generate both .gz and .br versions of every static asset.

What NOT to Compress

Compression is counterproductive for:

• Images (JPEG, PNG, WebP, AVIF) — already compressed by their format. Compressing again wastes CPU and may increase size
• Video and audio (MP4, WebM, MP3) — already compressed
• Compressed archives (ZIP, tar.gz) — already compressed
• Very small files (<150 bytes) — compression overhead exceeds savings. Set gzip_min_length 256
• Fonts (WOFF2) — already Brotli-compressed. WOFF is Gzip-compressed

Configuration Best Practices

• Enable both — configure Brotli as primary, Gzip as fallback. Browsers that support Brotli get smaller files; older clients get Gzip
• Dynamic content: level 4–6 — for HTML, JSON, and API responses generated on each request, use moderate compression. CPU cost matters here
• Static content: maximum level — pre-compress at level 9 (Gzip) / 11 (Brotli) and serve with *_static on
• Set Vary: Accept-Encoding — tells caches to store separate versions for different encodings. Without this, a cache may serve a Brotli-compressed response to a client that only supports Gzip
• Test with real content — compression ratios vary by content type. Test your actual assets to verify improvements

Verifying Compression

# Check compression with curl
curl -I -H "Accept-Encoding: br,gzip" https://example.com/
# Look for: Content-Encoding: br (or gzip)

# Check compressed size
curl -s -o /dev/null -w "%{size_download}" \
    -H "Accept-Encoding: br" https://example.com/assets/app.js

# Use Enterno.io HTTP headers checker to verify
# Content-Encoding header on any URL

Conclusion

Brotli is the superior choice for web compression — it produces 15–25% smaller files than Gzip for typical web content, with comparable decompression speed. Use Brotli as your primary encoding with Gzip as fallback. Pre-compress static assets at maximum level, use moderate levels for dynamic content, and always verify compression is active via response headers. This single optimization can reduce bandwidth costs and improve page load times significantly.