The cruel arithmetic of launch day: your earliest visitors are your most motivated ones — the mailing list, the press-release clickers, the fans who set alarms — and a cold cache sends precisely those people to your origin for the full miss-path experience, all at once. Cache warming is the fix: fetch the content through the edge yourself, before the doors open, so the crowd finds it already there.
Why cold caches bite hardest at launch
Steady-state traffic warms its own cache: yesterday's visitors paid the misses that make today's hits. Launches break that bargain twice over. New content has no yesterday — every object starts cold — and launch traffic is a synchronized spike, so the misses arrive in a burst that lands on your origin at the exact moment it can least afford them. The failure compounds: concurrent cold requests for the same objects can multiply origin load unless collapsed (see the origin-load guide), origin latency rises under the burst, and the slow responses hold the miss window open longer. Warming converts that burst into a scheduled trickle you control, run at a quiet hour, against a relaxed origin.
Building the warm list
Warming is only as good as its URL list, and the list is where efforts quietly fail. It needs exact, canonical URLs as the cache will key them: the launch pages, their full asset graphs — CSS, JS, fonts, images, in the fingerprinted filenames the new deploy will actually reference — plus every variant that is part of the cache key: each image format and size if you serve responsive variants, each compression encoding if your platform caches them separately, each language or region version. Generate it mechanically rather than by hand — from the build manifest, the sitemap, or a crawler pointed at a staging copy of the new pages — because the hand-built list always misses the hero image's mobile variant, which is the one the crowd hits first. Then rank it: warm in order of expected first-hour traffic, so if the job runs long, the head of the list is what matters and it's done.
Reaching the right POPs
The step most first-timers miss: CDN caches are per-location. A warming script run from your office populates the POP near your office and nothing else; the launch crowd in other regions still lands cold. So warm from where the audience is — run fetchers in each target region (cloud instances in a handful of regions cover most audiences), sized to the geography of your mailing list rather than of your infrastructure. Two refinements help. If your platform supports origin shield, warming through it means even unwarmed edge POPs will miss to the shield rather than to your origin, softening the penalty everywhere you didn't reach. And check whether your provider offers native prewarm or preload tooling before building your own — several do, and the built-in version knows the POP map better than you do.
Sequencing against TTLs and purges
Warmth decays: an object warmed at midnight with a one-hour TTL is cold again by the 9 a.m. launch. Sequence the job against your TTLs — warm inside the window where launch-hour arrivals will still find objects fresh, which for short-TTL content means warming late, close to the door-opening, rather than comfortably the night before. Coordinate with the deploy, too: if shipping the launch involves a purge or new fingerprints, warming must run after that moment, or you are lovingly pre-heating content the deploy is about to evict. The clean pattern is a pipeline: deploy → purge what's replaced → warm the list → verify → open the doors. For long campaigns (a sale weekend), schedule re-warming passes at intervals shorter than the shortest important TTL, so warmth is maintained rather than achieved once and mourned.
Verifying warmth
Never declare a cache warm from the warming script's exit code — the script proves requests were sent, not that objects were stored, and a stray cookie, a cache-control surprise or a key mismatch can make the whole run a no-op. Verify from the outside: after warming, fetch a sample of the list from each target region and read the cache-status header; it should say HIT everywhere that matters. Spot-check the variants specifically (the mobile image, the Brotli encoding), since key mismatches hide there. Then watch the first minutes of the real launch in the logs with hit ratio on the launch paths as the live scoreboard — it should start high and stay there. If a fresh-content launch opens below your normal steady-state ratio, some population is missing that the list didn't cover; the logs will name it, and the next launch's list gets it. Warming is a checklist skill: the second run is always better than the first, provided the first was verified rather than assumed — and the whole drill is one line of the spike-day checklist.