Brotli vs Gzip: which one should your server use?
Both shrink your text before it hits the wire, and both are basically free speed. Here is the honest comparison — which compresses harder, which is faster, and when to reach for each.
Gzip is the old reliable; Brotli is the newer one that squeezes text a bit smaller. Use Brotli for cacheable static files where you can compress once and reuse, and Gzip (or light Brotli) for dynamic responses generated per request. Every modern browser supports both, so there's no real downside to offering them.
Compression is one of those wins that feels almost unfair. You flip it on, your pages get smaller before they're sent, they arrive faster, and your visitors never know it happened. The only real question is which compressor to use — and the answer is more interesting than "the newer one".
What compression actually does
Text — HTML, CSS, JavaScript, JSON — is wildly repetitive. The same tags, class names and keywords appear over and over. Compression spots those repeats and encodes them compactly, so a 200 KB file might travel as 40 KB and get rebuilt by the browser on arrival. Less data on the wire means faster loads, especially on mobile networks.
Compression only helps text. Images, video and fonts are already compressed — running Gzip over a JPEG just wastes CPU for no gain. Compress the text; optimize the media separately.
How they compare
| Gzip | Brotli | |
|---|---|---|
| Released | 1992 | 2015 |
| Typical text savings | ~70% | ~75–80% |
| Best for | Dynamic responses | Cacheable static files |
| Browser support | Everything | Everything modern |
| Max compression speed | Fast | Slower at top setting |
Brotli wins on size, particularly at its higher settings — but those higher settings are slower to compress. That trade-off is the whole story, and it's why the right answer depends on whether you're compressing once or every single time.
The static vs dynamic distinction
Here's the part people miss. If a file is static and cacheable — your CSS bundle, your app's JavaScript — you compress it once at the highest Brotli setting and serve that compressed copy thousands of times. The slow compression happens a single time and nobody waits for it.
If a response is generated fresh for every request — a personalized dashboard, an API call — you can't reuse a precompressed copy. There, a lighter compression level (Gzip, or Brotli at a low setting) gives you most of the savings without burning CPU on every request.
The good news: you don't have to choose
Browsers tell the server which compressors they support on every request, via the Accept-Encoding header. A good CDN reads that and serves the best option each browser can handle — Brotli where possible, Gzip as a fallback — and caches both. You enable it once and the right thing happens automatically.
Offer both. Let static files be Brotli-compressed hard and cached; let dynamic responses use a lighter setting. The browser and the CDN sort out the rest. It's a handful of kilobytes per file, which doesn't sound like much until you multiply it by every visit.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
