---
title: "Fastly cache warming: instant purge deserves instant re-warm — warmup.rocks"
description: "Fastly purges globally in ~150 ms — and leaves every POP cold. How Fastly's per-POP caching, shielding and soft purge interact with cache warming, and how to keep hit ratios high after purges."
canonical: https://warmup.rocks/blog/fastly-cache-warming
---

Fastly

# Fastly cache warming: instant purge deserves instant re-warm

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

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](https://warmup.rocks/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**](https://developer.fastly.com/learning/concepts/purging/) 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](https://warmup.rocks/) requests your sitemap from 90+ locations across 40+ countries, hitting the POPs where your audience actually is, and reports the [hit ratio](https://warmup.rocks/blog/cache-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](https://warmup.rocks/cache-checker) and the [global TTFB test](https://warmup.rocks/ttfb-test) can.