HTTP Caching

HTTP caching is a set of rules built into the HTTP protocol that decide whether a stored copy of a response can be reused instead of asking the server again. The server attaches headers to a response that say how long the copy stays fresh and how to check if it has changed. Any cache along the path can honor those headers: the browser's own disk cache, a corporate forward proxy, or a CDN edge node sitting in front of the origin.

There are two layers to it. A private cache lives in one user's browser and holds responses specific to that user. A shared cache, like a CDN or proxy, serves many users from one stored copy. Static assets such as images, CSS, JavaScript bundles, and fonts are the prime candidates because they change rarely and look identical for everyone.

The whole point is to avoid work. If the answer is the same as last time, sending it over the network again wastes bandwidth, adds latency, and loads the origin for nothing.

The server controls caching mainly through the Cache-Control header. A value like Cache-Control: max-age=31536000 tells a cache the response is fresh for one year, so it can be served straight from local storage with no network call at all. Adding public lets shared caches store it; private restricts it to the browser; no-store forbids storing it entirely.

When a cached copy expires, the cache does not just throw it away. It revalidates. The server sends an ETag, a short fingerprint of the content like a hash, and a Last-Modified timestamp. On the next request the browser sends back If-None-Match with that ETag or If-Modified-Since with the timestamp. If nothing changed, the server replies 304 Not Modified with an empty body, and the browser reuses its stored copy. A 304 round trip still costs a request but transfers almost no data, which is much cheaper than re-downloading a 300 KB bundle.

The common production pattern is content hashing in filenames, such as app.4f3a9b.js. The file is served with a one-year max-age and treated as immutable. When the code changes, the build tool generates a new hash, so the HTML points at a brand new URL and the browser fetches the new file while keeping the old one cached harmlessly.

Cache aggressively for anything versioned or immutable: hashed JS and CSS, images, fonts, and downloadable files. These can use max-age of a year because the URL changes whenever the content does. For HTML and API responses that change often, use short max-age or no-cache, which forces revalidation on every request but still saves bandwidth via 304 responses.

The hardest problem is invalidation. Once you tell a browser to cache something for a year, you cannot reach into that browser and delete it. If you cache an HTML page or an unversioned file too long, users keep seeing stale content until the timer expires. The fix is to never long-cache a stable URL whose content can change; change the URL instead, or keep its max-age low.

Watch out for caching private data in shared caches. A response with Cache-Control: public that contains one user's account details could be served to another user by a CDN. Mark anything user-specific as private or no-store, and use the Vary header when a response depends on a request header like Accept-Encoding or Authorization.

Open the network tab on a large site like GitHub or Amazon and reload a page you visited a minute ago. Most of the static assets show as served from disk cache or memory cache with no network time at all, because they carry Cache-Control: public, max-age=31536000, immutable and hashed filenames.

Cloudflare and other CDNs operate as a giant shared HTTP cache. When the first visitor in a region requests an image, the edge node fetches it from the origin once, stores it according to the Cache-Control headers, and serves every later visitor in that region from the edge in single-digit milliseconds. The origin server might see one request per hour for a file that gets a million views.

The payoff is large. A typical web page is mostly static bytes. Effective HTTP caching turns a returning visit from dozens of full downloads into a handful of 304 checks plus a fresh HTML fetch, cutting page load time and origin traffic by a big margin with nothing more than the right headers.