Web caching is a stack — each layer catches what the layer above misses, and together they cut origin load by 90%+ for typical sites.

The layers (closest to user → furthest)

1. Browser HTTP cache

Built into every browser. Driven by response headers:

Cache-Control: public, max-age=31536000, immutable
ETag: "abc123"
Last-Modified: Wed, 17 May 2026 12:00:00 GMT

• max-age — how long the response is fresh (no revalidation).
• immutable — promise that the resource won't change before max-age expires; browser skips even revalidation on user reload.
• ETag / Last-Modified — opaque/timestamp markers for conditional revalidation. Browser sends If-None-Match / If-Modified-Since; server returns 304 (empty body) if unchanged.
• s-maxage — like max-age but only for shared caches (CDNs).
• stale-while-revalidate=N — serve stale up to N seconds while fetching fresh in background.
• no-cache — cache but always revalidate.
• no-store — never cache (auth-only, personalized).
• private — only the browser, not shared caches.

Standard pattern:

• Hashed assets (main.abc123.js, logo.def456.png): Cache-Control: public, max-age=31536000, immutable. Cached forever.
• HTML: Cache-Control: public, max-age=0, must-revalidate or short max-age + ETag. Always fresh on next nav.

2. CDN / edge cache

CloudFront, Cloudflare, Fastly, Vercel Edge. Shared across all users; cache HTML and assets close to user.

• Same headers (Cache-Control: s-maxage=…).
• Vary on Accept-Encoding, Accept-Language if responses differ.
• Cache key normally URL; can extend with query whitelist, cookies.
• Purge by URL or tag (Cloudflare cache tags, Fastly surrogate keys).

3. Service Worker (custom strategies)

When the browser cache isn't expressive enough:

• Cache-first for static assets.
• Network-first with cache fallback for HTML (offline support).
• Stale-while-revalidate for content that's fine being slightly old.
• Network-only for auth, mutations.
• Pre-cache at install for the app shell.

Workbox makes this manageable.

4. In-memory app cache (React Query / RTKQ / SWR / Redux)

• Caches API responses by query key.
• Deduplicates concurrent requests.
• TTL and tag-based invalidation.
• Survives component unmount but not page reload.

This is where most "API caching" lives in modern apps.

5. localStorage / sessionStorage / IndexedDB

For client-side persistent state:

• localStorage — 5–10MB, sync API, sticky across sessions.
• sessionStorage — same but per-tab.
• IndexedDB — gigabytes, async, structured queries. Right for big offline datasets, Dexie or idb wrapper for sanity.
• Cache API (within SW context) — Request/Response pairs, perfect for SW caching.

Watch out: never store PII or auth tokens in localStorage (XSS-readable). HttpOnly cookies for tokens.

Cache keys — the hard part

If two users get different responses for the same URL, the cache must distinguish:

• Auth: Authorization: Bearer … responses are per-user; Cache-Control: private (browser only) or no-store. Don't put behind shared caches.
• Locale: Vary: Accept-Language so the cache stores one per language.
• Cookies: by default CDN caches strip cookies and ignore them; if your response varies by cookie, configure the cache key explicitly.
• Device: mobile vs desktop variants — Vary: User-Agent is too broad (every UA string becomes a cache entry); use Client Hints or render mobile-first responsive.

Wrong cache key = users seeing each other's data. The most embarrassing cache bug.

Strategy matrix

Common pitfalls

• Long-cached HTML referencing a chunk that got rebuilt with a new hash → 404 on next deploy.
• no-cache confused with no-store (no-cache does cache, just revalidates).
• Mixing Cache-Control and Expires — Cache-Control wins; remove Expires to avoid confusion.
• Forgetting Vary when serving compressed (gzip/brotli) responses (most CDNs handle this; double-check).
• Setting long cache on /api/me → user sees previous user's data.
• Service worker caching old shell + serving new chunks → fatal version mismatch.

Invalidation

The two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.

• Versioned URLs (hashes): never invalidate; serve forever, change the URL on update. Use for assets.
• Soft purge / revalidate: CDN tag-purge an entire content type (e.g., all product pages after a price change).
• TTL: accept some staleness; pick TTL to match how often the content changes.
• stale-while-revalidate: serve stale instantly, fetch fresh in background — best of both for non-personal content.

Mental model

Cache aggressively at the layer closest to the user. Use immutable URLs to make cache invalidation a non-problem. Personalize at the closest layer to the user too (browser, edge with auth-aware Workers) so the rest of the stack can cache shared content.