What Is Gzip Compression? Smaller Files, Faster Pages

Jul 27, 2026 · SEO Glossary

During a performance audit last year, I found a site shipping 1.9 MB of JavaScript completely uncompressed. The developers had spent a sprint optimizing images and lazy-loading everything below the fold — genuinely good work — while a single missing server directive was costing them more transfer weight than all of it combined. The fix took four lines of nginx config and cut the JS payload to about 480 KB.

What is gzip compression? It's a method your web server uses to shrink text-based files — HTML, CSS, JavaScript, JSON, SVG — before sending them over the network. The browser announces it can handle compressed content, the server compresses the response on the fly, and the browser decompresses it on arrival. The user just gets the page faster. Typical savings on text files run 60–80%, which is why this is one of the first things any speed checklist looks for.

What is gzip compression doing under the hood?

Gzip is built on the DEFLATE algorithm, which exploits a simple truth: text repeats itself. HTML is full of recurring tag names, class attributes, and boilerplate; CSS repeats property names endlessly; JavaScript repeats keywords and identifiers. DEFLATE replaces repeated sequences with short back-references and then encodes frequent characters with fewer bits. The more repetitive the file, the better the ratio — which is why minified CSS still compresses beautifully but a JPEG doesn't compress at all (it's already compressed, and gzipping it wastes CPU for zero gain, occasionally even producing a slightly larger file).

The negotiation happens in HTTP headers. The browser sends Accept-Encoding: gzip, deflate, br with every request. If the server supports one of those encodings, it responds with Content-Encoding: gzip (or br) and the compressed body. No browser you need to care about lacks gzip support — it's been universal for two decades.

Gzip vs. Brotli: which should you use?

Brotli (the br encoding) is Google's newer algorithm and compresses text roughly 15–20% smaller than gzip at comparable settings. Every modern browser supports it over HTTPS. So should you bother with gzip at all?

The practical answer: serve Brotli where you can, keep gzip as the fallback. Most CDNs — Cloudflare, Fastly, CloudFront — handle this automatically. On your own servers, one nuance matters: Brotli at its maximum level (11) is slow to compress, so it's best for pre-compressed static assets (compress once at build time, serve forever), while dynamic HTML should use a moderate level, Brotli 4–5 or gzip 6, where compression is fast enough to happen per-request without adding latency.

Why this matters for SEO, concretely

Compression feeds directly into Core Web Vitals. Largest Contentful Paint depends on how quickly the browser receives HTML and render-blocking CSS — smaller transfers mean earlier rendering. Heavy JavaScript bundles delay interactivity, which shows up in Interaction to Next Paint. On a fast fiber connection the difference between 300 KB and 90 KB of CSS is barely perceptible; on a mid-range phone on 4G, it's the difference between a page that feels instant and one that makes the user watch a blank screen.

There's also a crawling angle people forget: Googlebot requests compressed content too. Smaller responses mean Google spends its crawl budget fetching more of your pages per visit — a minor effect on small sites, a real one on sites with tens of thousands of URLs.

How to check whether your site compresses properly

Three quick methods, in increasing order of thoroughness:

1. Browser DevTools. Open the Network tab, click any HTML/CSS/JS response, and look for content-encoding: gzip or br in the response headers. Compare the "transferred" column against the resource size — a big gap means compression is working.
2. Command line. curl -H "Accept-Encoding: gzip" -sI https://example.com | grep -i content-encoding shows you exactly what the server negotiates.
3. Crawl everything. Spot checks miss the interesting failures — compression enabled on the main domain but not the static subdomain, or on HTML but not on JSON API responses your pages fetch. A full-site audit flags uncompressed text resources across every URL in one pass, alongside the slow pages they cause.

The misconfigurations I actually find in the wild

• Missing MIME types. The server compresses text/html but nobody added application/javascript, image/svg+xml, or application/json to the list. SVG is the classic orphan — it's text and compresses by 50–70%, but servers treat it like a binary image.
• Compression lost behind a proxy. A reverse proxy or load balancer strips Accept-Encoding, so the origin never compresses. Everything looks configured; nothing actually is.
• Double compression of images and fonts. Gzipping JPEGs, WOFF2 fonts, and MP4s burns CPU for nothing. WOFF2 in particular has Brotli built into the format already.
• Compression level 9 on dynamic pages. Gzip 9 costs noticeably more CPU than level 6 for a size gain of 1–2%. Level 6 is the sensible default almost everywhere.

One caveat for completeness: don't confuse transfer compression with the rest of performance work. Gzip shrinks bytes on the wire — it does nothing about render-blocking resources, unoptimized images, or a bloated DOM. It's the cheapest win on the list, not the whole list.