Fast Pages, Wrong Consent

Page caching is one of the best things you can do for speed and hosting costs. It is also one of the easiest ways to break a consent setup without noticing. A cache does exactly what it is told: it stores a response once and serves it to everyone who matches the same key. If that stored response contains anything specific to one visitor’s consent choice or location, the next visitor receives it too.

This guide covers the caching layers that typically sit in front of a publisher site — CDN edge caches, full-page caching plugins, reverse proxies, service workers and the browser itself — and how to keep each one from serving the wrong consent experience.

The Core Rule: Keep Consent Out of Cached HTML

The safest architecture renders the cached HTML page as consent-neutral. The page contains the CMP loader and your tags in a blocked or waiting state, but no decision about this particular visitor. The CMP then runs in the browser, reads the stored choice, decides whether to show the banner, and releases tags accordingly.

Problems start when the server makes consent decisions at render time, for example:

• a theme or plugin that only prints ad or analytics tags when a consent cookie is present;
• server-side code that omits the banner markup for visitors who already chose;
• templates that embed a visitor’s consent state in an inline script variable.

Once that page is cached, the first visitor’s state becomes everyone’s state. A visitor who rejected tracking may receive a page with tags already active, or a new visitor may never see a banner because the cached copy came from someone who had already dismissed it.

Why “Vary: Cookie” Is Rarely the Answer

The textbook fix for per-visitor content is to tell caches to vary on the cookie header. In practice, visitors carry many cookies with unique values, so varying on the whole cookie header usually turns your cache hit rate to nearly zero. Some CDNs let you build the cache key from a single cookie value instead, which is workable if your consent cookie has a small number of possible states, but it adds complexity and still multiplies the number of cached copies. Moving the decision into the browser is simpler and keeps the cache efficient.

Geography at the Edge

Many publishers show different banners by region: an opt-in banner for the EU and UK, an opt-out notice for US states, and something lighter elsewhere. If the server picks the variant from the visitor’s IP address and that page is cached, a European reader can receive a cached US page, or the reverse.

Three patterns avoid this:

1. Client-side geolocation. Let the CMP determine the region in the browser, so the cached HTML stays the same for everyone.
2. Country in the cache key. If you must decide at the edge, include the country code your CDN provides in the cache key. You get one cached copy per country, which is predictable.
3. Uncached edge logic. Run the regional decision in an edge function that injects a small, uncached value into an otherwise cached page.

Whichever you choose, document it. Geo bugs are among the hardest to reproduce, because they only appear for visitors in one place who happen to receive a page cached by someone in another.

Caching the CMP Script Itself

Caching the CMP loader for a long time is good for performance, but it has a cost when configuration changes. If you update vendors, purposes or banner text and the script or configuration file is cached for a year, some visitors will keep seeing the old version. Check how your CMP versions its files: a changing file name or version parameter lets you cache aggressively while still rolling out changes immediately. Also confirm that your own CDN does not strip query strings from third-party script URLs if the CMP relies on them.

Service Workers and Offline Caches

Sites with a progressive web app layer often cache HTML in a service worker. The same rule applies: never store a page that reflects a specific consent decision. Exclude consent-related endpoints and preference-centre pages from service worker caching, and make sure a fresh CMP configuration can always be fetched.

The Back/Forward Cache

Modern browsers keep recently visited pages in memory so that the back button restores them instantly. If a visitor opens the preference centre on one page, withdraws consent, then presses back, the restored page may still have tags running from before. Listen for the pageshow event and check its persisted property: when a page is restored from this cache, re-read the stored consent state and stop or start tags to match.

A Testing Routine

• Load a page in a clean session, reject, then load a second page and confirm no tracking tags fire.
• Repeat with a second clean browser and confirm the banner appears, proving it was not cached away.
• Check response headers to see whether pages are served from cache, and compare the HTML with and without a consent cookie — it should be identical.
• Test from at least two regions after purging the cache, then again after the cache has warmed.
• Withdraw consent, use the back button, and verify that tags stop.

Key Takeaways

• Cached HTML should be consent-neutral; let the CMP decide in the browser.
• Avoid varying on the full cookie header; it destroys hit rates.
• If banners differ by region, decide client-side or add the country to the cache key.
• Version CMP files so long cache lifetimes do not delay configuration changes.
• Handle service workers and the back/forward cache, and test with the cache warm, not just after a purge.