Web Caching Strategies 2026: An Engineering Reference

Web caching strategies in 2026 span five distinct layers — the browser, the CDN, the reverse proxy, the application cache, and the database query cache — and each one has a different invalidation model and a different way to fail. Treating caching as a single knob is the root cause of most stale-content bugs and most cascading outages. This reference maps all five layers in one place, from HTTP directives governed by RFC 9111 to Next.js 16’s explicit use cache lifetimes.

Most caching articles cover only one or two layers — usually HTTP headers or Redis, rarely both, and almost never the failure modes that connect them. That gap is why teams ship a clever Cache-Control policy and still get paged at 2 a.m. when a popular key expires and a thundering herd flattens the database. A mental model that maps where each piece of data should live, how it expires, and what breaks when it does is worth more than any single tuning trick.

Below: the canonical no-cache versus no-store misunderstanding, a decision matrix for every significant Cache-Control directive, why stale-while-revalidate is the most underused directive in HTTP, how CDN tag-based purging actually propagates, Redis eviction policies and cache-stampede mitigation, and how Next.js 16’s use cache plus cacheLife replace ISR-style fetching with composable lifetimes. It closes with a proprietary five-layer reference table you can keep next to your architecture diagram.

A request for a single resource can pass through — and be cached at — five independent layers before it ever reaches your business logic. Each layer caches for a different reason, expires on a different clock, and fails in a different way. Understanding the stack as a whole is what lets you answer the only question that matters when you’re deciding where to put a piece of data: which layer should own its freshness?

This is the single most common caching misunderstanding, and it is worth correcting before anything else. The directive no-cache does not prevent a response from being stored. It means the cache may store the response, but it must revalidate with the origin before reusing it — typically via a conditional request that returns 304 Not Modified when the content is unchanged. The directive that actually prevents storage entirely is no-store.

The practical consequence: if you want a resource to never be cached at all — a response with sensitive data, say — no-cache is the wrong choice. It permits storage and merely demands a revalidation round-trip. Reach for no-store instead. Conversely, if you want a resource that is always served fresh but still benefit from a 304 when nothing changed, no-cache is exactly right — and far more bandwidth- efficient than disabling caching outright.

One more directive deserves a mention here because engineers conflate it with both: must-revalidate tells a cache it may serve a stored response while it is still fresh, but once that response goes stale it must revalidate with the origin and may not serve the stale copy on its own initiative. That is a meaningfully different contract from no-cache, which revalidates on every use, fresh or not.

MDN documents these directives narratively. The matrix below is the compact decision form — for each significant directive, whether it applies to private caches, shared caches, or both; whether the response may be stored; what it is best for; and the specific mistake engineers most often make with it. RFC numbers are included so you can trace any cell back to the spec.

Two cells warrant emphasis. First, max-age measures elapsed time since the response was generated on the origin server — not since it was received by an intermediate cache. The Age header that intermediate caches add deducts that transit time, so a response with max-age=600 that spent 120 seconds reaching a CDN is already 2 minutes into its life on arrival. Second, immutable (RFC 8246) is only safe on URLs that carry a content hash, which is exactly why Next.js applies public, max-age=31536000, immutable to everything under /_next/static/ — the hash in the filename is the cache buster.

stale-while-revalidate (RFC 5861) is the most underused directive in the HTTP caching toolkit. It lets a cache serve a stale response for a defined window while it revalidates the resource in the background — so the user gets an instant response and never waits on the origin round-trip. The revalidated content is ready for the next request. A combined example: Cache-Control: max-age=2592000, stale-while-revalidate=86400 caches for 30 days with a one-day grace window during which stale content is served while a fresh copy is fetched.

Its sibling, stale-if-error (also RFC 5861), is your origin-outage safety net. It permits a cache to serve a stale response for a defined window when the origin returns a 5xx status — 500, 502, 503, or 504 — or is unreachable entirely. Stacked together, the three directives form a resilient policy: Cache-Control: max-age=3600, stale-while-revalidate=600, stale-if-error=86400 gives one hour of freshness, a ten-minute window to hide revalidation latency, and a full day of last-good fallback if the origin falls over.

A persistent myth is that stale-while-revalidate is a browser-only feature. It is not — it is specified for shared caches and is supported at the edge by Cloudflare, Amazon CloudFront, and Fastly. That makes it most valuable precisely where it is least used: at the CDN, where a single background revalidation can shield the origin from a traffic spike while every user still gets a sub-second response.

When a cached response goes stale, revalidation does not have to re-download the whole body. Validators let a cache ask the origin “has this changed?” and receive a tiny 304 Not Modified with no body when it hasn’t. There are two: ETag and Last-Modified.

Strong ETags guarantee byte-for-byte identity; weak ETags — prefixed W/ — guarantee only semantic equivalence. RFC 9110 recommends sending both an ETag and a Last-Modified header in responses, and during revalidation If-None-Match takes precedence over If-Modified-Since. A matching ETag returns 304 Not Modified with no response body, saving the bandwidth of re-sending an unchanged resource.

At the edge, the question shifts from “when does this expire?” to “how do I purge it the instant it changes?” The three major CDNs answer it differently, and the differences matter for both speed and cost. A well-architected web development stack layers caching across the browser, CDN, and application tiers — and wires purge into the same workflow that publishes the content.

Fastly leads on tag-based purging. Its Surrogate-Key mechanism lets you tag any response and purge every object carrying that tag in roughly 150ms globally. Individual keys are limited to 1,024 bytes and the full Surrogate-Key header may not exceed 16,384 bytes; purges run via dashboard, API, CLI, and a Rust edge SDK, and soft purges mark content stale rather than deleting it outright.

Cloudflare exposes a dedicated CDN-Cache-Control header that controls CDN behaviour without affecting upstream or downstream caches, accepting the same directives as Cache-Control. Its Origin Cache Control is enabled by default on Free, Pro, and Business plans, and the Cache Response Rules that shipped on March 24, 2026 let operators rewrite Cache-Control directives, manage cache tags, and strip headers like Set-Cookie from origin responses before they reach the cache — all without touching origin config.

Amazon CloudFront handles invalidation by path, with reported propagation in the 10-to-60-second range. It also supports stale-while-revalidate and stale-if-error directives at the edge.

The application cache is where most teams spend their tuning time, and two decisions dominate: which eviction policy runs when memory fills, and how you prevent a cache stampede when a hot key expires.

Eviction policies

Redis offers a full set of eviction policies — noeviction, the allkeys-* family (lru, lfu, random), and the volatile-* family that only evicts keys carrying a TTL. For a pure cache, allkeys-lru or allkeys-lfu are recommended; for a mixed workload where Redis also holds non-cache data, use volatile-lru with TTLs set on the cached keys only. LFU support arrived in Redis 4.0. Eviction only triggers once the instance reaches maxmemory — below that ceiling, keys live until their TTL.

Two tuning knobs are worth knowing. LRU is approximate: Redis samples a handful of keys rather than scanning them all, and the default maxmemory-samples 5 can be raised to 10 for a closer approximation of true LRU at a marginal CPU cost. For LFU, the defaults lfu-log-factor 10 and lfu-decay-time 1 (minutes) control how quickly the frequency counter saturates and how fast access counts decay.

Cache stampede (thundering herd)

When a popular cache key expires, many concurrent requests can simultaneously query the database to regenerate it — potentially causing a cascading failure. There are three primary mitigations, and they compose well:

One layer deeper sits the database query cache, where Redis can cut response times substantially for read-heavy workloads by keying results on a hash of the full query and its parameters. The catch is invalidation: any write to any table referenced in a cached query invalidates the entire cached result, which means query caching pays off most in read-heavy systems and least in write-heavy ones. This is the natural complement to reducing database query load through indexing — caching removes the query, indexing makes the unavoidable ones fast.

Next.js 16 (caching docs at version 16.2.9) replaces ISR-style data fetching with an explicit, composable model. The use cache directive caches the return value of an async function or component, and it is enabled by setting cacheComponents: true in next.config.ts. You can apply it at the data level — an individual fetching function — or at the UI level, on a full component or page. Arguments and closed-over values automatically become part of the cache key, so two calls with different inputs cache separately without any manual key management. This is the framework context for migrating to Next.js 16 Cache Components.

The companion cacheLife function controls how long a cached value lives, via three properties: stale (how long the client router cache may serve without checking the server), revalidate (how often the server refreshes in the background), and expire (the hard maximum age before the cache is treated as dynamic). Next.js ships seven built-in profiles — the table below maps each to its use case and its stale/revalidate/ expire triple.

Three sharp edges are worth internalising. First, the stale minimum is 30 seconds, enforced by Next.js — and stale controls the client-side router cache via the x-nextjs-stale-time response header, not Cache-Control directly. Second, calling revalidateTag(), revalidatePath(), updateTag(), or refresh() from a Server Action immediately clears the entire client cache, bypassing the stale time. Third — and most likely to trip you up — a cache with revalidate=0 or expire under 5 minutes is automatically excluded from prerenders and becomes a request-time “dynamic hole.” That includes the built-in seconds profile, and a short-lived cache nested inside a longer use cache without an explicit cacheLife will throw a prerender error.

This connects to Partial Prerendering, the default rendering mode when Cache Components is enabled. Static content and use cache content become the static HTML shell, while <Suspense>-wrapped dynamic content streams in at request time. Looking forward, the Next.js team is moving toward pathname-based CDN cache keying — where a full-page RSC response is served from /my/page.rsc and segment RSC from a .segment.rsc path — so CDNs need no Vary support and no custom header parsing. It is an announced design direction worth designing toward, not yet a finished default.

Here is the table to keep next to your architecture diagram. For each of the five layers it names the invalidation mechanism, the characteristic failure mode, the recommended directives or patterns, the Next.js integration point, and a typical TTL range. No single existing reference maps all five layers with their failure modes together — this is the one to bookmark.

Read the table as a routing guide. Push immutable, hashed assets to the browser and forget about them for a year. Put cacheable, shared-but-purgeable content at the CDN and wire surrogate-key purges into your publish workflow. Reserve the application cache for the expensive, per-tenant computations that benefit most from being memoised — and protect those keys against stampede. Use the database query cache sparingly, and only where reads dominate writes, because its invalidation overhead grows with write volume. Each layer is a tool; the architecture is choosing which one owns each value. The same care that goes into rate-limiting strategies for your API layer and into idempotency in distributed systems applies here: the perimeter behaviour is only as reliable as the invalidation discipline behind it.