Web hosting
Website cache headers: control browser and shared-cache behaviour safely
HTTP cache headers tell browsers and shared caches how long a response can be reused and under what conditions. The right policy is different for fingerprinted static assets, HTML, APIs, authenticated pages, and content that changes without a URL change.
Classify response types before setting TTLs
Hashed CSS/JS/images can often use long immutable caching because a content change creates a new URL. HTML with the same URL may need shorter freshness or revalidation so updates appear promptly.
Authenticated/personalized responses should avoid accidental shared caching.
Understand Cache-Control directives
max-age controls client/shared freshness unless more specific directives apply; s-maxage can target shared caches; no-store forbids storage; no-cache allows storage but requires revalidation; immutable tells clients a fresh response will not change.
Choose directives from the response semantics and cache requirements.
Use validators for revalidation
ETag and Last-Modified can let clients ask whether a stale resource changed and receive 304 without downloading the full body. Ensure validators represent the actual representation served through compression/proxy layers.
Do not use weak/strong ETag semantics without understanding how your server generates them.
Test update behavior, not only headers
Publish a controlled change and verify browsers/CDNs receive it within the intended window. Purge shared caches deliberately when emergency changes must appear faster than normal TTL.
- Classify static/HTML/private responses.
- Set Cache-Control by semantics.
- Use validators where appropriate.
- Test real change propagation.