How HTTP Caching Works: Cache-Control, ETags and CDNs Explained

Where responses get cached

The rules live in the IETF's HTTP Caching standard, RFC 9111, which replaced the older RFC 7234 in 2022. It describes two broad kinds of cache:

• Private caches belong to one user, almost always the browser. They can safely hold personalized pages such as a dashboard or an account screen.
• Shared caches sit between users and the server and serve many people from one stored copy. MDN splits these into proxy caches you do not control and managed caches you deploy on purpose, such as a reverse proxy or a CDN, which you can usually purge from a dashboard or API.

Caching happens after the earlier steps of a request: your device has already looked up the site's address in DNS and, for most sites, set up an encrypted connection. A cache hit skips the network trip entirely, so it saves the most time of all.

Freshness: is the stored copy still good?

A cached response is either fresh, meaning the cache may reuse it without asking anyone, or stale, meaning it should check first. Freshness is a simple comparison: if the response's freshness lifetime is greater than its current age, it is fresh.

RFC 9111 says a cache works out the freshness lifetime from the first rule that applies:

1. For a shared cache, the s-maxage value in Cache-Control.
2. The max-age value.
3. The Expires date minus the response's Date.
4. Otherwise, a heuristic guess.

Age comes from how long the copy has been stored, plus whatever a shared cache reports in the Age header. MDN's example: a response with max-age=604800 (one week) that arrives with Age: 86400 has six days of freshness left.

The Cache-Control directives that matter

Most of the behavior you will ever need comes from a small set of directives. The names are famously misleading, so this table is worth bookmarking.

The classic mix-up is no-cache versus no-store. no-cache still allows storage; it just forces a check with the server every time. MDN advises against handing out no-store liberally, because it switches off useful features such as the browser's back/forward cache. For personalized content, no-cache, private is usually the better fit.

Revalidation: ETags and the 304 shortcut

When a copy goes stale, the cache does not have to download the whole thing again. It sends a conditional request carrying a validator it saved from the original response:

• ETag / If-None-Match: the server labels each version with an opaque tag, and the cache asks, "give me the file unless it still has this tag."
• Last-Modified / If-Modified-Since: the same idea using a timestamp.

If nothing changed, the server answers 304 Not Modified with no body, and the cache marks its stored copy fresh again. If the content changed, it gets a normal 200 OK with the new version. When both validators are sent, If-None-Match wins, and web.dev prefers ETags because timestamps are less precise.

# See a site's caching headers
curl -sI https://example.com/ | grep -iE 'cache-control|etag|last-modified|age|vary'

# Replay a revalidation by hand (swap in the real ETag)
curl -sI https://example.com/ -H 'If-None-Match: "33a64df5"'
# HTTP/2 304  means: your copy is still good

This is the same trade-off engineers make with database indexes: a little extra bookkeeping up front buys much cheaper lookups later.

Recipes that work for most sites

Fingerprinted assets: cache for a year

Build tools can put a content hash in each filename, like app.3f9a1c.js. When the file changes, its URL changes, so browsers fetch the new one immediately and old copies simply stop being requested. That makes a very long lifetime safe:

Cache-Control: max-age=31536000, immutable

HTML and fixed URLs: always check

You cannot rename /index.html, favicon.ico or an API endpoint on every deploy, so let caches keep them but check before reuse. With an ETag in place, most of those checks end in a quick 304:

Cache-Control: no-cache
ETag: "v42-a7c9"

Let the CDN soften the edges

For pages that can lag by a few seconds, RFC 5861 adds stale-while-revalidate, which lets a cache answer instantly with the old copy while it fetches a new one in the background, and stale-if-error, which lets it serve a stale copy when the origin returns a 500, 502, 503 or 504. Some CDNs also honor a separate CDN-Cache-Control header, so you can give the edge a different policy from browsers. Cloudflare documents that when this header is present, it drives Cloudflare's caching while ordinary Cache-Control passes through untouched.

Cache-Control: max-age=60, stale-while-revalidate=30, stale-if-error=86400

Common HTTP caching mistakes

• Long max-age on unversioned files. Visitors may keep an old style.css for days after you ship a fix.
• Caching personal pages in shared caches. Mark anything tied to a logged-in user as private; MDN notes a cookie alone does not make a response private.
• Varying on too much. Vary adds request headers to the cache key. Vary: Accept-Language is reasonable, but Vary: User-Agent creates so many variants that hit rates collapse.
• Skipping validators. Without an ETag or Last-Modified, a stale copy has to be downloaded in full instead of confirmed with a 304.
• Forgetting the cost side. Every cache miss is bandwidth and compute you pay for. Good cache headers are one of the cheapest ways to cut hosting and CDN bills.

Frequently asked questions