gzip vs Brotli: What the Difference Is Worth, and Why a Third of Public Sites Still Send Nothing
- vuetelemetry
- Guide
- 7 min di lettura
Brotli compresses text better than gzip, by a margin that is real and smaller than the marketing suggests. The bigger finding is elsewhere: in a measurement of 336 public bodies, 107 of those that answered send their homepage with no compression at all.
The comparison is usually framed as a choice, and for a new deployment it is. For most existing sites it is not, because the real question turns out to be whether anything is being compressed at all.
Cosa abbiamo misurato, e quanto costa
We measured 336 Portuguese public bodies on 6 September 2026, one request each, reading only the response headers and the size of the HTML on the wire. 291 answered. 107 of them, 36.8 %, sent their homepage with no content encoding whatsoever.
The cost of that is not theoretical. Among the sites that do compress, the median homepage weighs 29 312 bytes on the wire. Among those that do not, the median is 109 705 bytes. That is 3.7 times more data for the same kind of page, and eighteen of the uncompressed sites exceed 200 kB of HTML alone, the heaviest at 536 245 bytes.
Il confronto vero e proprio
Now the actual comparison. gzip has been universally supported since the 1990s and is the safe default. Brotli, standardised in 2016, is supported by every current browser over HTTPS and typically produces smaller output on text, with the gain concentrated in HTML, CSS and JavaScript rather than in already-compressed formats.
- curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding
- No content-encoding line at all means nothing is compressed
- content-encoding: br means Brotli was negotiated, gzip means the fallback
- Test over HTTPS: browsers do not offer Brotli over plain HTTP
- Restrict compression to text types; images and video gain nothing
The honest way to state the difference is that Brotli wins on text and the margin varies with the content and the compression level chosen. Anyone quoting you a single universal percentage is quoting a benchmark, not your site. Measure yours: it takes one request.
I livelli contano piu dell algoritmo
The level setting matters more than the algorithm choice, and it is where most misconfiguration lives. Brotli offers levels 0 to 11. Level 11 is slow enough that using it for dynamically generated responses can cost more server time than it saves in transfer. The usual arrangement is a high level for static assets compressed once at build time, and a moderate level for anything generated per request.
gzip has the same structure with levels 1 to 9, and the same trap: the maximum level is rarely the right one for dynamic content.
Negoziazione, HTTPS, e cosa non comprimere
Content negotiation decides which one is used, and it is not your choice alone. The browser sends `Accept-Encoding: gzip, deflate, br` and the server picks. Configuring both means modern clients get Brotli and everything else falls back to gzip, which is why this is not really an either-or decision.
One practical detail that catches people out: Brotli is only offered by browsers over HTTPS. A site tested over plain HTTP will appear to lack Brotli support when it has it.
Compressing already-compressed formats is wasted work. JPEG, PNG, WebP, MP4 and most font formats gain nothing and cost CPU. Restrict compression to text MIME types, which is the default in most sensible configurations and the first thing to check in the ones that are not.
Verificate il vostro sito con una richiesta
Checking your own site takes one command, and it is the same one we ran 336 times:
FAQ
Is Brotli always better than gzip?
On text, Brotli generally produces smaller output than gzip at comparable settings, and the margin depends on the content and the level chosen. It is not better on already-compressed formats such as JPEG or MP4, where neither algorithm helps. Configuring both is the normal answer, since the browser negotiates which one it gets.
How do I check whether my site compresses anything?
Send one request with an Accept-Encoding header and read the response: curl -s -I -H 'Accept-Encoding: gzip, br' https://example.com | grep -i content-encoding. If no content-encoding line comes back, nothing is being compressed.
Why does my site not use Brotli even though the server supports it?
The most common reason is that you tested over plain HTTP. Browsers only advertise Brotli over HTTPS, so an HTTP test makes a correctly configured server look as if it lacks support. The second most common reason is that the compression module is enabled but restricted to a MIME type list that does not include your content type.
Should I use the maximum compression level?
For static assets compressed once at build time, a high level is reasonable because the cost is paid once. For responses generated per request, the highest levels can cost more server time than the transfer they save. A moderate level for dynamic content and a high level for static files is the usual arrangement.
How much does missing compression actually cost?
In our measurement of 291 responding public bodies on 6 September 2026, the median homepage weighed 29 312 bytes on the wire where compression was active and 109 705 bytes where it was not, a factor of 3.7 for comparable pages. Eighteen uncompressed sites exceeded 200 kB of HTML alone.
**Compressing already-compressed formats is wasted work.** JPEG, PNG, WebP, MP4 and most font formats gain nothing and cost CPU. Restrict compression to text MIME types, which is the default in most sensible configurations and the first thing to check in the ones that are not.