Enable text compression: what it means and how to fix it

Quick answer: This audit flags text responses served without gzip or Brotli compression. Enable it at the server (nginx, Apache) or let a CDN like Cloudflare or Vercel compress automatically. It typically cuts HTML, CSS, and JavaScript transfer size by 60 to 80 percent, speeding up first paint.

Lighthouse fails this audit when text-based responses (HTML, CSS, JavaScript, JSON, SVG) are served without gzip or Brotli compression. Compressing them typically cuts transfer size by 60-80%, which speeds up FCP and LCP directly.

TL;DR

• What: Text assets sent uncompressed (no Content-Encoding: br or gzip).
• Why it matters: Uncompressed text wastes bandwidth on the critical path, delaying first paint and interactivity.
• Fix: Enable Brotli or gzip at the server or CDN. Usually a one-line config change.

What does the text-compression audit check?

Lighthouse inspects the Content-Encoding response header on each text resource. If a compressible response over ~1.4 KB lacks br or gzip, it is listed with the potential byte savings.

Why does text compression matter?

Text assets compress extremely well because they are repetitive. A 300 KB JavaScript bundle is often ~80 KB gzipped and ~70 KB with Brotli. Those bytes sit on the critical rendering path: the browser cannot paint or run the page until they arrive. Compression is one of the cheapest, highest-return performance fixes because it requires no code changes.

How do I enable text compression?

Most modern hosts compress automatically. If you are on Vercel, Netlify, Cloudflare, or Fastly, this audit usually fails only because of a misconfiguration or an origin that bypasses the CDN.

nginx

gzip on;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;
gzip_min_length 1024;

# Brotli (requires the ngx_brotli module)
brotli on;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

Apache

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

Node / Express

const compression = require('compression');
app.use(compression());

CDN

Cloudflare, Vercel, Netlify, and Fastly compress text responses automatically. If the audit still fails, check that responses are not being served directly from an uncompressed origin and that Cache-Control is not preventing the CDN from transforming them.

What are common text-compression mistakes?

• Compressing images and fonts too. WebP, AVIF, JPEG, and WOFF2 are already compressed. Re-compressing wastes CPU for no gain. Only target text MIME types.
• Missing application/json or image/svg+xml. Default config lists often omit these, so API responses and inline SVGs ship uncompressed.
• Origin uncompressed behind a CDN. If the CDN passes through and does not re-compress, the user still gets raw bytes.
• Content-Encoding set but body not actually compressed. A broken proxy can mislabel responses; verify the actual transferred size.
• Compression disabled for HTTPS by an old proxy rule (a legacy "BREACH" overcorrection). Modern setups compress HTTPS text safely.

How do I verify text compression is enabled?

1. Re-run Lighthouse: "Enable text compression" should pass.
2. DevTools → Network → click an HTML/CSS/JS response → Response Headers: confirm content-encoding: br or gzip.
3. Compare the "Size" (transferred) vs "Content" (decoded) columns in the Network panel: transferred should be far smaller.
4. curl -sH 'Accept-Encoding: br,gzip' -o /dev/null -D - https://example.com/app.js | grep -i content-encoding.

Related audits

• First Contentful Paint (FCP), smaller text reaches the browser sooner
• Eliminate render-blocking resources, compression shrinks the blocking CSS/JS
• Largest Contentful Paint (LCP), faster critical-path delivery improves LCP

Audit your URL at https://lighthouse-md.com.