gzip or Brotli: what to switch on, and what it costs

Check what you send today

One request answers it. Ask for the page the way a browser does and read the response header:

curl -sSI -H 'Accept-Encoding: gzip, br, zstd' https://yoursite.com/ \
  | grep -i content-encoding

An empty result means the text is going out raw. That is worth checking and it is also worth not assuming: we asked 441 sites in our audit base the same question and 13 of the 428 that answered sent HTML with no compression, eight of which were placeholder pages. The interesting variation is which algorithm you get, and on a hosted platform that was decided for you: every Wix site in that sample answered with Brotli, every Squarespace and Tilda site with gzip.

Our own site was one of the exceptions. It shipped about 126 KB of HTML with no Content-Encoding header at all, while the same page through our proxy came back Brotli-compressed at roughly 26 KB. On a throttled mobile connection that difference is around half a second of transfer, landing on First Contentful Paint, Largest Contentful Paint and Speed Index at once.

What Brotli-11 cost us

The site runs on shared hosting (LiteSpeed). The textbook move is an .htaccess line, so we switched on maximum-quality Brotli:

Metric	No compression	Brotli-11, per request
PageSpeed, mobile	99	99
Speed Index	1.6 s	3.8 s

Speed Index more than doubled. Brotli at its highest quality is expensive in CPU, and a shared host has modest cores contended with every other tenant. Compressing 126 KB of HTML on every single request added more server time than the smaller payload saved. The page arrived smaller and later.

The configuration that scored 100

We dropped Brotli and enabled gzip only. It compresses slightly worse and costs almost nothing to run:

Metric	None	Brotli-11	gzip
PageSpeed, mobile	99	99	100
Speed Index	1.6 s	3.8 s	2.2 s

# Apache / LiteSpeed .htaccess
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript \
    application/javascript application/json image/svg+xml
</IfModule>

Getting Brotli sizes anyway

None of this is an argument against Brotli. It is an argument against compressing on every request on hardware you share. Build .br files once at deploy time and let the server hand them over as static files: you get the smaller payload with no per-request cost. On a dedicated box, or behind a CDN that compresses and caches the result, per-request Brotli is free and the whole trade-off disappears.

What to take from this

• Check before you fix. Raw text is a real problem and a rare one, so the one-line check above is worth running and the assumption is not worth making. We made it, from a sample of one, and printed it for a month.
• On shared hosting, start with gzip. The ratio is a little worse and the CPU cost is a rounding error, which is the trade that matters when the CPU is the scarce thing.
• Compression level is a server-time decision, not a bytes decision. The bytes-on-the-wire comparison says Brotli-11 wins every time. Time to paint said the opposite here, and time to paint is what the visitor experiences.
• Let the score arbitrate, three runs at a time. The difference between 1.6 s and 3.8 s is far outside run-to-run noise, but a one-point score move is not — see how to run the test.