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

What this means

Text-based resources are plain-text files: your page HTML, stylesheets, scripts, JSON API responses, SVG images, and XML. These files are highly repetitive, which means they compress extremely well before being sent over the network. When compression is enabled, your server delivers a smaller compressed copy and the browser unpacks it instantly.

This audit fires when one or more of those text files are served uncompressed. The two standard algorithms are Brotli (newer, more efficient, signalled as br) and gzip (older, universally supported). A correctly configured response carries a Content-Encoding header set to br or gzip. If that header is missing on a text file, the file went out raw, and the audit flags it.

Why it matters

Uncompressed text wastes bandwidth on every single request, for every visitor. A 200 KB uncompressed JavaScript bundle can drop to roughly 50 KB with Brotli, meaning the browser fetches a quarter of the data. Multiply that across all your CSS and JS, and across thousands of page views, and the savings in transfer time are substantial, especially on mobile networks where bandwidth is the bottleneck.

Smaller payloads arrive faster, which directly improves how quickly the browser can render. Render-blocking CSS and JavaScript clear sooner, your largest content paints earlier, and the whole page feels quicker. That feeds straight into Largest Contentful Paint and the rest of your Core Web Vitals. Because Vitals are scored on what real users experience in the field, not just in the lab, enabling compression is one of the cheapest, highest-leverage wins available. See field vs lab data for why that distinction matters.

How it gets flagged

Lighthouse loads each text-based response and checks for a compression Content-Encoding header (br, gzip, or deflate). For any uncompressed text file it then compresses the file itself to estimate the potential saving. The audit only flags a response when both conditions are true:

• The resource is larger than 1.4 KiB, and
• Compressing it would save more than 10 percent of its size.

Tiny files and already-efficient files are ignored, so the warning points only at responses where compression is genuinely worth it. Each flagged URL is listed with its current size and the estimated saving.

How to fix it

Compression is a server-side or CDN-side setting. Pick the path that matches your stack. Brotli is preferred because it compresses text better than gzip; keep gzip enabled as the fallback for any client that does not advertise Brotli support.

Apache (.htaccess or vhost)

Enable mod_deflate for gzip across common text MIME types:

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

If your Apache build includes mod_brotli, add Brotli as well:

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

Nginx (nginx.conf or server block)

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

# Requires the ngx_brotli module
brotli on;
brotli_comp_level 5;
brotli_types text/plain text/css application/javascript
             application/json image/svg+xml application/xml;

Note that stock Nginx does not bundle Brotli; you add it via the ngx_brotli module. The gzip on; block works out of the box.

Host, CDN, or WordPress

Most managed hosts and every major CDN (Cloudflare, Fastly, BunnyCDN, KeyCDN) support Brotli and gzip with a single toggle, often on by default. If you are on a CDN, enable compression there first; it applies globally without touching your origin config. On WordPress, a caching plugin such as WP Rocket, LiteSpeed Cache, or W3 Total Cache can switch on compression for you. After any change, reload and confirm the response carries Content-Encoding: br or gzip in your browser DevTools Network tab.

False positives

Some flagged-looking situations are not real problems:

• Already-compressed binary files. Images (JPEG, PNG, WebP, AVIF), fonts (WOFF2), video, and ZIP archives are already compressed. Do not gzip them; doing so wastes CPU and can slightly enlarge them. Lighthouse only targets text resources, so these should never appear here. If they do, your config is over-broad.
• CDN or proxy stripping the header. Compression may be active at your origin but a misconfigured proxy re-buffers the response uncompressed. Check the Content-Encoding header at the edge, not just at origin.
• Third-party assets. Scripts served from domains you do not control (ad, analytics, widget vendors) can be flagged even though you cannot fix them. Focus on your own origin; for chronic third-party offenders, consider self-hosting.

FAQ