What is cache warming?
Cache warming is requesting your pages through the CDN right after a purge or deploy, so the first visitors get a cached copy, not an origin trip.
Cache warming is requesting your pages through the CDN right after a purge or deploy, so the CDN fetches them from the origin and stores them before visitors arrive. The first real visitor then gets a cache hit instead of waiting for the origin. It is also called cache preloading or cache priming.
deploy -> purge -> warm: GET each URL in the sitemap through the CDN
-> read the cache status of each response
-> repeat from each region that has visitorsWhy a purge leaves the cache cold
A purge removes, or marks stale, the cached copies of your pages in every PoP. Until something requests a page again, the cache is cold for it. CDNs fill caches on demand, one PoP or tier at a time, so busy pages recover quickly in busy regions while everything else stays cold longer.
What warming changes
- Origin load: the misses happen at a pace you choose, instead of as a burst from the first visitors and crawlers. Request collapsing only softens that burst per location.
- TTFB: a warmed page skips the origin round trip, which also helps LCP, because the browser cannot render before the HTML arrives.
- Hit ratio: the purged pages are cached again within minutes instead of whenever traffic reaches them.
- Crawling: crawlers that arrive after a deploy meet cached, fast responses, which Google counts towards crawl capacity.
How to warm a cache well
- Start from the list of pages that matter, usually your XML sitemap, most important pages first.
- Request through the CDN, from each region where you have visitors. A request fills the PoP, and the upper tier, that served it, not the others.
- Send the headers your visitors send, such as
Accept-Encoding, so you warm the same cache key and `Vary` variant they will ask for. - Rate-limit the requests so warming does not become the traffic spike it was meant to prevent.
- Verify each response: read the CDN's cache status and check that a second request is a hit. A
200 OKalone does not tell you the page was cached.
When warming does not help
- Pages the CDN does not cache, such as personalized pages, or responses with `no-store` or
private. Cloudflare, for example, does not cache HTML by default. - Pages with so much traffic everywhere that the first visitors refill the cache within seconds.
- Fingerprinted static assets with a long `immutable` lifetime, which deploys do not purge.
| Cold cache after a purge | Warmed cache | |
|---|---|---|
| First visitor per page and PoP | Waits for the origin | Served from cache |
| Origin load right after deploy | Burst, driven by traffic | Paced by the warmer |
| Crawlers during that window | Meet origin latency | Meet cached responses |
| Evidence that pages are cached | None until someone looks | A cache status per page |
How warming works on a given CDN depends on its cache-status header, purge options and tiers. The Top 10 CDNs comparison scores ten CDNs on those criteria, with a guide for each one, from Cloudflare and Fastly to Google Cloud CDN and Azure Front Door.
Related terms
References
- Cloudflare: Tiered Cachehttps://developers.cloudflare.com/cache/how-to/tiered-cache/
- Fastly: Request collapsinghttps://www.fastly.com/documentation/guides/concepts/cache/request-collapsing/
- web.dev: Time to First Byte (TTFB)https://web.dev/articles/ttfb
Warm your cache after every deploy
sitewarm requests the pages in your sitemap after a deploy and reports the cache state the CDN returns for each one, with the vantage point it was measured from.