Enable Text Compression: gzip/Brotli and How to Fix It

What "Enable text compression" means

This check fires when your server sends text-based files — HTML, CSS, JavaScript, SVG, JSON — without a Content-Encoding header, meaning they travel the wire uncompressed. Text compresses beautifully (often 70–90% smaller), so shipping it raw wastes bandwidth and delays first paint. The stakes land squarely on Core Web Vitals: a bloated main document pushes back Largest Contentful Paint, and on mobile connections that delay is measured in whole seconds.

A real example: seeing the header

The whole thing hinges on one response header. A compressed response looks like this:

$ curl -I -H "Accept-Encoding: gzip, br" https://example.com/style.css

HTTP/2 200
content-type: text/css
content-encoding: br          ← compression is ON (Brotli here)
vary: Accept-Encoding

If content-encoding is missing entirely, the file went out raw and the check fails. The fix is to turn compression on at the server. On Apache with mod_deflate:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript 
    application/javascript application/json image/svg+xml
</IfModule>

On Nginx, enable gzip (and Brotli if the module is compiled in):

gzip on;
gzip_comp_level 5;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;
gzip_vary on;

Brotli vs. gzip: what to reach for

Ship Brotli to clients that advertise it and fall back to gzip for the rest. The Vary: Accept-Encoding header keeps proxies and CDNs from caching the wrong version.

How to detect it on your own site

1. curl -I (the fastest check): Run curl -I -H "Accept-Encoding: gzip, br" https://yoursite.com/ and look for a content-encoding line. No line means no compression.
2. Lighthouse: DevTools → Lighthouse → Performance. "Enable text compression" appears under Opportunities with the estimated KB and time savings per file.
3. PageSpeed Insights: Run the URL through PageSpeed Insights — the same opportunity lists every uncompressed resource.
4. DevTools Network tab: Load the page, click a CSS or JS request, and compare "Size" (transferred) against "Content" (uncompressed). If they are identical, that file was not compressed.

Why the wire size, not the disk size, is what hurts

A 120 KB JavaScript bundle sitting on your server costs nothing until someone requests it. The moment they do, that 120 KB has to cross the network — and on a mid-tier mobile connection, that transfer alone can take the better part of a second before the browser has even started parsing. Compression attacks exactly this stretch of the timeline. Gzip or Brotli can turn that 120 KB into roughly 30 KB on the wire, and because the browser decompresses in a few milliseconds, the user gets the full file far sooner with no visible cost. The main HTML document is the highest-value target of all: it is the very first thing requested, and until it arrives nothing else can even be discovered, so compressing it directly shortens the critical path to first paint.

This is why compression is one of the highest leverage single toggles in performance work. It touches every text asset at once, it requires no code changes, and it compounds with every other optimization you make. A minified stylesheet that is also compressed is smaller than either technique achieves alone, and the savings apply on every request, for every visitor, forever.

How to fix it

1. Flip it on at the server. Apache: enable mod_deflate or mod_brotli. Nginx: set gzip on and add the Brotli module. This is the durable fix.
2. Let the CDN do it. Cloudflare, Fastly, and most CDNs compress at the edge with a single toggle — often the quickest win if you cannot touch server config.
3. WordPress on shared hosting: Many caching plugins expose a "gzip compression" switch; enabling it writes the right .htaccess rules for you.
4. List every text type. A common miss is compressing HTML but forgetting JSON, SVG, or web-font formats — add them to the MIME list.
5. Re-test with curl. Confirm the content-encoding header appears on each flagged file type, not just the homepage.

False positives and gotchas

Do not try to compress images with gzip — JPEG, PNG, and WebP are already compressed, and running them through gzip wastes CPU for zero gain. That belongs to image encoding, a different check. Also watch for a CDN that strips or overrides your origin's encoding; if curl shows compression at the origin but not at the public URL, the edge is the culprit. And if Lighthouse still complains after you enabled it, you are likely testing a cached response — purge and retest.

FAQ

Will compression slow down my server?

Barely, and it is a trade you want. Compressing HTML at gzip level 5–6 costs a millisecond or two of CPU to save tens of kilobytes over the wire. For static assets, pre-compress once at build time and the runtime cost is zero.

Is text compression the same as minification?

No. Minifying CSS and minifying JavaScript rewrite the file to remove whitespace; compression wraps whatever bytes you send in gzip or Brotli on the wire. Do both — minify first, then compress the minified output for the biggest reduction.

Do I need to compress images too?

Not with gzip. Images need format-level optimization — serving WebP or AVIF and encoding efficiently — not text compression.

I enabled it but the check still fails. Why?

Usual suspects: a CDN caching the pre-fix uncompressed version, a MIME type you forgot to add to the list, or the Accept-Encoding request header being stripped by a proxy. Curl each file type directly to isolate where the header disappears.

Does compression help SEO directly?

Indirectly but meaningfully — smaller responses mean faster loads, and page speed feeds Core Web Vitals, which is a ranking signal. See our guide on improving page speed on WordPress.