What This Tool Checks (and What It Doesn't)
This tool focuses on the response headers that control caching, compression, and general HTTP behavior: Cache-Control, ETag, Last-Modified, Content-Encoding, Vary, and server/CDN fingerprinting. It's built as a browser-based way to check server headers without installing anything: no extension, no `curl -I` in a terminal, just a URL and a real live connection. It deliberately does not duplicate security-header analysis (HSTS, CSP, X-Frame-Options, cookie flags); that lives in a dedicated Security Headers Checker, since mixing the two would make either tool's verdict harder to act on. Like following any URL, it also doesn't require an HTML content-type: an image, a JSON API response, or a download link all send real headers worth checking.
Cache-Control, Explained
Cache-Control is the single header that decides whether a browser or CDN can reuse a response instead of asking the origin server again. `no-store` disables caching entirely; `private` allows only the browser to cache it; `public` with a `max-age` lets shared caches (CDNs, proxies) store it too, for the number of seconds given; `no-cache` (a confusing name) still allows caching, but forces a revalidation check with the origin before reuse. Missing this header entirely is one of the most common, easiest-to-fix performance mistakes: every single request ends up hitting the origin fresh.
How to Tell If Compression Is Actually Working
A server can support gzip or Brotli and still fail to use it for a specific response: a misconfigured proxy, a missing MIME-type rule, or a CDN caching an uncompressed copy are all common causes. The only reliable way to know is to look at the actual `Content-Encoding` header on a real response, which is exactly what this tool does, not a guess based on the server's advertised capabilities, but what it genuinely sent back this time.