---
title: "Magento 2 cache warming: Varnish, Full Page Cache and the CDN edge — warmup.rocks"
description: "How to warm Magento 2's Full Page Cache and Varnish after cache flushes, deploys and reindexing — and why the CDN edge cache needs its own warming strategy."
canonical: https://warmup.rocks/blog/magento-cache-warming
---

Magento

# Magento 2 cache warming: Varnish, Full Page Cache and the CDN edge

July 2026 · 9 min read · [← All posts](https://warmup.rocks/blog/)

Magento 2 without a warm cache is one of the slowest mainstream platforms on the web — an uncached category page can take 2–5 seconds of pure server time while Magento assembles layouts, blocks and collections. With a warm cache the same page returns in 20–50 ms. No other platform has a bigger gap between cache hit and cache miss, which makes warming more valuable on Magento than anywhere else.

## The three cache layers of a Magento store

| Layer | Technology | Goes cold when… |
| --- | --- | --- |
| Full Page Cache (FPC) | Built-in (files/Redis) or Varnish — Adobe recommends Varnish for production | `cache:flush`, reindexing, product saves, deploys |
| Block/config caches | Redis | Deploys, config changes |
| CDN edge cache | Cloudflare, Fastly (Adobe Commerce Cloud), CloudFront… | TTL expiry, purges — _per edge location_ |

Most Magento performance talk focuses on the first layer. But if you serve international customers through a CDN that caches HTML, the third layer decides what a first-time visitor in each country actually experiences — and it's the one no Magento module can warm.

## Why Magento caches go cold so often

Magento invalidates aggressively, and rightly so — prices, stock and promotions must be correct. In practice your FPC gets (partially) flushed by:

-   **Product and category saves** — cache tags invalidate every page the product appears on: product page, categories, search results, CMS blocks with widgets.
-   **Reindexing** — price or catalog rule reindexes invalidate wide swaths of the catalog.
-   **Deploys** — `setup:upgrade` and `cache:flush` empty everything.
-   **Cron-driven catalog imports** — ERP syncs at night can silently flush the cache right before your morning traffic peak.

Each of these events puts the slowest version of your store in front of the next visitor — multiplied by every CDN edge location if you cache HTML at the edge.

## Step 1: warm the FPC / Varnish

The origin-side playbook is well established:

1.  **Use Varnish, not the built-in FPC**, in production. The built-in cache is a developer fallback; Varnish serves hits without touching PHP at all.
2.  **Crawl after invalidation.** The classic approach is a sitemap crawl after deploys and flushes — a shell loop, a cron job, or one of the Magento cache-warmer modules (Amasty, Mirasvit and others hook into invalidation events and re-crawl the affected URLs with configurable priority).
3.  **Prioritize by revenue:** home page, top categories, best-selling products first; the long tail after. Warm with the store's real currency/store-view parameters if you run multiple store views — each view has its own cache entry.
4.  **Don't warm as a logged-in customer** — customer-group pricing creates per-group cache variations. Warm anonymously (the default group) unless you know a specific group drives your traffic.

## Step 2: the layer the modules can't reach

Every Magento warming module — and every cron crawl — runs from one place: your server or a box next to it. That fills Varnish and the FPC. It does **not** fill the CDN edge cache, because edge caches are populated by requests that enter the CDN network at each specific location. Cloudflare runs 300+ data centers; Fastly (which fronts Adobe Commerce Cloud) runs its own global POP network. Your server-side crawl warms exactly _one_ path into that network.

The result is a familiar pattern: your domestic market feels fast (organic traffic keeps nearby colos warm), while international shoppers get cold-cache TTFB on their first pageview — precisely the audience that already has the least patience with your brand. You can see this yourself: run a product URL through our [free cache checker](https://warmup.rocks/cache-checker) and compare the cache status across locations.

[warmup.rocks](https://warmup.rocks/) closes that gap: it reads your Magento sitemap (`sitemap.xml` generated by the built-in sitemap cron) and requests every URL through proxies in 40+ countries on a schedule. Each request enters the CDN at a different edge location, so every colo caches its own copy — and the dashboard shows the resulting [hit ratio per location](https://warmup.rocks/blog/cache-hit-ratio) after every run.

## Adobe Commerce Cloud / Fastly notes

-   Fastly caches HTML out of the box on Commerce Cloud — your edge cache is live even if you never configured it. That makes edge warming immediately effective.
-   Purges are tag-based and surgical (product saves purge only affected pages), so a scheduled warming pass mostly re-fills what actually changed.
-   Fastly's `x-cache` header reports `HIT`/`MISS`; warming requests through global proxies register per-POP, same as Cloudflare colos.

## What to warm, in order

1.  **Category pages** — highest traffic, most expensive to render (layered navigation!), and invalidated by nearly every catalog change.
2.  **Top products** — your revenue pages.
3.  **CMS pages** — home, landing pages, campaign pages before a promo starts.
4.  **The long tail of products** — individually low-traffic, collectively most of your catalog and permanently cold without warming.

Schedule the warming interval to match your cache TTLs and your invalidation rhythm — [our scheduling guide](https://warmup.rocks/docs/schedules) covers how to pick an interval that keeps the cache warm without wasting requests.