Fastly cache warming: instant purge deserves instant re-warm

Fastly's headline feature is instant purge: invalidate an object across the entire global network in roughly 150 milliseconds. It's genuinely great — and it has a flip side nobody puts on the landing page: purging is instant, re-filling is not. The moment your purge lands, every POP on the planet is cold for that content, and each one refills only when a visitor happens to ask for it there.

How Fastly caches: per POP, clustered inside

Fastly runs on the order of a hundred POPs. Within a POP, requests are clustered: consistent hashing sends each URL to one primary cache node, so a single POP behaves like one logical cache — efficient. But across POPs there is no sharing by default: a HIT in Frankfurt says nothing about Tokyo. You can see it in the headers — x-served-by names the POP (e.g. cache-fra-eddf8230050-FRA) and x-cache shows HIT/MISS, sometimes as a pair like MISS, HIT when a shield was involved. Our cache checker reads both automatically, from six locations at once.

Shielding helps your origin, not your visitors' TTFB

Fastly's origin shield designates one POP as the funnel to your origin: edge POPs that MISS fetch from the shield instead of hitting your server. This collapses N origin fetches into one — great for origin load. But note what it doesn't do: the first visitor at each edge POP still pays a two-hop round trip (edge → shield → maybe origin) before that POP is warm. Shield is origin protection, not edge warming. The two combine well: with shielding on, a global warming pass costs your origin almost nothing — most warming requests terminate at the shield.

Soft purge: use it, and warm behind it

A hard purge deletes objects; a soft purge marks them stale instead. Combined with stale-while-revalidate in your Surrogate-Control header, visitors keep getting the (slightly old) cached copy while Fastly revalidates in the background:

Surrogate-Control: max-age=3600, stale-while-revalidate=86400, stale-if-error=86400

Soft purge + SWR is the single best setting for content sites on Fastly — it turns the purge cliff into a gentle slope. Two caveats: it only helps POPs that had the object (cold POPs stay cold), and the revalidation is triggered by a visitor request — the long tail still serves stale for a long time or expires out. A scheduled warming pass sweeps both cases: it triggers the background refresh everywhere and fills the POPs that never had the object.

Surrogate keys: purge precisely, warm precisely

Fastly's surrogate keys let you tag responses (Surrogate-Key: product-123 category-shoes) and purge by tag. If your CMS purges by key on every edit, your purges are already minimal — good. The warming counterpart is straightforward: after a key purge, re-request the affected URLs so they're hot before the next reader. A warmer that re-reads your sitemap on a schedule catches this automatically, since the edited pages are in there.

A practical Fastly warming setup

1. Serve HTML with Surrogate-Control (cache at the edge, controlled by you; keep Cache-Control separate for browsers).
2. Enable shielding on your origin — it makes warming nearly free for your backend.
3. Use soft purge + stale-while-revalidate instead of hard purges wherever freshness allows.
4. Warm from multiple locations on a schedule. One crawler warms one POP (plus the shield). warmup.rocks requests your sitemap from 90+ locations across 40+ countries, hitting the POPs where your audience actually is, and reports the hit ratio per location and run.
5. Verify per location — a single-location check can't tell you whether Singapore is warm. The cache checker and the global TTFB test can.