Skip to main content
sitewarm
Purging & invalidation

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 visitors

Why 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 OK alone 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 purgeWarmed cache
First visitor per page and PoPWaits for the originServed from cache
Origin load right after deployBurst, driven by trafficPaced by the warmer
Crawlers during that windowMeet origin latencyMeet cached responses
Evidence that pages are cachedNone until someone looksA 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.

References

  1. Cloudflare: Tiered Cachehttps://developers.cloudflare.com/cache/how-to/tiered-cache/
  2. Fastly: Request collapsinghttps://www.fastly.com/documentation/guides/concepts/cache/request-collapsing/
  3. 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.