Reuse without staleness
HTTP caching stores responses so repeat visits avoid network downloads. The cache control header is the main lever.
- max age: how many seconds the response stays fresh.
- no cache: store it but revalidate before reuse.
- no store: never cache, for sensitive data.
- immutable: promise the content will never change, so skip revalidation.
- public or private: whether shared caches may store it.
The hashing pattern
The classic conflict is wanting long cache lifetimes yet still shipping updates. Content hashing solves it.
- Static assets get a hash in the filename, such as app a1b2c3 dot js.
- Those files set a long max age plus immutable, since a new build means a new name.
- The HTML that references them uses no cache so it always fetches the latest names.
This way unchanged assets stay cached for a year while a deploy invalidates only what changed. Revalidation uses etag or last modified so a fresh check returns a small not modified response when nothing changed.
Key idea
Cache hashed static assets aggressively with immutable, but serve the referencing HTML with no cache so updates ship instantly.