HTTP Headers — Why the Browser Is Caching Your Old Build
This fetches a URL and shows every response header, the status code, and any redirects along the way. Headers decide how long a browser keeps a file, whether it compresses, how it interprets the bytes, and what it is allowed to do with the response — and almost none of that is visible from the page itself.
When it helps
The most common reason is a deploy that appears not to have taken effect. If a stylesheet has a long cache lifetime and no fingerprint in its filename, returning visitors keep the old one for as long as the header says, and your hard refresh proves nothing because it bypasses the cache you are trying to diagnose. Content type is the other frequent culprit: a font or a module served with the wrong type is refused by the browser while the request itself succeeds, which produces a console error that names the wrong problem.
Worth running automatically
Caching headers are set in several places — framework, web server, CDN — and any of them can change independently of your code. The expensive direction is silent: a build asset that starts being served with no cache lifetime is downloaded on every page view by every visitor, which shows up as a slower site and a larger bill rather than as an error. Checking headers on a schedule catches the change on the day, rather than during the next investigation into why the site feels sluggish.
What you get out of it
Explains the class of bug where your code is correct and the browser is showing something else. Monitored, it catches caching regressions whose only symptom is a gradually worse experience.