No Text Compression, and the Switch Nobody Turned On
One site we watch sends every page with the compression switch off. Not a slow server, and not a heavy design. The files arrive at full size because nothing on the way out is shrinking them, and the report names it no text compression.
This is one of the few findings that has nothing to do with how the page was built. Everything it needs is a setting on the server, or on the CDN sitting in front of it.
It is also the cheapest item on the list. There is no layout to rebuild and no plugin to configure carefully. One switch, and every text file your site sends gets smaller.
The browser asks, the server shrinks
Every browser asks the same question when it requests a page. It advertises the compression formats it can unpack, Brotli and gzip in anything still in support, and waits to see which one comes back.
A server with compression on answers with a smaller copy and labels it in a Content-Encoding header. With the switch off, the raw file goes out and that header never appears.
The finding fires only when neither Brotli nor gzip is present, which is why it carries high severity rather than a warning. There is no partial version of this. Either the bytes are being shrunk on the way out or they are not.
Text is where that matters most. HTML, CSS and JavaScript typically compress by 60 to 80 percent, making this the largest single reduction available to a page that is mostly code.
The cheapest fix in the report
Our global analytics page shows how common the gap still is. Across the sites we test, Brotli is in use on 37 percent and GZIP on 17 percent.
Read even the most generous version of those two figures and it leaves close to half the sites sending text at full size. Compression is not an advanced optimisation. It is a baseline that many sites never switched on.
Where the points actually land
Compression does not appear anywhere in the performance score. That gauge is assembled from the measured Core Web Vitals and two modifiers, and compression is not one of them.
That is a fact about the formula rather than the effect. Smaller text arrives sooner, and the metrics the performance gauge reads are measured on the page as it arrives, so compression reaches that score by the side door.
It moves a pillar you cannot see instead. The report calculates a caching and delivery score and folds it into the overall figure without ever drawing a gauge for it. That pillar carries 20 percent of the overall score.
Inside the pillar, Brotli is worth 25 points of the 100 and gzip is worth 18. Carried through the overall weighting, Brotli is worth about five points on the score at the top of your report, and gzip about four.
Five points for one server setting is a better return than most of what the performance section will ask of you. The report-reading walkthrough explains how the pillar scores combine if that arithmetic is new.
Turning text compression on
On nginx it is a directive for gzip, and a second one for Brotli if that module is compiled in. Typing it out is rarely your job, but it helps to recognise what your host has done for you.
# nginx, in the server block gzip on; gzip_types text/css application/javascript application/json; brotli on; brotli_types text/css application/javascript application/json; # Apache, with mod_deflate AddOutputFilterByType DEFLATE text/html text/css application/javascript
If you ever read that file, one detail matters. HTML is compressed the moment the directive is on, so listing it among the types is redundant, and nginx logs a warning about a duplicate MIME type if you do.
Most WordPress owners never open either file. On managed hosting the switch usually sits in the control panel, or in the caching plugin the host installs, and LiteSpeed servers expose it inside their own cache plugin.
If a CDN sits in front of the site, check there first. Compression can be handled at the edge, and the edge is also where it sometimes gets left off while the origin is doing everything right.
One thing it will not shrink. Images, video and web fonts are already compressed formats, so the saving lands on your text and code rather than your pictures. A page that is mostly photographs will feel this change far less.
One header tells you
After the change, open the page in a browser and look at the document request in the developer tools. A Content-Encoding line reading br or gzip is the proof, and its absence means the setting did not take.
The simpler confirmation is to run another test. The finding clears because the report reads the compression from the response rather than asking you to take its word for it.
If the flag survives, the switch is not reaching the requests that matter. That is usually a directive set in the wrong block, or a CDN rewriting the response on the way through.
A page that is mostly text, which is most pages, carries that full uncompressed weight on every single visit. The page weight guide covers where that weight piles up beyond the text.
