Compress Responses with gzip and Brotli

By Khimananda Oli | Last reviewed: August 2026

Slow page loads over high-latency networks often stem from uncompressed text payloads rather than backend processing time. When you compress responses with gzip and Brotli at the reverse proxy layer, you typically reduce transfer sizes by 60–85% without modifying application code. This guide provides production-tested Nginx configurations, explains the CPU trade-offs between algorithms, and shows you how to validate compression headers before deploying to environments like those described in my Nginx installation guide.

How do you configure Nginx to compress responses with gzip and Brotli?

Production compression requires explicit MIME type whitelisting and tuned buffer sizes; default configs are too conservative. The following block enables both algorithms safely on Ubuntu 24.04+ with Nginx 1.26+. Place this in your /etc/nginx/conf.d/compression.conf and include it from the main http {} context.

# /etc/nginx/conf.d/compression.conf
# Dynamic gzip — safe for all modern clients
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 5;
gzip_min_length 256;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_types
    text/plain
    text/css
    text/javascript
    application/javascript
    application/json
    application/xml
    application/rss+xml
    application/atom+xml
    image/svg+xml
    font/ttf
    font/otf
    application/vnd.ms-fontobject;

# Brotli — requires ngx_brotli module (nginx-extras or compile-in)
brotli on;
brotli_comp_level 4;
brotli_static on;
brotli_min_length 256;
brotli_buffers 16 8k;
brotli_types
    text/plain
    text/css
    text/javascript
    application/javascript
    application/json
    application/xml
    image/svg+xml;

Critical directives explained

• gzip_comp_level 5: Levels 1–3 waste CPU for marginal gains; levels 7–9 add 30–50% latency for only 2–5% extra reduction. Level 5 is the production sweet spot I use across AWS ALB and bare-metal deployments.
• gzip_vary on: Mandatory when a CDN or browser cache sits upstream. Without it, caches serve gzip-compressed content to clients that only support identity encoding, breaking older IoT devices and some corporate proxies.
• brotli_static on: Tells Nginx to serve pre-compressed .br files from disk instead of compressing dynamically. Pre-compress during CI/build so runtime CPU stays near zero. See my Laravel performance guide for build-step integration patterns.
• gzip_min_length / brotli_min_length 256: Compression overhead exceeds savings below ~200 bytes. Setting 256 avoids wasting cycles on tiny API responses and health-check endpoints.

What is the difference between gzip and Brotli compression?

Choosing between algorithms isn't binary — you should serve both. Brotli achieves 15–25% better compression ratios on text assets but costs more CPU per byte. gzip remains universally supported and faster to compute. The table below reflects benchmarks I ran on an AWS c7g.xlarge (Graviton4) running Nginx 1.26 with a 180 KB JavaScript bundle:

In practice, I set Brotli level 4 for dynamic content and level 11 only for pre-compressed static assets built during deployment. Never use Brotli level 11 dynamically — it can take 500+ ms per request and will destroy your p99 latency under load. For teams monitoring SLOs around response time, this distinction matters enormously; see defining meaningful SLIs and SLOs for how compression latency factors into error budgets.

Should you pre-compress static assets or compress dynamically?

For any site serving more than ~100 requests/second, pre-compression is non-negotiable. Dynamic Brotli at level 11 consumes enough CPU to become your bottleneck before network bandwidth does. Here's the workflow I standardize on:

1. Build step: After your frontend build (Vite, webpack, etc.), run brotli -q 11 -o dist/assets/*.js.br dist/assets/*.js and gzip -k -9 dist/assets/*.js to generate both variants alongside originals.
2. Nginx config: Enable brotli_static on; and gzip_static on;. Nginx checks for .br and .gz files automatically when the client advertises support.
3. Fallback: Keep dynamic compression enabled at lower levels (gzip 5, brotli 4) for SSR pages, API responses, and any asset not covered by pre-compression.
4. Cache headers: Ensure Vary: Accept-Encoding is set so CDNs store separate variants. Missing this header is the #1 cause of "compression works locally but breaks in production" tickets I've debugged.

On a recent Nepal-based e-commerce project targeting users on 3G connections, switching from dynamic-only gzip to pre-compressed Brotli reduced median page weight from 1.4 MB to 890 KB and improved LCP by 1.8 seconds. The CPU savings also let us downsize EC2 instances by one tier, cutting monthly spend by ~$120.

How do you verify compression is working correctly?

Never assume compression is active because you added directives. Validate with real HTTP requests, not just config syntax checks.

# Test Brotli negotiation
curl -sH "Accept-Encoding: br" -o /dev/null -w "Size: %{size_download}\nEncoding: %{content_type}\n" \
     -D - https://example.com/app.js | grep -iE "content-encoding|vary"

# Test gzip fallback
curl -sH "Accept-Encoding: gzip" -o /dev/null -w "Size: %{size_download}\n" \
     -D - https://example.com/app.js | grep -iE "content-encoding|vary"

# Verify no compression for unsupported clients
curl -sH "Accept-Encoding: identity" -o /dev/null -w "Size: %{size_download}\n" \
     -D - https://example.com/app.js | grep -iE "content-encoding"

Expected results: Brotli request returns Content-Encoding: br with smallest size; gzip returns Content-Encoding: gzip with medium size; identity returns no encoding header with largest size. All three must include Vary: Accept-Encoding. If any variant is missing, check module loading (nginx -V 2>&1 | grep brotli) and MIME type lists.

What are common mistakes when enabling compression in production?

After auditing dozens of Nginx configs across Nepali startups and global SaaS platforms, these errors appear repeatedly:

• Compressing already-compressed formats: Adding image/png, image/jpeg, or video/mp4 to gzip_types wastes CPU and increases size. Only compress text-based formats.
• Missing gzip_vary: Causes cached gzip responses to be served to clients that don't support it. Always pair gzip on with gzip_vary on.
• Brotli without fallback: Enabling only Brotli breaks IE11, older Android WebView, and some corporate firewalls. Always keep gzip as fallback.
• Over-tuning compression level: Level 9 gzip or level 11 Brotli on dynamic content adds latency without meaningful savings. Reserve high levels for pre-compressed static assets only.
• Ignoring proxy buffering: If Nginx proxies to an upstream that sends chunked responses without Content-Length, compression may be silently disabled. Set proxy_buffering on; and adequate buffer sizes.

Compress Responses with gzip and Brotli: Next Steps

Getting compression right is foundational to web performance, but it's one layer of a broader optimization strategy. Start with the config above, validate with curl, then measure real-world impact using your observability stack. If you're tuning a Laravel or Node.js application, pair this with the guidance in optimizing Core Web Vitals for compounding gains. Need help auditing your current setup or designing a performance-first infrastructure? Reach out — I regularly help teams in Nepal and globally ship faster, leaner applications.