How does HTTP caching work with immutable assets and a CDN?

Question

IT Interview Practice · Accepted Answer

HTTP caching lets browsers and CDNs reuse a response instead of re-fetching it, controlled by the **`Cache-Control`** header. The winning pattern for web apps: **hash your asset filenames and cache them forever; keep HTML uncacheable.**

## The two-tier strategy

```http
# Hashed, versioned assets — content never changes for a given URL
Cache-Control: public, max-age=31536000, immutable
# e.g.  /static/app.9f2c1a.js   (the hash changes when content changes)

# HTML — must always be fresh so it can point at new asset hashes
Cache-Control: no-cache
```

- **`immutable`** tells the browser never to revalidate — no conditional request at all, even on reload. Safe because the filename hash *is* the version; new content = new URL.
- **`no-cache`** on HTML is misleadingly named: it means "store it, but revalidate before using" (a 304 if unchanged), so users always get HTML that references the current asset hashes.

## Revalidation and the CDN

- **`ETag`** / `Last-Modified` enable cheap `304 Not Modified` responses when `max-age` expires.
- A **CDN** caches at edge nodes near users. Use `s-maxage` for the shared CDN cache and `stale-while-revalidate` to serve stale content instantly while refreshing in the background:

```http
Cache-Control: public, s-maxage=600, stale-while-revalidate=86400
```

## Pitfalls

- Caching HTML with a long `max-age` → users stuck on old versions with no way to bust it.
- `immutable` on non-hashed URLs → you can't ship a fix.

## Why it matters

Caching is the cheapest performance win — it turns repeat visits into zero network cost and offloads the origin. The hashed-immutable-asset + revalidated-HTML pattern is the industry standard; explaining *why* `no-cache` ≠ "don't cache" signals real depth.

The two-tier strategy

Revalidation and the CDN

Pitfalls

Why it matters

Related questions