What Is Caching?

How Caching Works

Every time a browser fetches a resource, it can store the response and reuse it for later requests instead of asking the server again. MDN summarizes the payoff plainly: caching reduces latency because a stored response lives closer to the client than the origin, and it reduces server load because the origin does not have to process, route, and render the request a second time. The mechanism that controls all of this is the Cache-Control HTTP response header.

The most important directive is max-age, which sets how many seconds a response stays fresh. A response served with Cache-Control: max-age=604800 is reusable for a week without contacting the server. Once that window passes the response becomes stale and must be revalidated before reuse. Two other directives set the outer bounds: no-cache allows storing the response but forces revalidation on every use, and no-store forbids storing it at all, which is the right choice for genuinely sensitive data.

Caches also come in two flavors. A private cache lives in a single browser and may store personalized responses; you signal this with Cache-Control: private. A shared cache — a proxy, a reverse proxy, or a CDN — sits between the server and many users, so it must never store a response meant for one person. Marking authenticated responses private is what keeps one user’s data from leaking into another’s cache hit.

Revalidation and 304 Responses

When a fresh response expires, the browser does not blindly re-download it. Instead it sends a conditional request using a validator the server provided. If the response carried an ETag (a content fingerprint), the browser sends If-None-Match: "<etag>"; if it carried a Last-Modified date, it sends If-Modified-Since. When nothing has changed, the server replies 304 Not Modified with no response body, and the browser reuses its stored copy. That saves the bytes of the resource while still confirming it is current. MDN recommends servers emit both an ETag and a Last-Modified header on cacheable responses.

Example of Caching

The clearest documented pattern is the split between versioned assets and HTML. For a fingerprinted subresource like bundle.v123.js, MDN prescribes Cache-Control: public, max-age=31536000, immutable. The max-age=31536000 value is exactly one year in seconds, and immutable tells the browser not to bother revalidating even on a manual reload, because the content behind that URL will never change — if the bundle changes, its filename hash changes with it.

The HTML that references those assets gets the opposite treatment. Because a main document’s URL cannot carry a version hash, MDN recommends Cache-Control: no-cache on HTML, so the browser always revalidates and picks up new markup immediately after a deploy, while still saving the download via a 304 when nothing changed. For a page personalized after login, that becomes Cache-Control: no-cache, private so the response revalidates and is never stored in a shared cache. This pairing — immutable year-long caching for hashed assets, always-revalidate for HTML — is the backbone of fast, safe web caching, and it is why a returning visitor can load a complex app with almost no new network traffic.

The search relevance is direct. Faster repeat loads and a lighter origin both feed into Time to First Byte and the loading Core Web Vitals Google scores, and a well-cached site also spends less of a crawler’s crawl budget re-fetching unchanged assets. Getting the headers right is one of the highest-leverage, lowest-risk technical wins available, because it costs nothing per request and compounds across every returning visitor and every crawl.

Frequently Asked Questions

The Bottom Line

Caching trades a fresh download for a stored copy, and the whole art is telling each cache how long that trade is safe. Freshness directives, revalidation tokens, and the split between private and shared caches are the levers. Set them per resource — long and immutable for versioned assets, revalidate-always for HTML — and repeat visits get faster without ever serving stale data.