gzip, Brotli and Zstandard are the algorithms a web server uses to compress
text before it goes over the wire. The browser lists what it accepts in the
Accept-Encoding request header, the server picks one and names it in the
Content-Encoding response header, and the browser decompresses it before parsing. They
apply to text: HTML, CSS, JavaScript, SVG and JSON. Images, video and fonts arrive in
already-compressed formats and are left alone.
The three in practice
At their default settings Brotli produces a smaller file than gzip on the same HTML, and Zstandard sits between them while costing the server less CPU. All three are supported by every current browser, and gzip additionally by everything older, which is why it is still the safe default rather than the best one.
The differences are smaller than the numbers in benchmark tables suggest, because compression level matters as much as algorithm choice. Brotli at its maximum level is slow enough that servers usually apply it only to files they compress once and cache, not to pages they generate per request.
Almost nobody serves raw text any more
Uncompressed HTML is the classic first finding on a slow site, and it has largely stopped being true. We asked 428 sites in our audit base directly, with the header a browser sends: 13 came back with no compression at all, and eight of those were 114-byte placeholder pages on parked domains. That leaves five real pages in 428. The full method and the caveats are in Five sites in 428 serve HTML uncompressed.
So the useful question is not whether text is compressed. It is which algorithm answered, and that turned out to be decided somewhere the site owner never looks.
The platform picks, not the site
Across the same 428 sites, measured 24 August 2026, the split was gzip 53%, Brotli 37%, Zstandard 7%. Grouped by platform it stops looking like a distribution:
| Platform | Algorithm |
|---|---|
| Wix | Brotli, 28 of 28 |
| Squarespace | gzip, 35 of 35 |
| Tilda | gzip, 33 of 33 |
| Duda | gzip, 43 of 44 |
| WordPress and WooCommerce | Brotli 60%, gzip 25%, Zstandard 14% of 111 |
A hosted builder answers with one voice because one team configured the edge for everyone on it. WordPress is the only group in that sample that gives three different answers, and the reason is that the choice belongs to the host and the stack rather than to the CMS. These are sites we chose to audit, not a sample of the web.
What it does and does not buy you
Compression reduces transfer size, so it shortens the download of each text file. It does
not change how many files there are, what order the browser is allowed to use them in, or
whether a stylesheet blocks the first paint. A page with a compressed but render-blocking
<head> still waits for that head.
That is why “enable text compression” ranks where it does in a Lighthouse report on most modern sites: it is either already done, or it is worth a fraction of what the blocking matters. The exception is real and worth checking once, because when a server does send raw HTML the file is often several times larger than it needs to be.
Turning it on
On shared hosting, the practical answer is usually gzip rather than Brotli, and our own site is the worked example of why: we enabled Brotli at maximum level and the page got measurably slower, because the compression ran per request on a CPU we shared. The recipe and the measurement are in gzip or Brotli on shared hosting.
What our proxy does with the response
Pages served through our proxy are compressed with Brotli where the browser accepts it and gzip otherwise, applied to the rewritten HTML rather than to the original. Compression is the cheap half of what happens to a response; the part that moves the score is the reordering of the critical path that happens before it.