HTTP Compression: The Easiest Performance Win Most Sites Still Miss
HTTP compression — gzip, deflate, or Brotli — can shrink HTML, CSS, and JavaScript responses by 60–80% on the wire. That translates directly into faster page loads, lower bandwidth bills, and better Core Web Vitals scores. Yet a surprising number of production sites still ship uncompressed assets, especially API endpoints and dynamic HTML.
gzip vs Brotli
gzip has been universally supported since 2000. Brotli (announced 2015) typically compresses 15–25% smaller than gzip for HTML and CSS at equivalent CPU cost. Most modern CDNs (Cloudflare, Fastly, AWS CloudFront, Vercel) support Brotli out of the box. Enable it.
What this tool does
We bypass Node’s automatic decompression and read the raw bytes directly from the socket — that gives us the actual transfer size, not what some library reports. We then decompress and measure the original payload, so the savings number you see is the literal byte difference visitors experience. We also probe with Accept-Encoding: identity to catch servers that are misconfigured.
Common findings
If we report no compression, your origin or CDN isn’t serving compressed responses for this URL — check your server config (nginx gzip on; / Apache mod_deflate / your CDN’s settings). If we report compression but the savings are weak (under 50%), the server may be using a low compression level — bump it up. If we report compression on already-compressed content (JPEG, MP4) the savings will naturally be tiny — that’s expected.