You hit “Publish” on a post correction, purge the CDN cache, refresh the page—and the typo’s still there. You wait. Refresh again. Still wrong. Five minutes later, it updates.
CDN cache purging isn’t instant. Most providers propagate purge commands through distributed edge networks, and that takes time. If you’re running a content business on WordPress, understanding actual purge timing prevents panic refreshes and helps you decide when a full-site purge is worth the performance cost.
How CDN purge propagation actually works
When you purge a cached object—a page, an image, a CSS file—the CDN doesn’t instantly delete it from every edge server worldwide. Instead, your purge request hits the CDN’s API, gets queued, then propagates to regional points of presence (PoPs). Each PoP marks the object stale or removes it, depending on the provider’s architecture.
Cloudflare’s purge-by-URL typically completes in 30 seconds globally, though they quote “up to 30 seconds” as a best-case median. Fastly averages under five seconds for most objects but can stretch to 15–20 seconds during high load. BunnyCDN usually clears within 10–30 seconds. StackPath and KeyCDN sit around 60–90 seconds for full propagation.
Those are averages. Edge cases—literal and figurative—happen. A PoP in Sydney might lag behind one in Frankfurt. If your reader’s browser cached the HTML before the purge, they’ll still see stale content until their local cache expires or they hard-refresh.
What happens during the lag
Between purge initiation and full propagation, some visitors see the old version, others see the new one. If you’re fixing a pricing error or a broken affiliate link, that inconsistency matters.
WordPress caching plugins like WP Rocket, W3 Total Cache, and LiteSpeed Cache trigger CDN purges via API when you update a post. But they don’t wait for confirmation. The plugin fires the request, WordPress shows you the updated post in the admin, and you assume it’s live everywhere. It’s not—yet.
If you need guaranteed consistency, purge the specific URL, wait two minutes, then check from an incognito window or a mobile device on cellular (different network path, different edge server). Don’t rely on your own cached browser session.
Selective purge vs. full-site purge
Most WordPress caching plugins offer two purge modes: purge this page, or purge everything. Purging a single URL is fast and surgical. Purging the entire cache forces every page, image, and asset to reload from your origin server until the CDN re-caches them.
A full-site purge sounds safe—no stale content anywhere—but it costs you. For the next 10–30 minutes, your origin server handles traffic it normally wouldn’t. If you’re on shared hosting or a low-tier VPS, that spike can slow response times or trigger rate limits. BigScoots and other managed hosts handle it better, but you still lose the speed benefit of edge caching until the CDN rewarms.
Purge selectively unless you’ve changed something global: a CSS file, a header template, or site-wide navigation. If you fixed one post’s typo, purge that post’s URL and its homepage listing. That’s it.
When browser cache makes CDN purge irrelevant
CDN purge only matters if the CDN is the bottleneck. If you set aggressive browser cache headers—say, one year for HTML—visitors won’t even request the page from the CDN. Their browser serves the cached copy until the cache-control max-age expires.
Check your caching plugin’s browser cache settings. WP Rocket defaults to one year for static assets (images, CSS, JS) but typically one hour or less for HTML. LiteSpeed Cache lets you set per-file-type TTLs. If your HTML cache TTL is longer than your CDN purge time, the CDN purge won’t help users who visited before the update.
The fix: keep HTML browser cache short (3600 seconds or less) or version your URLs when you make critical changes. Most plugins handle CSS/JS versioning automatically via query strings, but HTML doesn’t get that treatment.
Tool-specific purge behavior
Cloudflare’s WordPress plugin purges the updated post, the homepage, any archive pages that list it, and related tag/category pages. Selective, but broader than just the post URL. Fastly’s plugin (less common) purges by surrogate key, which batches related objects—faster propagation but requires tagging setup.
WP Rocket integrates with Cloudflare, StackPath, and Sucuri CDNs via API. When you save a post, it purges the post URL and any pages you’ve configured in settings. W3 Total Cache supports a longer CDN list but requires manual API key entry and sometimes fails silently if credentials expire.
If purges aren’t working, check your plugin’s CDN settings. API tokens expire, rate limits get hit, and some hosts block outbound API calls from PHP. You’ll see no error in WordPress—just stale content that won’t budge.
Want more infrastructure breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives into the tools that run your online business—no fluff, just what actually happens under the hood.