Here is a fact that surprises many site owners: the HTML, CSS, and JavaScript your server sends can usually be shrunk by 70 to 90 percent before transmission — and the browser will transparently expand it back on arrival. This magic is text compression, and it is one of the simplest, most effective performance optimizations in existence.
Two algorithms dominate the web: Gzip, the battle-tested veteran that has powered the web since the 1990s, and Brotli, the newer challenger from Google that squeezes files even smaller. Both are free, both are widely supported, and choosing between them (or using both) takes only a few minutes of server configuration.
In this guide, we will compare Gzip and Brotli on compression ratio, speed, browser support, and CPU cost, show you how to check whether compression is working on your site with a gzip test, and help you decide which one deserves a place in your stack.
HTML, CSS, and JavaScript are highly repetitive — the same tags, property names, and variable patterns appear hundreds of times. Compression algorithms exploit that repetition by replacing repeated sequences with short references, much like writing "see above" instead of repeating a paragraph.
The process is invisible to everyone involved:
Accept-Encoding header listing the algorithms it supports (for example, gzip, deflate, br).Content-Encoding header.Typical results are dramatic: a 200 KB JavaScript bundle often compresses to 50 KB with Gzip and 40 KB with Brotli. That is the difference between a page that feels instant and one that stalls on a slow connection — achieved with zero changes to your code.
Gzip is based on the DEFLATE algorithm and has been compressing web traffic since 1992. Its strengths are maturity and ubiquity:
Brotli was developed by Google and released in 2015, designed specifically with web content in mind:
How do they stack up in practice? Here is the honest breakdown:
Brotli wins, consistently. On typical web assets:
On a 500 KB total payload, switching from Gzip to Brotli might save an additional 30–50 KB. On slow mobile connections, that translates directly into faster rendering.
Gzip wins, by a wide margin at high compression levels. Gzip level 6 (the common default) compresses several times faster than Brotli at quality 11 (its maximum). For dynamic content — API responses, personalized HTML — Gzip's speed advantage makes it the pragmatic choice.
The smart compromise: use Brotli at moderate quality (4–6) for dynamic content, where it is nearly as fast as Gzip but still compresses better, and reserve maximum-quality Brotli for static assets that are compressed once and served millions of times.
Both are fast enough that it barely matters. Brotli decompression is roughly comparable to Gzip — modern phones decompress either algorithm in milliseconds. This is not a decision factor.
Gzip works everywhere, including ancient browsers and HTTP connections. Brotli requires HTTPS and a modern browser — which describes over 95 percent of real traffic in 2026, but the edge cases (old embedded devices, some bots) still need Gzip as a fallback. Fortunately, servers can offer both and let the browser choose.
Maximum-quality Brotli is CPU-hungry — up to 10x slower than Gzip to compress. On a busy server generating dynamic pages, that cost adds up. The standard solution is tiered: pre-compress static assets at maximum quality during your build process (CPU cost paid once), and use fast settings for dynamic responses.
This is not really an either-or decision. The optimal setup, used by most high-performance sites, is:
With this configuration, modern visitors get the smallest possible files, legacy visitors still get compressed responses, and your server stays healthy. There is no downside — the browser automatically picks the best option it supports.
For Gzip, the gzip module is built in. For Brotli, install the ngx_brotli module, then configure both. Most managed hosts and CDNs (Cloudflare, for example) enable Brotli with a single toggle in their dashboard.
Enable mod_deflate for Gzip. Brotli requires mod_brotli, available in Apache 2.4.26 and later. Both are straightforward configuration additions.
If you use a CDN — and you should — check its settings first. Most major CDNs compress automatically or with one click, often preferring Brotli when the browser supports it. This is the easiest path: no server configuration at all.
Most caching plugins (WP Rocket, W3 Total Cache, LiteSpeed Cache) handle compression automatically, or your host may enable it server-wide. If not sure, the plugin settings usually have a Gzip/Brotli toggle.
Configuration mistakes are common — a typo can silently disable compression while everything else looks fine. Always verify:
Content-Encoding: br (Brotli) or Content-Encoding: gzip.After confirming compression works, run a page speed checker to see the impact on overall performance scores. Compression alone often improves load times by 30 percent or more on text-heavy pages.
Compression is for text. Applying it to already-compressed formats is pure waste:
Configure your server to compress only text-based MIME types: text/html, text/css, application/javascript, application/json, image/svg+xml, and similar. Everything else should pass through untouched.
For file size, yes — Brotli consistently produces smaller output. But Gzip compresses faster and works over plain HTTP and on ancient clients. The best practice is enabling both and letting the browser negotiate the best option, rather than choosing one exclusively.
All modern browsers (Chrome, Firefox, Safari, Edge) support Brotli, but only over HTTPS connections. If your site still serves traffic over plain HTTP, those visitors will get Gzip instead. Given that HTTPS is now standard, this is rarely a practical limitation.
Minimally, if configured sensibly. Static assets should be pre-compressed once at build time (zero per-request cost). For dynamic content, use moderate compression levels — the CPU cost is small compared to the bandwidth and time savings. Only maximum-quality Brotli on every dynamic response would be a concern, and nobody configures it that way.
Text compresses extremely well. Typical reductions: HTML 70–80 percent, CSS 75–85 percent, JavaScript 65–75 percent with Gzip; Brotli shaves an additional 15–25 percent off those numbers. A 1 MB total text payload often drops below 200 KB after Brotli compression.
Yes — run any URL through a gzip test. It works on any public website, so you can benchmark competitors and see whether they use Gzip, Brotli, or nothing at all. If a competitor is not compressing, that is an easy performance edge for you to claim.
Text compression is the closest thing to a free lunch in web performance: a few minutes of configuration, zero ongoing maintenance, and dramatically smaller payloads forever. Enable both Gzip and Brotli, verify with a gzip test, and confirm the overall impact with a page speed checker. Your mobile visitors will feel the difference immediately.
