Cache header.
A cache header is the server response header that tells the browser how long a resource may be stored and how it is to be revalidated.
The basic tension fits in one sentence: a long cache is fast but updates do not propagate; a short cache is current but slow. Most teams pick a value in the middle and take both disadvantages at once.
The solution that removes the tension is a content stamp: the resource’s address carries a stamp derived from its content. When the content changes the address changes too, so the cache lifetime can be set as long as a year.
That the stamp derives from the content is critical. If a random version number or the build time is used, the address changes on every deployment even though the content did not, and the cache is wasted.
- Stamped styles and scripts — very long lifetime, marked immutable.
- HTML pages — short or revalidated; the address has to be permanent and cannot be stamped.
- Fonts — very long; they rarely change.
- Sitemap and robots — short; they may be updated often.
The immutable marker brings an additional gain: it tells the browser there is no need even to revalidate the resource. Without the marker a revalidation request may go out when the page is reloaded; with it, that request is never made.
This marker should only be given to stamped resources. Calling a resource with a fixed address immutable prevents updates from propagating entirely.
Misconfiguration has two classic forms. The first is providing no cache at all: every resource downloads again on every visit and the advantage of a repeat visit is lost completely. The second is giving a long cache to an unstamped resource: the update does not propagate and the user goes on seeing the old version.
The second is especially insidious, because it only shows for users who have visited the site before. The developer tests in a private window, everything looks right, and real users see a broken page.
Having the policy defined in a single place matters too: definitions scattered across layers drift apart over time and it becomes unclear which one wins.
To verify that the policy works, open a page twice in the browser’s network panel: on the second open the stamped resources should not be requested at all. If a request appears, either the stamp is missing or the header is written wrongly.
One final note on scope: the policy has to be defined not only for static resources but for the pages themselves. On a page with no header the browser applies its own heuristics and the result becomes unpredictable — cached in some browsers, not in others.