After a deploy or a cache flush, Magento’s full page cache is empty, and the first visitor to every page pays the full dynamic render. Under traffic, that cold cache can overwhelm PHP. Cache warming crawls your pages to fill the cache before real users arrive, in the right order.
Full page cache is what makes a Magento storefront fast: a cached page is served in milliseconds without touching PHP. The problem is the moment the cache is empty. This guide covers why the cold cache is dangerous, how warming works, what to warm first, and how to do it on Hyva without overloading the origin. For the server-side foundation, see our Magento development services.
Why a cold cache is a production risk, not just a slow page
When full page cache is populated, most requests are a cache HIT and never reach Magento. When the cache is empty, every request is a MISS that runs the full dynamic render: layout, blocks, database queries, the works. One cold page is just slow. The danger is at scale.
Picture a flush during business hours. Suddenly every incoming request is a MISS. PHP-FPM workers fill up rendering pages that used to be served from cache in milliseconds. Response times climb, the queue backs up, and the site can tip over, a thundering herd against your origin. This is the cold-cache spike, and it is why you never run a blanket cache:flush on a busy production store without a plan to re-warm. Our guide to scaling Magento for flash sales and product drops covers the same failure mode under traffic spikes.
The fix is to repopulate the cache yourself, in a controlled way, before real users do it for you.
When the cache goes cold
The cache does not only empty on a manual flush. It goes cold or partially cold after:
- A deploy that flushes cache, or a
bin/magento setup:upgrade. - A full
cache:flush, which clears everything including non-page caches. - Cache-tag invalidation from catalog changes: a category save, a price rule, a product edit. Magento invalidates only the pages tagged with the changed entity, which is a far smaller, more surgical event than a full flush.
That last point is the key to doing this well. Magento tags cached pages by the entities on them, so a single product change invalidates just the pages showing that product, not the whole site. Prefer targeted invalidation over full flushes, and you shrink the warming job from “the entire catalog” to “the handful of pages that actually changed.” Adobe’s page cache developer documentation and the Magento_PageCache module source describe how tag-based invalidation works.
How warming actually works
There is no magic. Warming is a crawler that requests your public URLs so the server renders each page once and stores it in cache, so the next visitor gets a HIT. The pieces:
- A URL list. Usually your
sitemap.xml, optionally supplemented with top-traffic URLs from analytics. - A crawler that fetches each URL, which triggers the render and the cache store. A simple
wget --spiderover the sitemap works; extensions do the same with more control. - An order, so the pages that matter most are warm first.
- Throttling, so the warm-up does not become its own cold-cache spike.
On-premise Magento does not ship a dedicated production warmer in core, so teams either script the crawl or use an extension. On Adobe Commerce Cloud, the deploy process has a post-deploy phase that can warm pages. Either way the mechanism is the same: request the page, let it cache.
A DIY warm-up versus an extension
The simplest DIY warm-up is a crawl of your sitemap right after a flush or deploy. A wget --spider over sitemap.xml, or a short script that reads the sitemap and fetches each URL with limited concurrency, will render and cache every public page. It costs nothing and is easy to drop into a post-deploy hook.
Extensions add control on top of that bare crawl: queue generation on cron, multi-process fetching, automatic re-warming when the cache is flushed from the admin, and ranking the queue by visit count. Mirasvit’s full page cache warmer documentation is a good reference for how a cron-driven warmer builds and processes a URL queue, filters excluded URLs, and marks each page cached once the server responds. The choice is usually DIY for simple stores and an extension once the catalog is large enough that warm order and queue management actually matter.
Warm the right pages first
Warming the entire catalog alphabetically is a waste if the cold-cache spike hits your homepage and top categories. Order the queue by value:
| Priority | Pages | Why |
|---|---|---|
| 1 | Homepage, top categories, best-sellers | Highest traffic, worst to be slow |
| 2 | Remaining category and brand pages | Common entry points |
| 3 | Product pages by sales rank | Long tail, warm as capacity allows |
| 4 | CMS and informational pages | Lower traffic, lower urgency |
Several warmers rank the queue by real visit counts so the most-visited URLs warm first, which is exactly the right instinct: match the warm order to where the traffic actually lands. Exclude pages that should never be cached as public content, such as cart, checkout, and account pages.
Throttling: do not warm too fast
The warm-up itself hits the origin with requests, each a cache MISS by definition. Fire thousands of concurrent warm requests and you recreate the exact spike you are trying to avoid. The balance:
- Too much concurrency overloads PHP-FPM and the database, the warm-up becomes an outage.
- Too little and warming a large catalog takes hours, leaving pages cold for real users in the meantime.
Tune concurrency to leave headroom for real traffic, and warm during low-traffic windows when you can. Measure the effect at the cache layer, watching hit rates climb as the warm-up runs, and keep an eye on response time so the warm-up never competes with customers. The metric your customers feel is Time to First Byte, and web.dev’s guide to TTFB explains why a cached page served fast at the edge is the single biggest lever on perceived speed. Warming is a performance tool, so pair it with the rest of the work in our guide to reducing Magento time to first byte.
Warming on Hyva, and what client-side prefetch adds
Hyva does not change the warming model, but two things are worth knowing:
- Hyva pages are cheaper to render. A Hyva page has far less frontend weight than Luma, so a cache MISS costs less PHP and renders faster. The cold-cache spike is less violent, though it is still real at scale.
- Private content is separate. Hyva loads customer-specific data client-side through customer-data sections, so the warmer only requests the cacheable public shell. You are never warming per-customer content, which keeps the job clean.
There is also a client-side complement to server-side warming. Speculation Rules let the browser prefetch or prerender the next page a visitor is likely to click, so navigation feels instant even for pages the server has already cached. Our guide to Speculation Rules on a Hyva Magento storefront covers that. The two work together: server-side warming makes the first render fast, and prefetch makes the next navigation feel instant.
Keep cron and invalidation healthy
Warming that runs on cron depends on cron being healthy, and targeted invalidation depends on indexers being healthy. If cron is stalled, a cron-driven warmer never runs; if indexers are invalid, cache tags may not clear correctly and warm pages can serve stale data. Our guide to Adobe Commerce cron and indexer health covers keeping that machinery running, and the warming strategy sits directly on top of it. The full picture of how the cache itself is configured is in our guide to Magento full page cache and Varnish on Hyva.
The same problem on other platforms
The cold-cache problem is most visible on self-hosted Magento because you own the cache layer. Managed platforms hide more of it:
- Teams on Shopify development do not manage a full page cache; Shopify’s CDN and caching are handled for you.
- BigCommerce development and Shopware development abstract caching to varying degrees, with less direct control than Magento.
More control means more responsibility: on Magento you decide when to flush, how to warm, and how fast. The team at Bemeir manages this on production stores, and our technology partners include the hosting and CDN layers warming depends on.
FAQ
Does Magento have a built-in cache warmer?
Core on-premise Magento does not ship a dedicated production cache warmer. Adobe Commerce Cloud’s deploy process has a post-deploy phase that can warm pages. On-premise, teams either script a crawler over the sitemap or use a warming extension. The mechanism is always the same: request public URLs so each page renders and caches.
What is the cold-cache spike?
It is what happens when full page cache is suddenly empty under traffic. Every request becomes a cache MISS that runs the full dynamic render, PHP workers fill up, and response times climb until the site can tip over. Controlled cache warming after a flush or deploy prevents it.
Should I run cache:flush on production?
Avoid a blanket cache:flush on a busy production store, because it clears everything and leaves every page cold. Prefer targeted cache cleaning and tag-based invalidation so only changed pages drop out, and warm them back deliberately. If you must flush, do it in a low-traffic window with a warm-up ready.
What should I warm first?
Warm by traffic value: homepage, top categories, and best-sellers first, then remaining categories, then product pages by sales rank, then low-traffic CMS pages. Many warmers rank the queue by real visit counts automatically. Exclude non-cacheable pages like cart, checkout, and account.
Does Hyva change cache warming?
Not the model. Hyva pages render faster on a cache MISS because they carry less frontend weight, so the cold-cache spike is less severe, and private content loads client-side so the warmer only requests the public shell. Pair warming with Speculation Rules for instant client-side navigation.
Warm your cache before your customers do it for you
A cold full page cache is a quiet liability that only shows up under load, usually at the worst time. Warming is simple in principle and easy to get wrong in practice, from warm order to throttling. Bemeir is the USA’s first Hyva Gold Partner and an Adobe Commerce performance shop. Learn more about Bemeir and how we keep storefronts fast through deploys and traffic spikes. See our Hyva development services for the frontend that benefits from every warm page.
