Warmup Cache Request: Fill the Cache Before Your Visitors Arrive

A cache is a stored copy of a page or a response, kept close to your visitors so the server does not have to build it again for every request. Right after a deploy, a restart or a cache clear, that store is empty. Teams call this a cold cache, and it means the first visitors of the day pay the full building cost: the database queries, the template rendering and the API calls, all of it, on every early page view.

A warmup cache request is the fix, and it is a simple idea. Before you open the doors, you request your own most important pages and endpoints yourself. Each request takes the slow path once, stores the finished response, and leaves the cache warm. When the first real visitor arrives, the stored copy is already waiting, and the slow first build happened on your schedule instead of theirs. The technique also goes by the names cache warming and cache preloading, and most caching tools have a setting or a button for it.

This guide explains the mechanics in plain words. It covers why the first request is always the expensive one, how to prove a warmup worked by reading cache status headers, the three cache layers a single request fills, four ways to send warmup requests, what to warm and what to skip, and the mistakes that quietly waste the whole effort.

Why the first visitor pays full price

A cache only helps when it holds a copy. On a cold cache, the copy does not exist yet, so the first request for a page does all the work itself. The web server runs the application code, the code asks the database for the content, templates turn that content into HTML, and only then does the response travel back. The cache stores that finished response on the way out, which is why the second request for the same page is cheap and the first one never is.

Cloudflare describes the moment precisely in its cache documentation. Its CF-Cache-Status header reports MISS when a resource was eligible for caching but was not present in the cache at request time, so the response was served from the origin web server. In plain words, a miss means somebody waited while the origin built the answer. That somebody can be a customer, or it can be your warmup cache request. The whole point of warming is choosing who pays.

The cost of choosing wrong grows with traffic. One slow first view is a shrug. A product launch, a newsletter send or a news mention that pushes a crowd onto a cold cache turns into many slow first views at the same moment, and every one of them runs the same database queries at once. Slow queries hurt most exactly here, on a cold cache, which is why warming pairs naturally with the work in our guide to database optimization. Warming does not make a slow page fast. It moves the slow moment from your visitors to a time you control.

How to tell it worked: read the cache headers

You never have to guess whether a warmup cache request worked. Every serious cache reports its decision in a response header, a small label attached to the response that says where the response came from. Send one request, read the header, then send the same request again. The first response should report a miss, and the second should report a hit. If the second response still reports a miss, the page is not being cached at all, and warming it is pointless until you fix the reason.

On Cloudflare, the header is CF-Cache-Status, and its values tell the whole story. HIT means the resource was found in the cache. MISS means it was eligible but not stored yet. EXPIRED means a copy was stored but its time limit had passed, so the origin served a fresh one. BYPASS means the origin told the CDN not to store the response, for example with a no-store instruction or a cookie header. DYNAMIC means the file type was never eligible for caching in the first place. The full list lives in Cloudflare’s cache response documentation.

Amazon CloudFront says the same thing in different words. Its X-Cache header reads Miss from cloudfront when the request came from the origin, Hit from cloudfront when it came from the edge cache, and RefreshHit from cloudfront when CloudFront checked the stored copy with the origin and found it unchanged. AWS also notes that responses served from the origin carry no Age header, while cached responses show an Age that counts up in seconds, so a growing Age is a quiet second proof of a hit. The worked examples live in the AWS guide to CloudFront object caching.

A terminal turns this into a ten second check. Run curl with the -I flag against your page, look at the cache headers, wait a moment, and run it again. A warmed page shows the pattern in the chart below: a miss on the first request, a hit on the second, and an Age value that grows between checks.

The three places a warmup request fills

A modern site rarely has one cache. It has a stack of them, and a single warmup cache request can fill several layers on its way through, because each layer asks the next one for help whenever it misses.

The first layer is the CDN edge cache. A content delivery network, or CDN, keeps copies of your pages on servers around the world, close to your visitors. Cloudflare and Amazon CloudFront both work this way. One honest limit lives here: each edge location keeps its own cache, so a warmup request warms the location that handled it. Warm from the regions your traffic comes from, or accept that the first visitor in a distant region may still meet one miss.

The second layer is the full page cache on your own server. Tools like Varnish sit in front of the web application and store finished HTML pages in memory. On a miss, Varnish fetches the page from the application, stores the response and serves it, and later requests get the stored page without touching the application at all. WordPress sites reach the same result with a caching plugin instead of a proxy. WP Rocket, for example, includes a Preload feature that scans your sitemaps to detect the URLs to preload, and it also adds pages that real visitors open to its preload list, so the list stays current between runs.

The third layer is the object cache, usually Redis or Memcached. Instead of whole pages, it stores the pieces pages are built from: database query results, computed values and API responses, held in memory for fast reuse. Page requests warm this layer as a side effect, because building the page runs the queries. Some applications also warm it directly, with a startup script or a scheduled job that calls the expensive queries and endpoints before traffic begins. On larger stacks these layers sit between many connected systems, which is the world our guide to enterprise application integration explains: the warmer the shared layers are, the fewer systems feel the morning rush.

Four ways to send a warmup request

There is no single right tool, and the method matters less than the habit. Whichever one you pick, the warmup cache request itself stays the same: an ordinary request for the URL, made early, on purpose. The four methods below cover almost every stack, from a small WordPress site to a large application with its own release pipeline.

The crawler script deserves one extra note, because it is the method teams most often build by hand. It is a small, polite version of the crawling we explain in our guide to web scraping, pointed at your own site: fetch the sitemap, walk the list in order, pause briefly between requests, and log the cache header of every response. That log is your proof. A run that ends with hits on every important URL is a finished warmup. A run full of misses and bypasses is a bug report about your cache rules, delivered before your customers could file it.

What to warm first, and what to skip

Warming works best as a short list, not a full crawl. Choose the targets of each warmup cache request by a simple rule: if a slow first view of this page would hurt, warm it. For most sites that means the homepage, the top landing pages from your analytics, the busiest product and category pages, and any page a campaign is about to send traffic to. Add the shared files every page needs, such as the main images, stylesheets and scripts, because a fast page with slow assets still feels slow.

API responses belong on the list too. The endpoints your app calls on every load, such as search, the home feed or the product list, are exactly the responses that should be waiting in the cache. These endpoints deserve the careful treatment we describe in our guide to API design principles: predictable URLs, honest cache headers and responses that a cache is actually allowed to store.

Just as important is what to leave off the list. Carts, checkouts, payment pages and account screens are personal. Caches refuse most of them by design, because a response built for one signed-in user must never be served to another, and the BYPASS value exists for exactly these cases. Admin screens, preview links and rare archive pages waste origin time on copies nobody will request. The guidance runs the same way from the tool makers: WP Rocket’s documentation for large sites advises preloading only the most visited pages instead of the full sitemap, because a giant preload can still be running when the cache clears again.

Mistakes that waste the warmup

The first mistake is warming before the deploy finishes. If half your servers still run the old code, your requests store a mix of old and new pages, and if the deploy is broken, you can even store error pages. CloudFront, for example, caches error responses for ten seconds by default, and other caches have similar habits. A warmup cache request sent too early is worse than none at all, because it spends the origin’s effort on copies you are about to throw away. Warm last, after the release is live everywhere and the smoke tests pass.

The second mistake is hammering the origin. A warmup that fires hundreds of parallel requests at a cold site is not a warmup, it is a small denial of service attack on yourself. The origin still has to build every page once, and it can only build so many at a time. Spread the requests out, run them one or a few at a time, and start with the pages that matter most, so even a half finished run leaves the important copies in place.

The third mistake is forgetting that warmed copies expire. Every cached response has a time limit, called its TTL, short for time to live. Warm a site in the morning for an evening launch and the copies may expire before the crowd arrives. Time the warmup close to the moment you need it, or repeat it on a schedule that matches your TTLs, the way the cron method does.

The last mistake is warming only the homepage. Traffic rarely lands there. It lands on the article the newsletter linked, the product the ad promised and the pricing page from the search result. Build the warm list from real landing page data, and the warmup covers the visits you will actually get.

Conclusion

A warmup cache request is a small habit with an outsized effect: you take the one slow, expensive first build of every important page and schedule it for a moment when nobody is watching. The mechanics are simple enough to prove with two curl commands and a response header. Warm after every deploy and purge, warm the short list of pages and endpoints that carry your traffic, move at a pace your origin can handle, and verify the headers flipped from MISS to HIT. Do that, and the first visitor penalty stops being a surprise your customers discover for you.