Cache Preloading

Cache Preloading keeps your cache warm, so visitors never wait for a page to be built. Instead of the first visitor after a cache clear paying the full WordPress render time, MilliCache Pro requests the pages itself in the background.

Enable it under Settings → MilliCache → Modules → Cache Preloading.

What Triggers a Preload#Copied!

Preloading is event-driven. There is no cron schedule to configure; the module reacts to the moments where the cache actually loses entries:

Event What gets preloaded
You publish or update a post The post itself plus its related pages (the post-type archive, author, taxonomy, and date pages, derived from the post's cache flags)
A cache entry is invalidated The removed entry's URL, reconstructed from its flags, is re-queued
A full cache clear Every URL from your XML sitemap
You enable the module Every URL from your XML sitemap
Preload Full Cache (manual) Every URL from your XML sitemap

The manual trigger lives in the settings header menu (Preload Full Cache) and on the empty state of the Entries browser.

Note: Expiring the cache (the soft variant of clearing, where stale pages keep being served while they regenerate) intentionally does not trigger a sitemap preload. Stale-while-revalidate already keeps visitors fast in that case.

How It Works#Copied!

flowchart LR
    A[Cache cleared /<br/>post published] --> B[URLs queued]
    B --> C[Action Scheduler<br/>background batches]
    C --> D[HTTP request<br/>per URL]
    D --> E[Page rendered once,<br/>stored in cache]
  1. URLs are collected in a queue (a set, so the same URL is never queued twice).
  2. Action Scheduler processes the queue in background batches of 50 URLs.
  3. Each URL is requested over HTTP with the user agent MilliCache/1.0, exactly like a visitor would. The response lands in the cache; already-cached URLs are simply a cache hit and cost nothing to re-request.

While the Edge Cache module has purges pending, preload batches wait and retry 30 seconds later, so pages are never warmed through a stale CDN edge.

You can watch progress in the summary bar of the Entries tab ("Fetching sitemap…", "Preloading: N URLs remaining") and in the Status tab.

Settings#Copied!

Setting Default Description
Sitemap URL empty Path to your XML sitemap, relative to the site root. Leave empty to use the default (/sitemap.xml, which WordPress redirects to its core sitemap). Override it if your sitemap comes from an SEO plugin like The SEO Framework, Yoast or Rank Math and lives at a different path.

Sitemap indexes are followed recursively, so a sitemap that links to per-post-type sitemaps is fully expanded.

Important: WordPress serves no core sitemap while Settings → Reading → "Discourage search engines from indexing this site" is enabled. In that case there is nothing to preload from: either make the site public or point the Sitemap URL at one generated by an SEO plugin. The Status tab warns about this state.

Monitoring#Copied!

The Status tab shows a Cache Preloading check with the outcome of the last sitemap run: how many URLs were queued, from which sitemap, and how long ago. If the sitemap could not be fetched, returned an error status, or contained no URLs, the check tells you exactly that instead of failing silently.

WP-CLI#Copied!

 1wp millicache preload [--uri=<uri>] [--dry-run] [--async]

By default the command fetches the sitemap and preloads every URL synchronously with a progress bar.

Options:

Option Description
--uri=<uri> Preload a single URI (path or full URL) instead of the full sitemap. Use the global --url=<site-url> to scope to a specific site on multisite.
--dry-run List URLs that would be preloaded without actually requesting them
--async Enqueue URLs for background processing via Action Scheduler instead of preloading synchronously

Examples:

 1# Preload all URLs from the sitemap
 2wp millicache preload
 3
 4# Preload a single URI
 5wp millicache preload --uri=https://example.com/about/
 6
 7# Preview which URLs would be preloaded
 8wp millicache preload --dry-run
 9
10# Enqueue for background processing
11wp millicache preload --async

If the module is inactive, the command offers to activate it before running.

Notes#Copied!

  • Background preloading runs through Action Scheduler (bundled with MilliCache Pro), which relies on site traffic or WP-Cron to process its queue. On very quiet sites, consider running Action Scheduler via a real cron job so preloads finish promptly.
  • Preload requests are fire-and-forget with a short timeout. The page keeps rendering server-side after the request returns, so a large site finishes warming shortly after the queue empties.
  • Disabling the module drains the queue and unschedules all pending preload work.

Next Steps#Copied!

Last updated: