Enable text compression

When Lighthouse or PageSpeed Insights reports Enable text compression, the server is sending HTML, CSS, JavaScript, JSON or SVG files uncompressed. Every one of those files could travel across the network as a much smaller compressed stream and be unpacked by the browser in a fraction of a millisecond. It is one of the cheapest fixes in web performance: no code changes, one server or CDN setting, and the saving applies to every visitor from the first request on.

From PerfDelta's measurements: Lighthouse reports this finding on 4% of 4,108 measured home pages. The median estimated saving is 454 ms. More in the data section below.

What the audit checks

Lighthouse looks at every text-based response the page loads and compares the transferred size with the size it would have after compression. A resource counts as a finding when the response is text (HTML, CSS, JavaScript, JSON, XML, SVG and similar types), was not served with a Content-Encoding header for br, gzip or deflate, and compression would save a meaningful share of its bytes. Binary files such as images, video and WOFF2 fonts are already compressed and are not part of this audit.

In the PageSpeed Insights report the finding lists the affected URLs with the potential saving. In recent Lighthouse versions the check for the main HTML document moved into the document request latency insight, which also covers redirects and server response time. The fix is the same.

How compression works between server and browser

The browser announces what it can decode in every request header: Accept-Encoding: gzip, deflate, br, zstd. The server picks one of those, compresses the response body and marks it with Content-Encoding: br (or gzip). The browser decompresses on arrival. Both steps are fast compared with the time the extra bytes would take on a mobile connection, which is why compression is a net win even on small files above a kilobyte or two.

Two algorithms matter in practice:

• Gzip is supported by every browser and every server. It is the safe baseline.
• Brotli (br) is supported by all current browsers and typically produces smaller files than gzip for text at a comparable decompression cost. Compression itself is slower at high levels, so Brotli is best used for pre-compressed static files at a high level and for dynamic responses at a moderate level.

A server that offers both will use Brotli for browsers that accept it and fall back to gzip for the rest. Compression ratios depend on the content: minified JavaScript and CSS with repetitive patterns compress very well, already-compressed data not at all.

How to enable text compression

1. Check what the server sends today

Request a CSS or JavaScript file with a browser-like header and look at the response headers:

curl -sI -H "Accept-Encoding: br, gzip" https://example.com/assets/app.js | grep -i content-encoding

No content-encoding line means the file is uncompressed. Check the HTML document too, since application servers and static file servers are often configured separately.

2. Apache

Gzip through mod_deflate, usually already installed:

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

Brotli needs mod_brotli (Apache 2.4.26 or later) with AddOutputFilterByType BROTLI_COMPRESS for the same types. On shared hosting these modules are often enabled centrally; the hosting control panel or a support ticket is the quickest way to find out.

3. Nginx

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

Brotli is available as the ngx_brotli module (brotli on; brotli_types ...;). Many distributions ship Nginx without it, so check with nginx -V before relying on it.

4. CDN and hosting platforms

Cloudflare, Fastly, Akamai, CloudFront, Vercel and Netlify compress text responses at the edge, usually by default or with a single toggle. Shopify, Wix, Squarespace and Webflow compress their own assets, so this finding on those platforms almost always points at a third-party script or an external file you embed, not at the platform. On WordPress hosting the setting sits with the host; caching plugins can add gzip only if the server allows it.

5. Pre-compress static files at build time

For assets that do not change between deployments, compress once at the highest level and let the server serve the .br or .gz file next to the original. Build tools do this with a plugin (for example compression plugins for webpack, Vite or Rollup), and Nginx serves them with gzip_static on; and brotli_static on;. This removes the CPU cost from the request path entirely.

6. Verify and keep it verified

Run the curl check again and look for content-encoding: br or gzip, then re-run PageSpeed Insights. Add the check to your deployment smoke test, because compression is the kind of setting that silently disappears after a server migration or a CDN change.

What compression does not fix

Compression shrinks transfer size, not the amount of work the browser has to do. A 1 MB JavaScript bundle still has to be parsed and executed after it arrives, so reducing unused JavaScript and cutting execution time remain separate tasks. Compression also does nothing for images and fonts; those are covered by modern image formats and correct image sizing. Together with the step to minify CSS and JavaScript, it is the last mile for text, not the whole road.

Frequently asked questions

Should I use Brotli or gzip?

Both, where the server supports it. Brotli for browsers that accept it, gzip as the fallback. If only one is possible, gzip is universally supported and already captures most of the saving.

Does compression slow down the server?

Dynamic compression costs CPU per response, but at moderate levels the cost is small and far below the time saved on the network. For static files, pre-compressing at build time removes the cost from the request path entirely.

Why does Lighthouse still report the finding after I enabled compression?

Usually because one of the listed files comes from a different server, for example a third-party script, an external CSS file or a font CSS. Check the URLs in the finding; each origin needs its own compression setting.

Does compression help images or fonts?

No. JPEG, WebP, AVIF and WOFF2 are already compressed. Compressing them again saves nothing and wastes CPU, which is why they should be excluded from the compression types.