How the cache is refreshed

Once a page is cached, visitors receive that copy instead of a page freshly built by WordPress. This page explains when that copy is replaced, how quickly your changes reach visitors, and what to expect when you flush the cache.

At a glance

Situation	What happens	Does a visitor wait?
A page has been cached for an hour	It is refreshed automatically	No, with Always Online enabled
You publish or edit content	The pages affected are removed from the cache	The next visitor to each of those pages, briefly
You click Flush Cache	Every page is removed from the cache	The first visitor to each page, briefly
You purge LiteSpeed Cache or another WordPress cache plugin	Nothing changes at the edge: visitors keep being served from Edge Caching	No, and your server sees no surge

In every case, the new version of a page is cached again by the first visitor who requests it, and every visitor after that receives it from the cache.

Purging your WordPress cache no longer takes your site down

Many WordPress sites run a caching plugin such as LiteSpeed Cache, WP Rocket or W3 Total Cache. Purging it, after an update, a design change or simply out of habit, empties that cache all at once. Every visitor’s next request then runs PHP and queries the database until the cache is rebuilt. On a busy site, that surge exhausts PHP workers and database connections and can take the site down, at the very moment you are making changes.

With Edge Caching in front of your site, purging your WordPress cache plugin does not touch the Edge Caching cache. Visitors keep being served from Edge Caching, so the purge causes no surge on your server. Your plugin’s cache refills gradually instead, as Edge Caching refreshes each page in the background, at most once an hour per page.

After purging your WordPress cache plugin	Without Edge Caching	With Edge Caching
Where visitors are served from	Your server, running PHP for every request	Edge Caching, from memory
Requests reaching WordPress	One per visitor, all at once	No additional requests
How the plugin’s cache refills	Under full visitor load	Gradually, one page at a time
Risk of downtime on a busy site	High	None from the purge

Purge your WordPress cache whenever you need to

The same protection applies to any cache running on your server: a plugin’s page cache, a server-level page cache, or an object cache such as Redis. Clearing them no longer exposes your server to your visitors’ traffic.

Purges do travel in the other direction: when Edge Caching purges pages because you edited content, the WordPress plugin also clears LiteSpeed Cache, WP Rocket and Hummingbird for the same pages, so the two layers never serve different versions.

Every hour: automatic refresh

A cached page is kept for one hour. After that hour, the next visitor still receives the cached copy immediately, and Edge Caching asks your server for an up-to-date version in the background. From then on, visitors receive the new version.

This works while Always Online is enabled, which is the default. If you disable it, there is no background refresh: the first visitor after the hour waits while the page is rebuilt. On busy pages this is rarely noticeable; on pages visited only occasionally, that visitor gets a slower response.

When you change content

You do not need to wait an hour for changes to appear. When you publish or edit a post, the Edge Caching WordPress plugin tells Edge Caching which pages to remove from the cache:

• the post itself;
• the front page;
• the posts page, if your site uses one;
• the category pages the post belongs to.

Changes that affect the whole site, such as switching themes, editing a menu or activating a plugin, remove every page instead.

The next visitor to each removed page receives the new version, built by WordPress, and it is cached again for everyone after them. Every other page stays in the cache.

Pages with query strings

A page reached with a query string, such as /products/?color=red, is cached separately from /products/. Removing /products/ does not remove its query string variants; they are refreshed within the hour, or by a full flush.

Flushing the whole cache

Flush Cache in the admin empties the Edge Caching cache itself, which is different from purging your WordPress cache plugin. It removes every page at once. You rarely need it: content changes are handled by the plugin. It is useful after changes the plugin cannot detect, such as editing theme files directly on the server.

What visitors experience

Right after a flush, the first visitor to each page waits while WordPress builds it; everyone after them receives it from the cache again.

Even then, a flush does not send all your traffic to your server. When many visitors ask for the same page at the same moment, Edge Caching makes one request to your server and gives the result to all of them. What matters is how many different pages are requested, not how many visitors:

Visitors at the moment of the flush	Requests to your server
1,200 on the home page	1
900 on /shop/	1
2,500 on /blog/post-1/	1
400 on /blog/post-2/	1
5,000 visitors	4 requests

For most sites, a flush costs the server a handful of requests. Sites with thousands of different pages visited at the same time, such as a large online store, feel it more.

Logged-in visitors, carts and checkout pages are never cached, so a flush does not change anything for them.

Warming after a flush

When Always Online is enabled, a flush from the admin also starts cache warming: Edge Caching visits the pages listed in your sitemap so they are cached again before most visitors arrive. Popular pages are usually ready first; a visitor can still land on a page that has not been warmed yet.

Do not flush while your server is down

A flush also removes the copies Always Online uses to keep your site available during an outage. Flushed pages cannot be served until your server is back. See When your server is down.

Terms

For readers familiar with HTTP caching, here is how these behaviors map to Varnish concepts:

Term	Meaning here
TTL	The one-hour lifetime of a cached page. Origin max-age headers do not change it.
Grace	The period during which an expired page can still be served while it is refreshed. Set by Always Online’s stale period; 10 seconds when Always Online is disabled.
Purge	Removing specific URLs, implemented as Varnish bans on exact, anchored paths.
Flush	A ban matching every URL of the site.
Request coalescing	Varnish holding concurrent requests for the same object on a single backend fetch.