Nginx Compression: Gzip and Brotli Config for Faster Loads

Getting your site to load in under a second usually comes down to one thing: how much data you’re forcing the user's browser to download. While you should always look at bundle size optimization: auditing dependency graphs for faster loads to trim the fat from your source code, server-side compression is your final line of defense.

I’ve spent too many hours debugging slow LCP (Largest Contentful Paint) scores only to realize the server was sending raw, uncompressed JSON and HTML. Adding nginx compression is the highest ROI task you can perform to improve website performance.

Why Gzip isn't enough anymore

For years, Gzip was the gold standard. It’s fast, ubiquitous, and reliable. However, Brotli—developed by Google—consistently beats Gzip in compression ratios, especially for text-based assets like CSS, JS, and HTML.

We initially tried just enabling Gzip on a high-traffic project, but we saw about 15-20% better savings once we added the nginx brotli module. If you’re serious about reducing page load time, you should be serving both.

Configuring Nginx Gzip

Most Nginx installations come with the Gzip module pre-compiled. You can check this by running nginx -V 2>&1 | grep --color gzip. If it’s there, you’re ready to go.

Open your nginx.conf or your specific site block and add this configuration:

NGINX
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/x-javascript text/javascript;

Don't set gzip_comp_level to 9. It hits CPU usage hard for diminishing returns. Level 6 is the sweet spot for most production environments.

Implementing the Nginx Brotli Module

The Brotli module isn't always included in standard Nginx builds. You might need to compile it as a dynamic module or install it via your package manager (e.g., apt-get install libnginx-mod-http-brotli).

Once installed, your configuration will look something like this:

NGINX
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/x-javascript text/javascript;

Brotli vs Gzip: A quick comparison

Why you need both

You might wonder why you’d keep Gzip if Brotli is better. The answer is simple: fallbacks. Older browsers or specific proxy configurations might not support Brotli. By keeping Gzip enabled, Nginx will automatically serve the Gzip version when a client doesn't send the br flag in the Accept-Encoding header.

Just like we use API field projection: reducing payload size and server load to keep API responses lean, we use dual-compression to ensure the transport layer is equally efficient.

Common pitfalls and verification

The biggest mistake I see? Compressing images that are already compressed. Don’t waste CPU cycles trying to Gzip a JPEG or a PNG. Stick to text-based MIME types.

After you update your config, always test it. You can check the headers using curl:

Bash
curl -H "Accept-Encoding: br" -I https://yourdomain.com/main.js

Look for Content-Encoding: br in the response headers. If you don't see it, double-check your Nginx syntax with nginx -t and reload the service. If you're building a complex site, you might also want to look into next.js website & landing page development to ensure your initial build output is as clean as possible before the server even touches it.

FAQ

Does Brotli hurt my server's CPU? It’s more CPU-intensive than Gzip, yes. However, for most modern web servers, the impact is negligible compared to the bandwidth savings. If you're on a very constrained VPS, monitor your load averages after enabling it.

Can I use Brotli for everything? Stick to text-based assets. Compressing binary files like JPEGs, PNGs, or MP4s is a waste of resources because they are already compressed.

What happens if a user's browser doesn't support Brotli? Nginx handles this automatically. If the client doesn't include br in their Accept-Encoding request, Nginx will fallback to Gzip or plain text, depending on your configuration.

Final thoughts

Optimizing your delivery pipeline is never a "set it and forget it" task. While adding these modules is a massive win, keep an eye on your performance metrics. I’m still experimenting with shared brotli dictionaries: advanced payload optimization strategies for some of our larger SPA deployments, which promises even better results for repeated visits. Start with standard Gzip/Brotli, measure your improvements, and go from there.