How it works

A cache only helps the second visitor. The first one waits while the page is built. The warmer fetches every page ahead of time, so no visitor has to be first.

The plugin’s own How it works tab shows these steps too, with a live read of your site’s cron setup.

The cycle

The queue is built. Your sitemap is read and every URL on your own domain is queued, minus the personal pages and your exclusions. The queue is rebuilt once a day.
A worker wakes up. On your worker interval, a scheduled job takes the URLs that are due: never warmed first, then the ones warmed longest ago.
Each URL is fetched twice. Once as a desktop browser, once as a phone. Caches keep a copy per device, and one request cannot fill both.
The answer is recorded. The response header says HIT (served from cache) or MISS (built on the spot). That is what the dashboard counts.
It backs off when it should. Slow answers, or a 429 or 503, make the next run smaller.

Building the queue

The warmer reads the sitemap at Sitemap URL, or <domain>/sitemap_index.xml when that field is empty. A sitemap index and a plain urlset both work. The sitemap is read fresh on every rebuild, so new pages join the queue by themselves.

What goes in:

Every URL in the sitemap that sits under your Canonical domain. URLs on any other host are skipped.
Your Extra URLs, even if there is no sitemap at all.
With Archive pagination on, page 2, 3 and so on of every public taxonomy archive, the shop and the blog, up to Deepest page. The number of pages comes from how many items each term has.

What stays out:

Cart, checkout and account pages, read from WooCommerce in every language, plus the order and account endpoints behind them.
Paths in Never warm these paths, and everything under them.
URLs matching Additional exclusions.
URLs with a query string, while Query strings is on.
Image sitemaps, while Image sitemaps is on.

If no sitemap can be read and Content fallback is on, the warmer walks your published content instead: the post types and taxonomies you list, capped at Fallback ceiling URLs. It is a rough list, because it cannot know what you left out of the sitemap.

Order

The home page is warmed first, then archives, then everything else. A page you publish or update jumps to the front of the queue while Warm on change is on.

Desktop and mobile passes

LiteSpeed and most CDNs pick the cached copy by user agent. The response carries vary: User-Agent, and the rules that decide what counts as a phone live in .htaccess or in the CDN.

With Mobile pass on, every URL is fetched with the desktop user agent and again with the mobile user agent. That doubles the requests per cycle, not the size of the queue. The first cycle after you turn it on is slow, because every mobile page is built from scratch.

The mobile user agent must contain a token your cache recognises: Mobile, Android, Silk/, Kindle, BlackBerry, Opera Mini or Opera Mobi. Without one the request lands in the desktop bucket and the mobile copy stays cold, while the screen still reports success. The default mobile user agent is an iPhone Safari string that contains Mobile.

To check that your cache really splits desktop and mobile, request the same page twice with two user agents and compare the cache header:

curl -sSI -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) Mobile/15E148" \
  https://example.com/shop/ | grep -i x-litespeed-cache

Reading the cache answer

The warmer looks for a known cache header in each response. Empty Cache header means it detects one from the response. These are recognised:

Cache	Header
LiteSpeed	`x-litespeed-cache`
Cloudflare	`cf-cache-status`
Nginx	`x-cache-status`, `x-proxy-cache`, `x-fastcgi-cache`, `x-nginx-cache`
Varnish	`x-cacheable`
Kinsta	`x-kinsta-cache`
SiteGround	`x-sg-cachehit`
Sucuri	`x-sucuri-cache`
20i	`x-20i-cache`

Age and Cache-Control are used as a fallback. Each answer is reduced to one of these:

HIT: served from cache. This is what warming is for.
MISS: built on this request. On a first pass that is the warming request itself, and expected.
BYPASS: the cache was told to skip this page. Warming cannot help, and for a personal page it should not.
No cache: no cache header came back, so nothing in front of WordPress is caching the page.
Unknown: a header came back with a value the plugin does not recognise. Naming the header under Cache header usually settles it.

Only a real MISS counts as cold. Bypass and no cache are decisions your stack made on purpose, and unknown means the header could not be read.

The cold share is measured from the second pass on. A first pass answers MISS on every URL by definition, so it is never counted and never emailed about.

Pacing

A run takes up to Batch size URLs and sends up to Requests at a time in parallel, with Delay between requests after each one. Requests go out in parallel through the HTTP library WordPress already ships.

A run stops itself after 45 seconds, so PHP cannot kill it halfway. What did not fit goes first next time. The log shows such a run as “time limit”.

Adaptive pacing

With Adaptive pacing on, your settings are ceilings. After each run the warmer looks at how long your site took to answer and, where the host allows it, the one-minute load average:

Requests slower than 2 seconds, or a busy machine: the next run sends half as many requests at once.
Requests faster than 0.8 seconds: one more request at a time, up to your setting.
Half or more of the requests failed: one request at a time.
A 429 or 503: one request at a time, and no requests until the Retry-After window has passed.

The dashboard shows the current value as Requests at a time, for example “2 of 3”, with “held back, the site is answering slowly” when it is below your setting.

Quiet window

Inside the hours you set under Quiet window, a run uses Batch size then and Requests at a time then instead of the daytime values. The same URLs are warmed in the same order; only the pace changes. Hours are in site time, and a window may cross midnight.

After a purge

A full purge empties the cache, so every URL is cold again no matter when it was last warmed. With Reset on purge on:

A full LiteSpeed purge clears the recorded results, and a fresh pass starts.
A purge done outside WordPress, such as from the LiteSpeed panel or an .htaccess save, is caught too. Each run checks three recently warmed URLs, and when all three come back cold the queue is reset.

The fresh pass counts as a first pass, so it is not judged or emailed about.

The dashboard

The Cache warming tab is the dashboard.

At the top, one line says whether warming is running and what to do if not:

Status	Meaning
Warming normally	How many pages are warm, and when the worker last ran.
Warming is switched off	The Worker switch is off. Nothing is fetched; the queue is kept.
The queue is empty	Rebuild the queue to read your sitemap.
Nothing has run yet	The worker has never woken up. If that lasts more than a few minutes, nothing is calling it.
Warming has stopped	The worker has not run for too long. Fix the cron.
Pages are not staying warm	The cold share is above your Miss threshold.
A full pass takes more than a day	Pages expire before they are warmed again. Change the pace.

Below it:

Counts: URLs queued, never warmed, warmed in 24h, and the cold share.
Desktop bucket, Mobile bucket and HTTP codes: what the cache and the server answered.
Recently warmed: each URL with its HTTP code and the desktop and mobile answers. Hover an answer or a code for what it means.
Rhythm: last run, next run, last and next rebuild, the quiet window, the measured response time and the last alert.
Setup: the domain, sitemap, cache header, mobile pass, requests at a time and failures on record.

Buttons

Run one batch now: does now what the schedule would do later.
Rebuild the queue: reads the sitemap again.
Warm everything again: clears the recorded results so every URL is due. It does not purge your cache.

The See it work panel warms a few URLs in front of you with Warm a few URLs now. One URL, right now warms any URL or path you paste, ahead of everything else, and adds it to the queue. Pages on the never-warm list are refused.

The Log tab

Worker runs lists each run with its URLs, requests, seconds and result. Events lists what the warmer had to say, filtered by level. Entries older than Keep log entries days are dropped once a day. Clear the log empties it now.

Run results you may see:

ok: the run finished everything it took on.
nothing due: every URL was warmed recently enough. Normal between passes.
already running: another run held the lock, so this one stepped aside. Seen often, it means two schedules do the same job, usually a server cron and WP-Cron.
time limit: the run stopped at 45 seconds. Seen on every run, the batch is bigger than what fits.

Turn on Debug in Settings to log a line per URL with the cache header that came back.