Technical
Cache purge
Cache purge is a request to a CDN or cache to drop stored copies of a URL, a tag, or the whole site, so the next request fetches fresh content from the origin. Until it completes, edges keep serving what they already hold.
How it is measured
Read the `Age` and `cache-status` (or `CF-Cache-Status`) headers on the URL. `HIT` with `Age: 4210` means the edge is serving a copy 70 minutes old. After a purge the next request shows `MISS` or `EXPIRED` and `Age: 0`.
Most CDNs finish in seconds; some take minutes across all sites. Test from more than one location, because one fresh edge says nothing about another.
Worked example
A news blog fixes a typo in `/2026/budget-explained`. The origin returns the fixed HTML at once, but `curl -I` through the CDN shows `Age: 2890`. A single-URL purge goes out. The next request is a MISS at 480 ms, and the one after is a HIT at 38 ms.
The stylesheet `main.css` was cached for a year under the same name, so the page still looks wrong until `main.css?v=412` is requested. The lasting fix is a versioned filename, not another purge.
How it differs
A cache purge removes stored copies at the CDN. It does not change the origin and does not touch the copy already sitting in a visitor's browser. The CDN is the network that holds copies; the purge is the command that empties them.
Common errors
Purging everything on every deploy and sending a stampede to the origin. Forgetting the browser still holds a copy under `max-age`. Purging the HTML but not the API response behind it. Purging `example.com/page` when the cache key includes `www` or a query string. Assuming it finished because the purge API returned 200.
In practice
Use cache tags or versioned asset names so a deploy does not need a purge-all. After any purge, request the URL from two regions and read the cache-status header. Put the purge call in the deploy script so nobody does it by hand.