Apprendre
Gzip vs Brotli: Choosing HTTP Compression
Brotli compresses text roughly 15–20% smaller than gzip at comparable settings. The decision is not which one — it is serving both and letting the client choose.
Lancez un audit DomainLens frais et utilisez le rapport comme liste de priorités.
How the two compare
Both are negotiated through Accept-Encoding, so serving both costs nothing: the client advertises what it supports and the server picks. Brotli where available, gzip as the fallback, is the whole strategy.
| gzip | brotli | |
|---|---|---|
| Ratio on text | Good | ~15–20% better |
| Browser support | Universal | All modern browsers, HTTPS only in practice |
| Compress speed | Fast at all levels | Slow at high levels, fine at low |
| Decompress speed | Very fast | Comparable |
| Best for | Dynamic responses | Static files compressed ahead of time |
Static versus dynamic changes the answer
For files that do not change between requests — your built CSS and JS bundles — compress once at build time using brotli's highest level. The CPU cost is paid once and every visitor gets the smallest possible file.
For responses generated per request, high-level brotli is a poor trade: you spend real CPU on every hit for a few extra kilobytes saved. Use a low brotli level or plain gzip there. This is why the "brotli is slow" claim is both true and irrelevant — it describes level 11 on dynamic content, which nobody should be doing.
# Dynamic responses: cheap and fast
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json
application/javascript text/xml
application/xml image/svg+xml;
# Pre-compressed static files, built at deploy time
brotli_static on;
gzip_static on;
# Note: woff2 is already compressed — listing it
# here wastes CPU for no size reduction.What to compress and what to leave alone
The most common misconfiguration is a compression type list copied from a blog post that includes image and font types. It costs CPU on every request and saves nothing, because those formats have no redundancy left to remove.
The second most common is compressing nothing at all, which is the default on a surprising number of stacks. A framework that sets its own Content-Type headers can bypass the server module entirely, and a CDN in front may strip the encoding and forward the response uncompressed. Both look identical from the application side, which is why the only reliable check is reading the response header from outside.
Content negotiation also has a caching consequence. A shared cache holding one response must know that the compressed and uncompressed variants differ, which is what Vary: Accept-Encoding declares. Without it a proxy can serve a brotli-encoded body to a client that never asked for one, producing a page that fails to render for reasons nothing in the markup explains.
- Compress: HTML, CSS, JavaScript, JSON, XML, SVG, plain text.
- Do not compress: JPEG, PNG, WebP, AVIF, MP4, WOFF2 — all already compressed internally.
- Skip very small responses. Below roughly 256 bytes the framing overhead can exceed the saving.
- Never compress a response that is already encoded; double compression grows the payload.
What compression is worth in practice
Text compression typically cuts HTML, CSS and JS to a quarter or a fifth of their original size, which shortens the critical path and helps LCP on slow connections. That is a genuine performance win, but it is a one-time fix rather than an ongoing lever: once text is compressed, compressing it better yields very little. If LCP is still poor afterwards, the cause is elsewhere — work through what LCP measures rather than tuning compression levels.
How DomainLens contributes
DomainLens reports the Content-Encoding a URL returns, so an uncompressed text response shows up in the audit rather than in a page-speed report weeks later. Check any URL directly with the HTTP headers checker , and pair it with the Cache-Control header for the rest of the delivery picture.
- Should I use brotli or gzip?
- Both. Serve brotli to clients that advertise support and gzip to everything else — the negotiation is automatic and costs nothing.
- Does compression affect SEO?
- Indirectly. Smaller transfers improve load time, which feeds Core Web Vitals. Compression itself is not a ranking signal.
- Why is brotli sometimes slower?
- Because its highest levels are computationally expensive. That matters only when compressing per request; for static files compressed once at build time it is irrelevant.
- Should I compress images?
- No. JPEG, PNG, WebP and AVIF are already compressed. Running gzip over them burns CPU and can make the response marginally larger.