How to purge your CDN cache (and when you actually should)
Purging is the big red button of CDNs: it clears the cache so changes show up now. Useful, occasionally necessary, and easy to over-use — often as a substitute for fixing the actual problem.
Every CDN has a purge button, and every team eventually develops a slightly unhealthy relationship with it. It starts as a legitimate tool for pushing a correction live. It becomes, over a year or two, something people click reflexively whenever anything looks wrong, because it is the one control everybody understands.
Which is a shame, because a site that needs frequent purging is usually a site with a fixable configuration problem, and the purging is masking it.
What a purge actually does
Purging removes a cached object so the next request for it becomes a cache miss. The edge then fetches a fresh copy from your origin, serves it, and stores it for next time.
Notice the consequence: every purged object is a guaranteed origin request in the near future. Purge one URL and that is one request. Purge everything on a busy site and you have just scheduled a very large number of simultaneous origin requests, at whatever moment your traffic next arrives.
The four kinds of purge
| Type | What it clears | Origin impact | Use when |
|---|---|---|---|
| Single URL | One exact object | Negligible | You changed one page |
| Prefix / wildcard | Everything under a path | Proportional | A whole section changed |
| Cache tag | Every object carrying a tag | Proportional and precise | One entity appears on many pages |
| Everything | The entire cache | Severe | Genuine emergencies |
Cache tags are the one worth setting up
The problem with URL-based purging is that content does not map neatly to URLs. Change one product's price and that product appears on its own page, three category pages, the homepage carousel, two collection pages and a search result. Purging "the product page" leaves five stale prices.
Cache tags solve this. Your origin attaches tags to each response — a product page might carry product-8842, category-boots, brand-acme — and the CDN indexes objects by tag. When that product changes, you purge the tag product-8842 and every page carrying it is invalidated at once, wherever it lives.
This takes an afternoon to wire up and eliminates most of the reasons people reach for purge-all. If you run a shop or a publisher with any real content graph, it is the highest-value hour in this article.
Why purge-all hurts more than it looks
Emptying the entire cache means every subsequent request is a miss until the cache refills. On a quiet site that is fine. On a busy one, three things happen at once.
Your origin receives a sudden multiple of its usual traffic — the exact load the CDN exists to prevent, delivered without warning. Your response times climb for everyone, since every visitor is now waiting on a full origin round trip. And if many visitors request the same uncached object simultaneously, you get a cache stampede: dozens or hundreds of identical concurrent requests for one page, because the first response has not arrived to populate the cache yet.
Good CDNs mitigate the last one by collapsing concurrent misses for the same object into a single origin request. It is worth confirming yours does, because it is the difference between a purge being a blip and a purge being an incident.
If you must purge everything on a high-traffic site, do it at your quietest hour and warm the cache afterwards by crawling your top URLs. Ten minutes of crawling your own sitemap is much cheaper than an hour of real visitors each paying for a miss.
Soft purge
A refinement worth knowing about. A hard purge deletes the object. A soft purge marks it stale instead, leaving it in the cache — so if the origin is slow or unavailable, the edge can still serve the stale copy while it revalidates, rather than having nothing at all.
For content where a slightly outdated version is better than an error page, which is most content, soft purging is the safer default. Reserve hard purges for things that must genuinely never be served again — a page with incorrect pricing, or content withdrawn for legal reasons.
When you should purge
Content changed and the change is time-sensitive
A corrected price, a published article, a withdrawn product. Purge that URL or tag.
Something wrong got cached
An error page, a half-rendered response, a page cached with the wrong currency. Purge it, then fix the reason it was cacheable.
You deployed something that changes shared output
A template change affecting every page. This is one of the few legitimate broad purges — and cache tags let you scope it.
When you should not
- After deploying fingerprinted assets. New content means a new filename, which is a new cache key. There is nothing to purge.
- As a debugging step. Purging to see whether it helps destroys the evidence and tells you very little.
- On a schedule. A cron job purging the cache nightly is a TTL expressed in the most expensive possible way. Set the TTL instead.
- Because you are not sure. Check the
AgeandCache-Controlheaders first. Most "the cache is stale" reports turn out to be a browser cache, which purging the CDN does nothing about.
That last one deserves emphasis, because it accounts for a lot of unnecessary purging. If a visitor's browser cached a page for an hour, purging the CDN will not help them — they are not asking the CDN. This is exactly why s-maxage exists: keep browser lifetimes short and edge lifetimes long, so purging is actually effective when you do it.
Frequently asked questions
What does purging a CDN cache do?
Purging removes cached objects from the CDN so the next request for them must be fetched fresh from your origin. It is how you force an update to appear immediately rather than waiting for the cached copy's TTL to expire. Each purged object results in at least one subsequent origin request.
How often should I purge my CDN cache?
Rarely, and only in response to a specific change. Frequent purging usually indicates TTLs that are set wrong or assets that lack content hashes in their filenames — the purging is compensating for a configuration problem rather than solving one. Scheduled purges are particularly wasteful, since a TTL achieves the same thing without emptying the cache.
Is purging the entire cache bad?
On a busy site, yes. Every subsequent request becomes a cache miss until the cache refills, which sends your origin a sudden multiple of its normal load and can trigger a cache stampede where many identical concurrent requests arrive for the same uncached object. Prefer purging by URL or cache tag, and if a full purge is unavoidable, do it during quiet hours and warm the cache afterwards.
What are cache tags and why use them?
Cache tags are labels your origin attaches to responses so the CDN can index cached objects by entity rather than only by URL. A product page might be tagged with its product ID, category and brand, and every page carrying that product also carries the tag. Changing the product then requires purging one tag rather than hunting for every URL where it appears.
Do I need to purge after deploying new CSS or JavaScript?
Not if your build produces fingerprinted filenames such as app.a1b2c3.css. A change to the file produces a new filename and therefore a new cache key, so the old entry is simply never requested again and expires on its own. Purging is only necessary for assets served under a stable filename.
Why do I still see old content after purging the CDN?
Most often because the stale copy is in your browser, not the CDN, and purging a CDN cannot reach it. Check with a hard reload or a private window. This is why HTML should carry a short max-age alongside a long s-maxage — browsers hold it briefly while the edge holds it long — since a CDN can be purged and a browser cannot.
Purge by URL or, better, by cache tag; keep purge-all for emergencies and warm the cache afterwards. Prefer soft purges so a stale copy remains available if the origin struggles. And if you are purging often, treat that as a signal to fix your TTLs and add content hashes to filenames — a cache you have to babysit is a cache that is misconfigured.
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
