Compression is on but PageSpeed still warns: how to fix
You turned on Gzip or Brotli, maybe even saw it work, and PageSpeed Insights still asks for text compression. Depending on the version, it reports this either as Enable text compression, which lists every text file it received uncompressed, or under Document request latency, which looks at the HTML page itself. PageSpeed is not wrong: it judges the exact responses it got, while you probably tested one page in one browser, and somewhere between those two views a file goes out uncompressed. The checker on this page fetches any URL you give it with the same Accept-Encoding header a browser sends and shows the encoding the server returns, so you can go through the flagged files one by one.
Check your site
-
Read exactly what PageSpeed flagged
Expand the warning and copy the URLs listed under it. Note which of them are on your own domain and which are on other domains: fonts, analytics, chat widgets, maps and ad scripts come from their own servers, and no setting on your hosting can compress them. If only third-party files are listed, the fix is to drop or replace that script, not to change your server.
-
Check each of your own files
Paste the full URL of a flagged file, for example https://your-site.com/wp-content/themes/x/style.css, into the checker on this page. If the compression result shows gzip or br, that file is compressed now. If it says disabled, the server sent it raw, and the next steps explain why. Check the HTML page the same way, using the exact address PageSpeed tested, with the same https and www form.
-
Add the file types your rule leaves out
Server compression is configured by MIME type, and the lists in many copied snippets are old: they cover text/html and text/css but miss application/javascript or text/javascript, application/json, image/svg+xml, application/xml or older font formats such as font/ttf and application/vnd.ms-fontobject. Add the missing types to AddOutputFilterByType in .htaccess (Apache mod_deflate) or to gzip_types in nginx, where text/html is always compressed and everything else has to be listed. WOFF2 fonts, images and video are already compressed and do not belong in the list.
-
Find out who actually serves the file
A compression setting in a WordPress plugin or in PHP only covers the pages PHP generates, so static CSS and JS served directly by the web server stay uncompressed. On some setups nginx serves static files in front of Apache and never reads .htaccess at all. Turn compression on at the web server level, or ask the host to, instead of relying on a plugin.
-
Clear caches that hold old copies
A CDN or caching proxy may have stored an uncompressed copy before you enabled compression and keep serving it. Make sure responses carry Vary: Accept-Encoding, so caches keep compressed and plain versions apart, then purge the CDN and the caching plugin. On Cloudflare compression to visitors happens at the edge, but a file cached in a bad state still needs a purge.
-
Ignore files too small to matter
PageSpeed only lists files where compression would save a meaningful amount, roughly 1.4 KB and 10% of the file, and servers usually skip tiny responses on purpose. If a file of a kilobyte or two shows no compression in our check, that is normal and not what PageSpeed is complaining about.
How to verify the result
Run the checker on this page again for each file PageSpeed listed and for the page itself: all of your own text files should now show gzip or br. Then run PageSpeed Insights again. It fetches fresh copies, but with a CDN in front wait a few minutes after purging. If the warning remains only for third-party URLs, your part is done.
Tip: Do not stack compression layers. Turning it on in a plugin, in PHP (zlib.output_compression) and in the web server at the same time can produce double-encoded responses that browsers show as garbage or as ERR_CONTENT_DECODING_FAILED. Pick one place, preferably the web server or the CDN, and switch the others off.