What Is Text Compression (Brotli & gzip)? Complete Guide (2026)

Why Uncompressed Text Files Slow Down Every Page Load

Text resources (HTML, CSS, JS) sit at the front of the critical path — the browser cannot render or become interactive until they arrive and parse. Shipping them uncompressed amplifies every other performance problem:

• Slower TTFB and FCP: The HTML document is the first byte the browser receives. Compressing it cuts the time-to-first-byte for the rest of the page.
• Slower LCP: Render-blocking CSS and JS must arrive before the largest contentful paint can occur. Compressed text means less network time and earlier LCP.
• Mobile data costs: Visitors on metered plans pay for every kilobyte. Saving 70% on text resources is a real cost saving, not just a speed metric.
• CDN egress bills: Compressed responses cost less to serve. At scale, enabling Brotli on a high-traffic site routinely cuts text egress in half.
• Search rankings: Slower TTFB and LCP hurt Core Web Vitals, which are confirmed ranking signals. Skipping compression is one of the cheapest performance wins to leave on the table.

How Audits Detect Missing Compression

The audit reads each response's Content-Encoding header. Any text response over 1.4 KB without gzip, br, or deflate in that header is flagged. Worked example for a typical missing-compression report:

Resource             Original   Encoded    Savings
-------------------- ---------- ---------- ----------
/index.html             56 KB      —         flagged
/styles/main.css        82 KB      —         flagged
/js/app.bundle.js      612 KB      —         flagged
/api/products.json     140 KB      —         flagged
/icons/logo.svg          8 KB      —         flagged
-------------------- ---------- ---------- ----------
Total                  898 KB

Estimated transfer with Brotli:    ~210 KB
Estimated savings:                 ~688 KB (77% smaller)

On this page, enabling Brotli alone removes nearly 700 KB from the transfer — roughly the difference between a passing and failing Total Byte Weight audit.

Brotli vs. gzip: Which Should You Use?

Both. Modern servers and CDNs negotiate compression based on the browser's Accept-Encoding request header — they serve Brotli to clients that support it and fall back to gzip for everyone else.

Practical rule: enable Brotli at level 4–6 for dynamic responses (HTML), pre-compress static assets (CSS/JS) with Brotli at level 11 once at build time, and keep gzip enabled as the fallback.

How to Check If Compression Is Working

You don't need a full audit to verify — a single curl command does it:

• Greadme deep scan — surfaces every uncompressed text resource on the page, broken down by file, and pairs each finding with an AI-generated server-config fix or one-click GitHub PR.
• Greadme crawler scan — checks compression coverage across every indexable URL on your site, so you can spot specific routes (often API endpoints or JSON responses) that slip through.
• Chrome DevTools → Network tab — click any request and look at "Response Headers" for content-encoding: br or content-encoding: gzip. The "Size" column shows transferred vs. resource size.
• Google Search Console — slow TTFB and LCP on the Core Web Vitals report often trace back to missing compression on the HTML document.

For a one-line CLI check:

# Verify Brotli is active for a JS file
curl -I -H "Accept-Encoding: br" https://yoursite.com/main.js \
  | grep -i content-encoding

# Expected output:
# content-encoding: br

# If you see no header at all, compression isn't enabled.
# If you see "content-encoding: gzip", Brotli isn't configured
# but the gzip fallback is — still good, but not optimal.

8 Ways to Enable and Optimize Text Compression

# /etc/nginx/conf.d/compression.conf

# gzip (universal fallback)
gzip on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_vary on;
gzip_types
  text/plain text/css text/xml
  application/javascript application/json
  application/xml application/rss+xml
  image/svg+xml;

# Brotli (modern browsers, HTTPS)
brotli on;
brotli_comp_level 5;
brotli_min_length 1024;
brotli_types
  text/plain text/css text/xml
  application/javascript application/json
  application/xml application/rss+xml
  image/svg+xml;

# httpd.conf or .htaccess
<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS \
    text/html text/plain text/css text/xml \
    application/javascript application/json \
    application/xml image/svg+xml
</IfModule>

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

# Generate .br and .gz alongside each output file
brotli -q 11 dist/main.js          # creates main.js.br
gzip  -9 -k dist/main.js           # creates main.js.gz

# Nginx: serve pre-compressed file when client supports it
location ~* \.(js|css|svg|json)$ {
  brotli_static on;
  gzip_static   on;
}

Common Compression Problems and Fixes

Compression Thresholds and Targets

FAQ

What is the audit threshold for text compression?

Any text resource larger than 1.4 KB served without a Content-Encoding: gzip, br, or deflateresponse header is flagged. Files under 1.4 KB aren't flagged because the per-response framing overhead of compression isn't worth the savings on tiny payloads.

Should I use Brotli or gzip?

Both. Modern servers and CDNs negotiate per request: they serve Brotli to clients that advertise br in Accept-Encodingand fall back to gzip for everyone else. Brotli compresses text 15–25% smaller than gzip at comparable CPU cost, so it's the preferred default for HTTPS traffic.

Is text compression a Google ranking factor?

Not directly — but it strongly improves TTFB, FCP, and LCP, all of which feed Core Web Vitals. LCP is a confirmed ranking signal, and skipping compression is one of the easiest ways to fail it. In practice, enabling Brotli is one of the cheapest SEO performance wins available.

Will compression hurt my server's CPU?

At sane levels (Brotli 4–6, gzip 6) the CPU cost is small and almost always dwarfed by the network savings. For static assets, pre-compress once at build time (Brotli level 11) and the runtime cost drops to zero. CDNs handle this automatically when you toggle Brotli on — origin CPU isn't affected.

What about compressing images, video, or fonts?

Don't. JPEG, PNG, WebP, AVIF, MP4, WebM, and woff2 are already compressed internally. Re-running gzip or Brotli over them spends CPU for zero (or negative) savings. Keep your compression MIME-type list strictly to text formats: HTML, CSS, JS, JSON, SVG, XML, plain text.

Does text compression matter for AI search engines like ChatGPT and Perplexity?

Indirectly, yes. AI-driven systems (Google AI Overviews, generative answer engines) preferentially cite pages that already rank well in traditional search. Slow TTFB and LCP from missing compression hurt Core Web Vitals → hurt rankings → reduce your odds of being chosen as a citation. Compressed pages compete better in both surfaces.

How do I know if my site is already using compression?

Run curl -I -H "Accept-Encoding: br, gzip" https://yoursite.com/ and look for a content-encoding line in the response headers. br means Brotli is active, gzip means gzip-only, no header means compression isn't configured. For a full per-resource breakdown across every page on your site, run a Greadme deep scan.