Gzip and Brotli Compression: Full Guide for Nginx and Apache

Imagine: your site loads in 5 seconds, but 80% of the time is spent transferring JavaScript bundles. You've already optimized images, enabled caching, but speed barely improved. Most likely, you missed transport-level compression. We configure Gzip and Brotli on the server, reducing content size by 3–10x without code changes. Traffic savings can reach 70% with Brotli — lowering hosting and CDN costs.

Brotli gives 15–25% better compression than Gzip at comparable CPU load. One of our projects — an online store with a 1.2 MB bundle. After enabling Brotli with pre-compressed static assets, the size dropped to 280 KB, and LCP fell from 4.2 s to 1.8 s. For static files we use pre-compressed assets — .gz and .br files are generated at build time, the server serves them without re-compression. This saves up to 30% CPU time during peak loads.

Why Brotli outperforms Gzip?

Brotli uses a dictionary for HTML/JS/CSS, enabling tighter packing. For example, app.js 500 KB compresses to 130 KB (Brotli) vs 150 KB (Gzip). The difference is especially noticeable on mobile networks with limited bandwidth. Additionally, Brotli supports compression levels up to 11, allowing maximum compression for static assets during build. However, for on-the-fly compression, high levels (9–11) heavily load the CPU, so level 6 is recommended for dynamic content.

How to minimize CPU load during compression?

The primary method is to use pre-compressed static assets. .gz and .br files are generated once during the project build (e.g., using vite-plugin-compression), and the server serves them directly, saving CPU time on every request. For dynamic content (HTML, JSON), we apply on-the-fly compression at level 6 — a balance between compression ratio and load. During peak hours, you can disable compression for large files via the gzip_min_length 256 directive. CPU monitoring allows timely adjustment of compression levels — if load exceeds 80%, consider lowering the level or increasing gzip_min_length. Reducing CPU load lowers server resource costs.

Nginx: Gzip + Brotli

# /etc/nginx/nginx.conf or /etc/nginx/conf.d/compression.conf
# Gzip — supported everywhere
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6; # 1-9, CPU/compression balance; 6 is a good spot
gzip_min_length 256; # don't compress very small files
gzip_types application/javascript application/json application/xml application/rss+xml image/svg+xml text/css text/html text/javascript text/plain text/xml font/woff font/woff2;
# Brotli — requires ngx_brotli module
# Install: apt install libnginx-mod-brotli
brotli on;
brotli_comp_level 6;
brotli_types application/javascript application/json text/css text/html text/plain image/svg+xml font/woff2;

Verification:

curl -H "Accept-Encoding: br" -I https://example.ru/ # Response should contain: Content-Encoding: br
curl -H "Accept-Encoding: gzip" -I https://example.ru/ # Response: Content-Encoding: gzip

Pre-compressed static assets

For static files (JS, CSS, bundles) — generate .gz and .br files at build time, serve directly. No CPU overhead per request:

// vite.config.ts
import { defineConfig } from 'vite';
import viteCompression from 'vite-plugin-compression';

export default defineConfig({
  plugins: [
    viteCompression({
      algorithm: 'gzip',
      ext: '.gz'
    }),
    viteCompression({
      algorithm: 'brotliCompress',
      ext: '.br'
    }),
  ]
});

# Nginx: serve pre-compressed files
location ~* \.(js|css|woff2)$ {
    gzip_static on;  # looks for .gz version
    brotli_static on;  # looks for .br version (ngx_brotli module)
    expires 1y;
    add_header Cache-Control "public, immutable";
}

How to verify compression is working?

Use curl or the Network tab in DevTools. The response should include a Content-Encoding: br or gzip header. Also check for Vary: Accept-Encoding — it tells caching servers that content depends on encoding. For step-by-step diagnostics, you can use online services, like header checking tools.

If the client doesn't support Brotli, Nginx automatically falls back to Gzip or uncompressed content. Ensure the gzip on directive is enabled — this guarantees a fallback. Using a CDN with Brotli support further accelerates content delivery and reduces load on the origin server.

Typical compression results

Compression levels: recommendations

Levels 1–3 — low CPU load, weak compression. 4–6 — balanced. 7–9 — high compression, but CPU grows non-linearly: level 9 takes 3x more time than 6. For pre-compressed files, use 11 (Brotli only) — compiled once at build time.

Apache

# .htaccess
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/css application/javascript
    AddOutputFilterByType DEFLATE application/json image/svg+xml font/woff2
</IfModule>

Compression setup process

1. Analyze current server configuration (Nginx/Apache).
2. Choose compression levels (Gzip 6, Brotli 6 — balanced).
3. Configure exclusions (non-compressible formats: PNG, JPEG, MP4).
4. Generate pre-compressed files in the build (Vite, Webpack).
5. Verify response headers (Content-Encoding, Vary).
6. Monitor CPU load.

What's included in the work

• Configuration of Gzip and Brotli on the server (Nginx/Apache).
• Setup of pre-compressed static assets (if using a bundler).
• Header verification and compression testing.
• Documentation of changes made.
• Recommendations for compression levels based on your traffic.

Our engineers have been configuring compression for over 5 years — we've optimized load speed for 100+ projects, reducing LCP and TTFB by 40–60%. Want the same? Contact us — we'll perform an audit and implement Gzip and Brotli compression in one day. Order compression setup and get a consultation on accelerating your site today.