Every time your server sends HTML, CSS or JavaScript, it can compress it first — shrinking the bytes that travel across the network, so pages arrive faster. It's one of the easiest performance wins there is, usually a single config flag. The two compression methods you'll meet are gzip and Brotli. Here's the difference and how to choose.
Why compression matters
Text-based files (HTML, CSS, JS, SVG, JSON) are highly compressible — often shrinking by 60–80%. Smaller files mean less to download, which means faster page loads, especially on slow connections. And it's essentially free: the browser decompresses automatically.
Note: this is for text. Images and video are already compressed in their own formats, so gzip/Brotli don't help there (that's what image optimization is for).
Gzip: the universal workhorse
Gzip has been around for decades and is supported by everything — every browser, every server. It's fast to compress and decompress, and it reliably shrinks text well. For years it was simply the answer.
Brotli: the modern upgrade
Brotli (from Google) is the newer algorithm, and it generally compresses text smaller than gzip — especially at higher settings, and especially for the kind of repetitive text web files contain. It's now supported by all modern browsers and is increasingly the default.
Side by side
| gzip | Brotli | |
|---|---|---|
| Support | Universal (everywhere) | All modern browsers |
| Compression ratio | Good | Better (smaller files) |
| Best for | Maximum compatibility | Best size on modern clients |
| Speed | Very fast | Fast (higher levels slower to compress) |
The practical answer: use both. Serve Brotli to clients that support it (almost all of them now) and fall back to gzip for the rest. Most servers and CDNs negotiate this automatically based on the browser's
Accept-Encodingheader — you just enable both.
A note on compression levels
Both algorithms have levels trading compression for CPU time:
- For static assets (cached and served repeatedly), compress once at a high level — you pay the CPU cost a single time for maximum savings.
- For dynamic responses (generated per request), use a moderate level so you're not burning CPU on every response.
This is why pre-compressing static files (or letting your CDN handle it) is ideal.
How to turn it on
You rarely write code for this:
- Enable compression in your web server, framework, or CDN config.
- Prefer Brotli with gzip fallback — most modern stacks support both out of the box.
- Confirm it's working — check the response headers for
content-encoding: br(Brotli) orgzip.
You can inspect those headers on any URL with an HTTP header checker.
The bottom line
| In one line | |
|---|---|
| What | Shrink text files before sending them — free speed. |
| gzip | Universal, fast, good ratio. |
| Brotli | Smaller files; the modern default. |
| Do | Enable both — Brotli with gzip fallback. |
Compression is one flag away from a meaningfully faster site. Turn on Brotli with a gzip fallback, compress static assets at a high level, and your text files travel 60–80% lighter — at no cost to quality.
Related: How to speed up your website, image optimization; check headers with the free HTTP header checker.