A page is identical for all users except a small personalised header. How do you cache it?

What is being tested

Whether you decompose by cacheability instead of accepting the page as one indivisible unit — and whether you know the severe failure mode lurking here.

The wrong answer, and why it is so common

Marking the whole page uncacheable because 5% of it varies. This converts a workload the CDN could absorb almost entirely into full origin load, and it is the single most expensive caching mistake in practice. A publisher who does this discovers it on the day a story goes viral.

The options, best first

1. Cache the page, fill the header client-side. Cache the full page publicly. The header renders with a placeholder, and a small JavaScript call fetches the personalised fragment after load. The page is one cacheable object, the origin serves a tiny endpoint, and the personalised part fails independently.

Cost: a brief layout shift, and users with scripting disabled see the placeholder. Both are usually acceptable and both are mitigable.

2. Edge-side assembly. The cached page contains a marker; the edge substitutes a small dynamic fragment before responding. Better first render than client-side, no layout shift, and it keeps the expensive part cacheable. Requires an edge platform that supports it.

3. Assemble at the edge from a signed token. If the header only needs the user's name and cart count, and those are already in a signed cookie or token, the edge can render it with no origin call at all. This is the strongest option when the personalised data is small and the client already carries it.

4. Two-tier caching. Cache the expensive shared components at the origin, assemble per user. Least effective — the origin still handles every request — but sometimes the only option for deeply personalised pages.

The failure mode to name explicitly

Caching a personalised response because the cache key omitted the user dimension. This serves one user's name, cart, or account data to another user. It is the highest-severity mistake available in this area and it happens regularly, usually because a Set-Cookie or a personalised variant slipped into a response that was marked publicly cacheable.

Defences: never mark a response public unless it has been verified to contain nothing user-specific; use Vary correctly; and treat cache-control headers as security-relevant configuration that receives review.

Related cache-key hygiene

• Strip tracking query parameters from the cache key, or every visitor arriving from a campaign gets a unique key and the hit rate collapses.
• Normalise the key — casing, trailing slashes, parameter order — so equivalent URLs share an entry.
• Vary on what actually matters (encoding, device class) and nothing else; each Vary dimension multiplies the number of stored variants.

The general shape

This is the same architecture that makes a news site survive an election night: the read path is cached artefacts served near the user, and the parts that resist caching — personalisation, paywall state, live counts, comments — are each handled separately, with an explicit decision about what to sacrifice when each one fails.