Warming pages up

Off by default. Switched on, the plugin quietly requests a few pages every five minutes — the front page first, then your pages, then recent posts — so nobody has to be the first visitor to a cold page.

Deliberately unhurried. Four pages every five minutes warms a thousand in a day without anybody noticing. The Settings screen says how long a full pass over your list takes at the saved rate, and says so when that is longer than the page lifetime, which means some pages expire before they are warmed again.

A page the cache has just cleared goes to the front of the queue, and a batch runs half a minute later, so the product you have just edited is warm again before most visitors reach it. Emptying the whole cache starts the list again from the front page. A batch that is running at that moment reads the list again just before it writes it back and takes off only the pages it warmed. A page cleared again after the batch began fetching it stays at the front, even when it was already first in the list, as it is when you save the same page twice in a row. That includes a save that lands while the batch is still building the page: the copy the batch stores once it has built it may be the page from before your save, so the batch clears it again and warms it on its next run. One narrow gap is left: a clear that lands in the instant between that last read and the write can still lose its place, and that page is then warmed when the list comes round to it, or by its next visitor.

Add the pages in your sitemap is on when warming is, and is the better source: your SEO plugin already keeps the list of pages worth finding, with everything you set to noindex left out. WordPress's own wp-sitemap.xml, Yoast's and Rank Math's sitemap_index.xml, and a plain sitemap.xml are all read. If none exists, the built-in list is used instead.

Once preloading is on and saved, Preload now on the Settings screen starts a batch straight away — useful after emptying the cache before a sale — and the rest carries on in the background.

It decides its own pace#

You do not have to work out what your hosting can take. Before any background work runs, the plugin reads the PHP memory limit, the execution time limit and — where the host will say — the load average:

• on a host that looks small (under 128MB of memory, or an execution limit under 30 seconds) the rate you chose is halved;
• while memory is more than two-thirds spent, or the load average is above twice the processor count, background work stands down entirely and picks up next time.

Nothing is lost when it stands down. The queue is exactly where it was.

Diagnostics shows these readings under Server Limits.