HTTP compression and delivery signal audit
Check Gzip or Brotli signals on a public URL, compare first-response HEAD headers with available GET page headers, inspect redirects and cache context, and learn when missing compression is a real problem rather than a misleading reading on media or a redirect.
Compression is negotiated per response. The first header sample uses the exact URL before redirect assumptions; the GET page sample is available when the backend can parse the destination as an HTML document.
What a compression checker should prove
Compression is one of the quiet web performance wins. A text response such as HTML, CSS, JavaScript, JSON, XML or SVG often transfers far more efficiently when the server or CDN negotiates Gzip or Brotli with the client. A compression checker should make that negotiation visible without pretending every missing Content-Encoding header means the site is broken. A redirect can hide the final page. A HEAD response can differ from a browser GET response. An image, video, archive or font may already be packed in a format where another compression layer adds little value.
This tool therefore keeps context in the report. It reads the exact first response, checks available GET page headers when the backend can parse an HTML document, inspects redirect rows, surfaces Content-Encoding and Vary, and keeps cache headers nearby. That gives you a better answer than a single green or red badge when you are tuning WordPress, a CDN, reverse proxy or web server.
Gzip, Brotli and the response that matters
Gzip remains widely supported and Brotli is common for modern text delivery, especially over HTTPS. The useful question is not which label sounds newer. It is whether the final text response your visitors download is transferred efficiently and cached correctly for the compression variants you serve. A server may send Brotli for one client, Gzip for another and an uncompressed response for a diagnostic request with different headers.
- Content-Encoding describes the encoding applied to that sampled HTTP response.
- Vary can show that caches should keep Accept-Encoding variants separate.
- Content-Type helps decide whether compression is expected for this resource.
- Cache-Control explains part of repeat-visit and CDN behavior.
- Redirect path tells you whether you audited the old URL or the final destination.
When missing compression deserves action
If a final HTML page, stylesheet, script, JSON response or XML feed is large enough to matter and no compression signal appears across the relevant response path, review the origin and edge configuration. On WordPress that can involve hosting defaults, Nginx or Apache rules, a performance plugin, a CDN setting, a proxy rule or a cache layer that serves different variants than expected. Do not start by compressing JPEG, WebP, MP4, ZIP or other already-compressed media just to make a checker happier.
Also keep response size in perspective. Compression reduces transfer bytes for text, but it does not remove heavy images, excessive scripts, render-blocking work, poor caching or slow backend generation. Pair this check with page size, status and response time checks when a page still feels slow after Content-Encoding looks healthy.
How to read HEAD and GET differences
HEAD is useful because it asks for headers without downloading the body, but some applications and intermediaries do not answer it exactly like GET. This matters during audits. A HEAD response can show no compression while the browser GET response does, or a redirect can answer one way before the final HTML page answers another. If the two samples disagree, trust the context rather than forcing a simple verdict: open browser network tools for the real client path and check the final text resource you care about.
A practical compression workflow
- Check the canonical final page URL, not only an old redirecting URL.
- Read Content-Type first so you know whether compression should be expected.
- Compare Content-Encoding and Vary on the available response samples.
- Review cache headers and CDN behavior before changing server rules blindly.
- Retest after cache purge, hosting changes, CDN changes and performance plugin changes.
Common questions
Is Brotli always better than Gzip?
Brotli often compresses text very well, but the best answer is the one correctly negotiated, served reliably and measured on your real delivery path. Gzip is still useful and broadly supported.
Should every file be compressed?
No. Text responses are the main target. Many images, videos, archives and modern font formats are already compressed or optimized in other ways.
Does compression guarantee a fast page?
No. It reduces transfer cost for suitable resources. Backend latency, caching, render work, JavaScript, image weight and third-party code still matter.
What is the difference between gzip and Brotli?
Both compress text responses. Brotli usually achieves a smaller size for the same content and is supported by all modern browsers; gzip is the universal fallback. Serve Brotli with a gzip fallback.
Why is my compression not working?
Common causes: the server module is not enabled, the content type is not in the compressible list, the response is already binary, or a proxy strips the Accept-Encoding header.
Does compression help SEO?
Indirectly, by reducing transfer size and improving load time, which feeds Core Web Vitals. It is low-effort and worth enabling for all text assets.
