KNOWLEDGE ARTICLE

What Is HTTP Caching?

Cache-Control, ETag, Last-Modified

Uses response headers to control reuse by browsers and intermediaries.

At a glance

Cache-Control sets storage scope and lifetime; ETag and Last-Modified support revalidation. Good policies reduce repeated transfers, while dynamic and private content need careful boundaries.

Reducing repeated response transfers

HTTP caches let browsers, shared proxies and CDNs reuse earlier responses. Cache-Control directives such as max-age, s-maxage, public, private, no-cache and no-store define freshness and storage scope. Expires is an older absolute-time mechanism. Suitable caching reduces latency, bandwidth and origin load.

No-cache does not mean no storage: it requires validation before reuse. No-store instructs caches not to store the response. Private limits shared-cache reuse for personalized content; public can explicitly allow sharing, but sensitive differences still need protection.

Freshness and conditional requests

  • A response within max-age can be reused directly. After expiry, If-None-Match or If-Modified-Since can ask the server to validate it.
  • ETag identifies a response version; Last-Modified provides a modification time. An unchanged response can produce 304 without retransmitting the full body.
  • Vary identifies request headers that alter the response, such as Accept-Encoding or language. Missing dimensions can mix content; excessive variation reduces hit rates.
  • Stale-while-revalidate and stale-if-error can temporarily serve older content during refresh or origin errors, improving continuity when the business accepts the stale window.
A cached HTTP response moves through storage, fresh reuse, conditional validation and 304 renewal
The lifecycle of a cached responseConnect initial fetch, fresh reuse, revalidation, 304 and replacement

Protecting personalized pages

If the cache key omits a content-changing cookie, Authorization header, region or experiment parameter, a shared cache may serve one user's response to another. Login, cart and account pages need explicit private or no-store policies, with CDN rules checked for overrides.

Static files commonly use content-hashed filenames and long lifetimes, while HTML uses shorter caching or revalidation to reference new assets promptly. Publish assets before updating HTML and avoid deleting files still referenced by cached pages.

Practical use and interpretation

Headers state the intended browser and shared-cache policy. Age, Via and provider fields may indicate a cache hit. Actual performance depends on hit rates, object size and network measurements, not just max-age.

Without explicit Cache-Control, clients may use heuristic caching. This is not necessarily an absence of caching. Sensitive-response safety also requires checking CDN behavior and responses under different authentication states.

Points to consider

A cache header alone does not establish performance. Resource type, CDN hits, compression and measured loading behavior also matter.

Frequently asked questions

Are no-cache and no-store the same?

No. No-cache permits storage but requires validation before reuse. No-store says not to store the response.

Does longer caching always make a site faster?

Versioned static resources often benefit. Dynamic or user-specific content may become stale or leak between users, so choose policy by resource type.

Why do visitors still see old content after an update?

Browser, CDN, service-worker or intermediary caches may still be valid, or a purge may not have covered the active cache key.

References