Cache purge
A cache purge removes content from a CDN's caches on demand, before its TTL would expire it — the tool for "the content changed, stop serving the old version." The flip side: every purge manufactures cold caches, and the first visitor afterwards pays for it.
The purge spectrum
| Method | Scope | Cold-cache damage |
|---|---|---|
| Purge by URL | Exact cache keys | Minimal — only changed objects go cold |
| Purge by tag / surrogate key | All objects labeled with a tag (e.g. product-42) | Proportional — precise if your tagging is |
| Purge by prefix / wildcard | Path subtrees | Broad |
| Purge everything | The entire zone | Total — every URL at every PoP is a miss again |
Tag-based purging (Fastly's surrogate keys, Cloudflare cache tags) is the precision tool: tag each page with the entities it renders, then purge the tag when an entity changes. Purge-everything is the blunt default in most deploy pipelines — convenient, and by far the most destructive to your hit ratio.
Purge ≠ invalidation, strictly speaking
Some systems distinguish hard purge (delete the object) from soft
purge/invalidation (mark it stale but keep the bytes). A soft-purged object can still
be served under stale-while-revalidate
or stale-if-error semantics while the cache refreshes — visitors keep
cache speed even during the transition. Prefer soft purges where your CDN offers
them.
Purge and re-warm belong together
A purge without a warming pass hands your miss penalty to real visitors — at the median a miss is 3.5× slower, per our production measurement. The clean deploy sequence is: deploy → purge (as narrowly as possible) → re-warm the affected URLs from every region, automatically. That last step is what deploy hooks exist for.