HTTP caching is the mechanism by which web browsers, intermediary servers, and other clients store copies of HTTP responses so that future requests for the same resource can be served without contacting the origin server again. By reducing the number of round trips required to fetch assets, HTTP caching is one of the most direct levers available for improving web performance and lowering server load.
When a server sends a response, it can include special HTTP headers that instruct any cache in the chain on how to handle that response. The most important of these is Cache-Control, which replaced the older Expires header and offers more precise directives. A value such as Cache-Control: max-age=86400 tells the browser it may reuse the cached response for up to 86,400 seconds (one day) before treating it as stale. Directives like no-cache, no-store, and public or private give developers fine-grained control over what gets cached, where, and for how long.
Alongside Cache-Control, the ETag header (short for entity tag) enables a process known as conditional validation. The server assigns a unique token to a specific version of a resource. When the cached copy becomes stale, the browser sends that token back to the server in an If-None-Match request header. If the resource has not changed, the server responds with a lightweight 304 Not Modified status, confirming the cached copy is still valid without resending the full response body. A similar mechanism works through the Last-Modified and If-Modified-Since headers.
HTTP caches exist at several layers. The browser cache is private to a single user and stores assets locally on their device. Shared caches, such as those operated by a CDN or a reverse proxy, sit between many users and the origin server, meaning a single cached response can be reused across thousands of requests. This distinction matters when setting the public versus private directive in Cache-Control, since a private response should never be stored by a shared cache.
From a web performance perspective, effective HTTP caching has a direct relationship with metrics tracked by Core Web Vitals. Serving assets from cache eliminates network latency entirely for repeat visits, which can significantly improve loading performance scores such as Largest Contentful Paint. For this reason, setting appropriate cache lifetimes for static assets like images, fonts, and scripts is considered a foundational performance optimization.
A common strategy is cache busting, where a version identifier or content hash is embedded in a file's URL (for example, app.a3f9c1.js). This allows the asset to be cached indefinitely with max-age set to a very large value, while ensuring that any update to the file is immediately accessible under a new URL, bypassing the old cached copy.