How HTTP caching works
HTTP caching lets browsers and proxies reuse responses instead of refetching them. The right headers decide freshness and revalidation.
- Cache Control sets max age and whether a response is public or private.
- ETag is a validator the client sends back to ask if content changed.
- A fresh response is served from cache with no network round trip.
The revalidation flow
When a cached copy goes stale, the client revalidates with its ETag and may get a not modified reply.
Strategy choices
- Cache immutable fingerprinted assets for a year.
- Use short max age plus revalidation for content that changes.
- Mark per user responses private so shared caches do not store them.
Practical notes
- A not modified reply saves bandwidth by skipping the body.
- Vary on headers like Accept Encoding so caches stay correct.
- Bust caches by changing the asset URL, not by purging everything.
Key idea
Combine long lived caching for immutable assets with ETag revalidation for changing content, so caches serve most requests without hitting origin.