Response compression

What this check looks for

This check reads the Content-Encoding response header for gzip, brotli (br), zstd, or deflate. If one is present, it passes. If absent but the document is 20KB or smaller, it also passes — compression overhead isn't worth flagging on documents that small. If absent on a larger document, it warns, reporting the uncompressed size.

Why it matters

Text-based responses like HTML compress extremely well — often 60-80% smaller — because of how repetitive markup and text tend to be, so skipping compression on anything but the smallest documents leaves an easy, essentially free performance win on the table. Every metric downstream of the initial download benefits: less data to transfer means a faster effective load time, especially on slower or metered mobile connections where every kilobyte matters more. This is one of the lowest-effort, highest-impact fixes in the whole performance category, since most web servers and CDNs support it as a one-line configuration change.

How to fix it

Enable compression at the server or CDN layer:

# nginx
gzip on;
gzip_types text/html text/css application/javascript application/json;

# Most CDNs (Cloudflare, Fastly, CloudFront) support brotli automatically —
# confirm it's enabled for your zone/distribution.

Note that some proxies strip the Content-Encoding header even while still compressing the response — if you're confident compression is enabled but this check still warns, verify with a direct request to the origin.