--- title: "What is cache warming? A practical guide — warmup.rocks" description: "Cache warming explained: how proactively filling caches works, which caches can be warmed (CDN, page cache, object cache), and when it's worth automating." canonical: https://warmup.rocks/blog/what-is-cache-warming --- Fundamentals # What is cache warming? A practical guide July 2026 · 8 min read · [← All posts](https://warmup.rocks/blog/) Every cache has the same embarrassing secret: it starts **empty**. The fastest CDN in the world serves its first request the slow way — all the way from your origin server, database queries and all. Cache warming (also called cache preloading or cache priming) is the practice of filling caches _proactively_, before real users arrive, so that the first visitor gets the same instant response as the millionth. ## The cold-cache problem A cache stores the result of expensive work — a rendered HTML page, a database query, a resized image — so the work doesn't repeat. But entries appear in a cache only when someone requests them, and they disappear constantly: - **TTL expiry:** every entry has a lifetime. When it ends, the next request is a miss. - **Eviction:** caches have finite memory. Under pressure, rarely-requested entries are dropped early — long-tail pages go first. - **Purges and deploys:** every deployment or manual purge resets the cache, often globally. - **Geographic fragmentation:** CDNs cache per edge location. A page cached in Frankfurt is still cold in Tokyo, São Paulo and Sydney. The result: on most sites, a surprisingly large share of requests are cache misses — especially on pages that aren't the homepage. Those visitors get the slow experience, and they're disproportionately _first-time_ visitors, the ones you least want to greet with a three-second load. ## How cache warming works The mechanism is disarmingly simple: **request the page before a user does.** A warming request is an ordinary GET request. The cache in front of your origin sees a miss, fetches the response, stores it — and every subsequent request within the TTL is a hit. The complexity is in doing it _right_: 1. **The right URLs.** Warm the pages people actually visit — usually everything in your sitemap — not a hand-maintained list that rots. 2. **The right shape.** The request must look like a real browser request (matching `Accept-Encoding`, no cache-busting query strings), or the cached variant won't match what visitors request. 3. **The right places.** For CDN caches, requests must enter the network where your visitors are — more on that below. 4. **The right rhythm.** Warm slightly more often than your TTLs expire, and re-warm after every deploy or purge. ## Which caches can be warmed? ### Server-side caches Page caches (WordPress plugins, Varnish, Nginx proxy cache), object caches (Redis, Memcached) and opcode caches live on or near your origin. One crawler visiting your URLs warms them fine — this is what most WordPress "preload" features do, and it's genuinely useful. ### CDN edge caches This is where it gets interesting. Cloudflare operates 300+ data centers, Fastly, Akamai and CloudFront hundreds more — and **each edge location keeps its own cache**. A request from a server in Virginia warms the Virginia edge. Every other location stays cold. To warm a CDN properly, requests must genuinely originate from many regions, so each one enters the network at a different edge location. That's the part a plugin on your own server structurally cannot do. ### Application-layer edge caches Frameworks that render at the edge (Cloudflare Workers, edge functions) often use their own per-location cache — for example the Cloudflare Workers Cache. Same rule: per-colo, warmable only by requests that actually land in that colo. ## When is cache warming worth it? Warming pays off most when misses are expensive and frequent: - **Long-tail content:** hundreds of product, article or docs pages that each get a few visits per day — individually too rare to stay cached organically. - **Global audience, regional traffic:** your US traffic keeps US colos warm, but the occasional visitor from Singapore always hits a cold cache. - **Slow origins:** server-rendered apps with database work, where a miss costs seconds, not milliseconds. - **Frequent deploys:** every release purges the cache; warming refills it in minutes instead of hours. It matters less on sites with a handful of pages and heavy traffic in one region — organic traffic keeps those caches warm on its own. ## Measuring success: hit ratio The metric to watch is your [cache hit ratio](https://warmup.rocks/blog/cache-hit-ratio) — the share of requests answered from cache. Before/after warming, it typically moves from "fine on the homepage, poor everywhere else" to consistently above 90%. The user-facing effect shows up as [TTFB](https://warmup.rocks/blog/time-to-first-byte): warm cache hits are served in tens of milliseconds; cold misses cost whatever your origin costs. ## DIY or a service? A cron job with `curl` over your sitemap is a fine start for warming _server-side_ caches. For CDN caches you additionally need geographically distributed egress, CDN-specific cache-status parsing, pacing, sitemap re-discovery and hit-ratio reporting — which is the point where a dedicated service earns its keep.