HTTP compression and delivery signal audit
Paste a public URL. I’ll show you what’s actually going on with Gzip or Brotli on it. First HEAD headers, the GET page headers right beside them, the redirect trail, the cache context, all on one screen. Why bother? Because a bare “no compression” badge lies, and it lies a lot. Half the time you’re staring at a redirect that swapped the page out, or an image nobody ever meant to gzip. I got tired of squinting at a red dot and guessing which one it was.
Compression is negotiated per response, not per site. So I sample it carefully. The first header read hits the exact URL you typed, before anything chases a redirect. The GET page read only shows up when the backend can read the destination as HTML.
What a compression checker should prove
Compression is one of those wins nobody brags about. It’s free, though, and it’s real. Send HTML, CSS, JavaScript, JSON, XML or SVG over the wire with Gzip or Brotli negotiated properly and the transfer drops hard. Honestly, all I ever wanted from a checker was honesty. Show me the negotiation. Don’t scream “broken” the second a Content-Encoding header goes missing, because most of the time nothing’s broken. A redirect quietly swapped the real page out. Or HEAD answered one way and the browser’s GET would have answered another. Or, look, you pointed it at a JPEG that was already packed, and a second layer of compression buys you basically nothing.
So this one keeps the context right there in the report instead of tossing it. It reads the exact first response. It grabs the GET page headers when the backend can read the destination as HTML, walks the redirect rows, pulls out Content-Encoding and Vary, then parks the cache headers next to all of it. Way more useful than one green-or-red dot when you’re elbow-deep in WordPress, a CDN, a reverse proxy, the web server itself.
Gzip, Brotli and the response that matters
Gzip is everywhere and it isn’t going anywhere. Brotli turns up a lot for modern text, mostly over HTTPS. Honestly though, I’d stop chasing the shinier name. What actually matters is whether the final text your visitors download lands small and gets cached right for each variant you serve. And keep this in mind: the server can hand Brotli to one client, Gzip to the next, a plain uncompressed body to some diagnostic tool that sent odd headers. The one response you happened to sample isn’t the whole story.
- Content-Encoding names the encoding applied to that one response I sampled. Nothing more.
- Vary is what tells caches to keep the Accept-Encoding variants apart so they don’t cross the streams.
- Content-Type is how you decide whether compression even belongs on this resource at all.
- Cache-Control covers a chunk of what happens on repeat visits, and at the CDN too.
- Redirect path is your proof you audited the real destination, not some stale URL.
When missing compression deserves action
So when would I actually chase this down? You’ve got a real HTML page, a stylesheet, a script, a JSON response or an XML feed big enough to feel, and no compression turns up anywhere on the path that matters. That one’s worth your time. Go poke at the origin and the edge. On WordPress it’s usually one of a small cast of suspects: a hosting default, an Nginx or Apache rule, a performance plugin, a CDN toggle, a proxy rule, a cache layer quietly handing back a different variant than the one you think you’re getting. What I would not do is start gzipping your JPEGs, WebP, MP4s or ZIPs just to flip a checker green. They’re already compressed. You’ll burn CPU for nothing.
And be honest about size while you’re at it. Compression shaves bytes off text, full stop. It won’t rescue a 4 MB hero image, a pile of scripts, render-blocking work, a cache you never bothered to set up, or a backend that needs a whole second to build the page. When a page still drags after Content-Encoding looks fine? That’s your cue to pull in the page size, status and response time checks and go hunt the real culprit.
How to read HEAD and GET differences
I love HEAD. It grabs the headers without dragging the whole body down. The catch, and it’s a real one, is that some apps and intermediaries just don’t answer HEAD the way they answer GET. That bites you mid-audit. You’ll watch HEAD report no compression while the browser’s GET is happily pulling Brotli. Or a redirect answers one way and the final HTML answers another. When the two disagree, don’t force a tidy verdict out of the mess. Trust the context. Then open your browser network tab, watch the real request your visitors make, and check the actual text resource you care about.
A practical compression workflow
- Test the canonical final URL. Not the old one that just bounces you somewhere else.
- Read Content-Type first, so you already know whether compression even belongs here.
- Line up Content-Encoding and Vary across whatever samples you actually managed to get.
- Look at the cache headers and CDN behavior before you go rewriting server rules blind.
- Retest after every change: a cache purge, a hosting tweak, a CDN flip, a plugin toggle.
Common questions
Is Brotli always better than Gzip?
Always? No. Brotli usually squeezes text harder, sure, but the encoding that actually wins is the one negotiated right and served every time without flaking. The one proven on your real path. Gzip still pulls its weight and runs everywhere, so don’t write it off.
Should every file be compressed?
Nope. Text is the target here. Your images, videos, archives and modern fonts already come compressed or packed some other way, so bolting Gzip on top mostly burns CPU to save a rounding error.
Does compression guarantee a fast page?
I wish. All it does is cut the transfer cost on the stuff worth compressing. Backend latency, caching, render work, your JavaScript, image weight, every third-party script, they all still get a vote. And they usually shout louder than compression ever will.
What is the difference between gzip and Brotli?
Both squeeze text. Brotli normally lands a smaller file for the same content, and every modern browser speaks it. Gzip is the universal fallback that never lets you down. So serve Brotli, keep gzip waiting behind it, and you’ve covered everyone.
Why is my compression not working?
Round up the usual suspects. The server module isn’t switched on. Your content type isn’t in the compressible list. The response is already binary. Or some proxy in the middle is quietly stripping the Accept-Encoding header before it ever reaches the origin.
Does compression help SEO?
Indirectly, yeah. Smaller transfers mean faster loads, and faster loads feed Core Web Vitals. Maybe it’s just me, but this feels like the lowest-effort win on the whole list, so flip it on for every text asset and move on.
