The fix, in one snippet
gzip on;
gzip_min_length 256;
gzip_types text/html text/css application/javascript application/json;
gzip_vary on;Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
We request each page with Accept-Encoding: gzip, deflate, br and read the Content-Encoding of the response. Pages larger than 30 KB that come back with no encoding are reported with their transferred size.
Small responses are excluded deliberately. Below a few kilobytes the compression header and the CPU cost outweigh the saving, and most servers are configured not to bother; that is correct behaviour rather than a fault.
Why it matters
HTML compresses extremely well, typically to a fifth or less of its original size, because it is repetitive text. Serving it raw means every visitor downloads several times more data than necessary, and the delay lands in the critical path before anything can render.
The effect is largest exactly where it matters most: slow mobile connections, which is how most people arrive. Time to First Byte and Largest Contentful Paint both improve immediately, and both feed into Core Web Vitals.
It is also one of the few optimisations with no downside and no maintenance: it is a server setting, not a change to your code.
How to fix it
Enable compression at the edge for text types. On nginx:
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css text/xml application/json application/javascript
application/xml+rss image/svg+xml;
gzip_vary on;Brotli compresses roughly 15 to 20 per cent better than gzip for text and is supported by every current browser; enable it alongside gzip rather than instead of it. If a CDN sits in front, check it is compressing rather than assuming the origin is.
Verify: curl -sI -H 'Accept-Encoding: gzip, br' https://example.com/ | grep -i content-encoding.
Where this fits
HTML served uncompressed is check 2 of 7 that the seo & site health audit runs under technical seo and speed, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Viewport meta tag missing (high), where without a viewport meta tag, mobile browsers render the page at desktop width and shrink it. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
HTML served uncompressed closes one route in. Immediately below it: Render-blocking scripts in the head, where synchronous scripts in the head stop the parser; Slow server response, where how long the server took to return each page; http:// references on HTTPS pages, where links from an HTTPS page to http:// URLs cost a redirect on every click and expose the first request.
Found in the same scan
The seo & site health audit reports this alongside checks from other categories that are at least as serious, including Broken internal links, where an internal link that returns an error is a dead end for the reader and a wasted request for the crawler, and Crawl errors (4xx / 5xx), where uRLs reached during the crawl that returned a client or server error. A single run of seo & site health audit answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: HTML served uncompressed (medium severity)
Scanner check id: seo-compressionThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.