Why cache warming matters after a purge

What is cache warming?

A CDN fills its cache on demand. When a PoP receives a request for a page it does not have, it fetches the page from the origin, or from an upper tier, stores it, and serves the copy to later visitors until its TTL runs out. Cache warming triggers those first fetches on purpose, from the regions where your visitors are, instead of leaving them to whoever arrives first.

The usual list of pages to warm is the XML sitemap: it already names the pages you want served fast. Warming only helps pages the CDN is allowed to cache, so it starts from correct `Cache-Control` headers.

What happens to a CDN after a purge?

A deploy usually ends with a purge, so visitors stop seeing the old version. CDNs offer two strengths of purge:

• Soft purge, or invalidation: the cached object is marked stale but kept. Fastly soft purge, Akamai invalidate and Cloudflare invalidate work this way, so the edge can revalidate the object with the origin, and serve it under `stale-while-revalidate` when the headers allow.
• Hard purge, or deletion: the object is removed. Akamai calls this delete. A standard Fastly purge, a Cloudflare purge and an Amazon CloudFront invalidation also remove the object, so the next request is a full miss. Note the naming: an Amazon CloudFront invalidation removes files, while a Cloudflare invalidation only marks them stale.

Scope varies too: one URL, a prefix, a host, a cache tag, or everything. Either way, every purged page is cold until something requests it again, in every PoP. The Top 10 CDNs comparison lists which purge options each CDN offers.

Four effects of a cold cache

1. A thundering herd on the origin

When a popular page is purged, everyone who asks for it before it is cached again is a miss. Without protection, each of those requests reaches the origin at once. Request collapsing merges concurrent misses for the same object into one origin request: Fastly documents it, and Cloudflare calls its version a cache lock. It works per location, though, and the collapsed requests still wait for the first one to finish.

2. Slower first responses

A miss adds the round trip to the origin, and the time to generate the page, to TTFB. The first visitors to each page in each PoP pay that cost. With many pages and many PoPs, that is a lot of first visitors.

3. A lower hit ratio

Right after a purge, the cache hit ratio for the purged pages is zero. Pages with steady traffic in a region recover quickly there. Pages with little traffic per region stay cold longer, and some are evicted before anyone reuses them.

4. Origin cost, and why tiered caching is not enough

CDNs do not copy each page to every PoP. Each PoP fills from its own traffic. Tiered caching, such as Cloudflare Tiered Cache, Fastly shielding or CloudFront Origin Shield, lets edge PoPs ask an upper tier before the origin, so far fewer locations call the origin. Each edge PoP still misses once, and the upper tier itself starts cold after a purge.

How a cold cache affects SEO

Search engines care about speed in two places: the experience of real visitors, and how fast their crawlers can fetch your pages.

• Google recommends good Core Web Vitals, and says that this, along with other page experience aspects, aligns with what its core ranking systems seek to reward. Good scores do not guarantee rankings.
• TTFB comes before every rendering metric. web.dev counts it as the first part of LCP, so origin time added by a miss is added to LCP too. A good LCP is 2.5 seconds or less at the 75th percentile. web.dev suggests most sites aim for a TTFB of 0.8 seconds or less. TTFB is not a Core Web Vital itself.
• Warming can help LCP through TTFB. It does not change INP or CLS, which depend on scripts and layout.
• Crawling: Google raises a site's crawl capacity limit when it responds quickly and consistently, naming latency and Time to First Byte, and lowers it when responses slow down or return 5xx or 429 errors. See crawl budget. Warming keeps the pages crawlers fetch after a deploy fast. It does not make Google crawl or index more pages.
• Visitors: slow first loads frustrate visitors and some leave. That is a business cost on its own. We make no claim that bounce rate is a ranking factor.

Warm where your visitors are

Google says Googlebot crawls primarily from IP addresses in the United States, and may crawl from other countries in some cases. The field data behind Core Web Vitals comes from real Chrome users, wherever they are. A page that is warm in the PoPs serving Googlebot can still be cold for your visitors in other regions, and the reverse. Warm the regions where your visitors are. Choosing regions from your Search Console data is planned for sitewarm.

Cold cache versus warm cache

When is cache warming not worth it?

• The CDN does not cache the page: it is personalized, sets cookies, or sends `no-store` or private. Cloudflare, for example, does not cache HTML by default. Fix the headers first, or warming only adds origin load.
• The page has so much traffic in every region that visitors refill the cache within seconds of a purge.
• The content is fingerprinted static assets with a long `immutable` lifetime, which a deploy does not purge.
• You only soft purge, your headers allow serving stale content, and a short window of stale pages is acceptable. Revalidation then hides most of the cold start, although each stale copy still needs one request to refresh.

For how ten CDNs handle cache-status headers, purges, tiers and stale content, read the Top 10 CDNs in 2026, with a caching guide for each CDN such as Cloudflare, Fastly and Amazon CloudFront.