Gzip/Brotli compression checker

HTTP compression shrinks text responses (HTML, CSS, JavaScript, JSON, SVG) before sending them over the network. A typical HTML page compresses 3–10×: 200 KB of raw markup transfers as 30–50 KB on the wire. The browser decompresses on arrival, invisibly to the user, so the entire benefit is faster page load — directly improving Time to First Byte, First Contentful Paint, and Largest Contentful Paint, the three metrics Google uses for Core Web Vitals scoring. Compression costs the server a small amount of CPU at response time, but modern servers negotiate it transparently via the Accept-Encoding request header and Content-Encoding response header, so enabling it is usually a one-line config change with no downside.

What this tool checks

• Content-Encoding header — presence of br, gzip, or deflate in the server response (parsed case-insensitively as a comma-separated list per RFC 7231)
• Compression type — whether the server chose Brotli (optimal), gzip (fine), or deflate (non-standard)
• Compression ratio — compressed vs. uncompressed size, reported as absolute bytes and percentage saved
• Vary: Accept-Encoding — when compression is in use, the response must declare Vary: Accept-Encoding so intermediate caches (CDN, reverse proxy) don't serve a compressed body to a client that requested identity

Difference between gzip, Brotli, and deflate

• gzip — classic DEFLATE-based compression, universally supported, compresses text resources by 70-80%. The safe default
• Brotli (br) — developed by Google, compresses 15-25% better than gzip on text content. Supported by all current browsers. Per the spec, browsers only advertise br over HTTPS; gzip is sent over both HTTP and HTTPS
• deflate — uses the same DEFLATE algorithm as gzip with different framing (zlib vs. gzip wrapper). Identical compression ratio but worse historical client compatibility; nginx and Apache don't serve it by default
• Recommendation — enable Brotli as primary and gzip as fallback. Clients negotiate automatically via Accept-Encoding, so there's no downside to offering both

How to enable server compression

• Nginx (gzip) — gzip on; gzip_types text/plain text/css application/javascript application/json image/svg+xml; gzip_vary on; in the server block. Defaults only cover text/html, so gzip_types is important
• Nginx (Brotli) — install the ngx_brotli module (nginx-extras on Debian/Ubuntu, or compile with --add-module=ngx_brotli), then brotli on; brotli_types ...;
• Apache — enable mod_deflate (gzip) and mod_brotli; add AddOutputFilterByType DEFLATE text/html text/css application/javascript
• Node.js / Express — the compression middleware handles gzip out of the box. For Brotli, use @fastify/compress, shrink-ray-current, or put a compressing reverse proxy in front
• CDN — Cloudflare, AWS CloudFront, Fastly, and Vercel all compress on the edge by default; if compression is missing on a CDN-fronted site, a cache rule or custom config usually disabled it

Good vs bad examples

Good — Brotli with correct Vary header:

Content-Encoding: br
Content-Length: 38412
Vary: Accept-Encoding

Good — gzip with correct Vary header (safe default):

Content-Encoding: gzip
Content-Length: 45120
Vary: Accept-Encoding

Bad — no compression on a text response:

Content-Type: text/html
Content-Length: 198432
(no Content-Encoding header)

Bad — gzip without Vary header (CDN may refuse to cache, or serve a gzip body to a non-gzip client):

Content-Encoding: gzip
Content-Length: 45120
(no Vary header)

Non-standard — deflate (works, but unusual and worse compatibility than gzip):

Content-Encoding: deflate
Content-Length: 45120

Common mistakes

• Compressing images with gzip/Brotli — JPEG, PNG, WebP, and AVIF are already compressed; re-compressing them adds CPU cost with near-zero size savings and sometimes slightly increases size. Restrict gzip_types / brotli_types to text MIME types only
• Forgetting API / JSON endpoints — nginx's default gzip_types only covers text/html; API endpoints returning application/json stay uncompressed unless you add the MIME type explicitly. Same for SVG (image/svg+xml)
• Missing Vary: Accept-Encoding — shared caches (CDN, corporate proxy) may either refuse to cache the response at all, or serve a compressed body to a client that didn't ask for compression. Use nginx's gzip_vary on; to add it automatically
• CDN stripping compression — a custom page rule or transform rule on Cloudflare / CloudFront may disable compression for specific paths. If the origin compresses but the audit sees no compression, check the CDN config before blaming the origin
• Double compression — a server compressing content that's already being compressed by an upstream proxy or load balancer. Usually causes broken responses rather than missed optimization