Topic
Browser caching
Browser caching lets previously retrieved resources be reused when HTTP freshness and validation rules say that reuse is appropriate.
At a glance
- Primary control header
- Cache-Control
- Validation examples
- ETag and Last-Modified
Overview
Web caches reduce repeated transfers by storing responses and reusing them under HTTP caching rules. A response can declare how long it remains fresh, whether it may be stored, and whether a stale copy can be validated with the origin server. Correct caching can improve speed and reduce bandwidth while incorrect caching rules can expose stale or private information.
Freshness and validation
A fresh cached response can often be reused without contacting the origin. When it becomes stale, validators such as an ETag or Last-Modified value can allow a conditional request so the server can confirm that the stored representation is still current instead of retransmitting the whole resource.
Caching needs a privacy model
Shared caches and private browser caches have different risk boundaries. Responses containing user-specific or sensitive data need deliberate cache directives, and developers should not assume that a URL change or browser refresh alone provides the intended privacy or freshness behavior.
Sources and review
MOOR's explanatory text is supported by the following source links.
- HTTP caching — MDN Web Docs
- HTTP Caching — RFC Editor