Uncompressed resources: enable gzip or Brotli

What it means

One or more same-host CSS or JavaScript resources referenced by this page are served without content encoding. A production server should answer a request carrying Accept-Encoding: gzip, br with a compressed body and a Content-Encoding: gzip or Content-Encoding: br header. When that header is absent, the raw uncompressed bytes are sent — for text-based content that is typically 60–80% more bytes than necessary.

Why it matters

Total transfer size and Time to First Byte feed Largest Contentful Paint, a confirmed Google page-experience signal. Brotli routinely shrinks HTML, CSS and JS to 20–30% of their original size with no quality trade-off, so compression is one of the cheapest per-byte wins available. The effect is most visible on mobile and long-distance connections, and uncompressed responses also raise the bandwidth Googlebot spends per crawl, which can indirectly reduce crawl frequency. This is a lab-proxy Crawlinx derives from the response headers of the same assets Googlebot fetches.

How to fix it

1. Enable gzip or Brotli at the server or CDN. Nginx: gzip on; plus gzip_types text/html text/css application/javascript application/json; (and the ngx_brotli module for brotli on;).
2. Apache: AddOutputFilterByType DEFLATE text/html text/css application/javascript in httpd.conf or .htaccess.
3. Node/Express: app.use(require('compression')()).
4. On a CDN (Cloudflare, Fastly, CloudFront) enable compression in the dashboard; Cloudflare gzips by default and Brotli lives under Speed → Optimization.
5. Verify with curl -H "Accept-Encoding: gzip, br" -I https://example.com/ and confirm a Content-Encoding header comes back.

Example

GET /js/app.js
200 OK
Content-Type: application/javascript
(no Content-Encoding header)

GET /js/app.js
200 OK
Content-Type: application/javascript
Content-Encoding: br

Enable Brotli (br) or gzip for text assets at the server or CDN. Text typically shrinks 60-80% — the single highest-leverage transfer win for CSS/JS.

When it's not a problem

Already-compressed binary formats (JPEG, PNG, WebP, AVIF, WOFF2, PDF, ZIP) should NOT be re-compressed — Crawlinx only inspects text CSS/JS here and excludes binary media. If a CDN adds compression transparently, the response Crawlinx sees (the same one Googlebot sees) will carry the Content-Encoding header and the rule will not fire. This check only runs when asset inspection is enabled for the scan.

How Crawlinx detects it

We probe same-host CSS and JS assets and check for a Content-Encoding header. A text asset served with no gzip/br encoding is flagged, because it transfers far more bytes than it needs to.

How common is it?

Not yet observed in our audit sample. We publish this explainer because the check runs on every crawl; once an audited site trips it, this page will break the issue down by platform, gatekeeper, vertical and country.

FAQ

gzip or Brotli?

Brotli compresses text ~15-20% smaller than gzip and is supported by all modern browsers. Enable Brotli with a gzip fallback; most CDNs do this with a single toggle.

Which files should be compressed?

All text-based responses: HTML, CSS, JS, JSON, SVG, XML. Don't re-compress already-compressed binaries like JPEG, PNG, WebP or MP4 — it wastes CPU for no gain.

How do I turn on compression?

On nginx use gzip on / brotli on; on Apache mod_deflate/mod_brotli; on a CDN it's usually a checkbox. Verify with the Content-Encoding response header afterward.