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:

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

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.

Which Sitemaps Are Preloaded#Copied!

By default, you configure nothing: on every full preload, MilliCache Pro reads your site's robots.txt and preloads every sitemap listed on a Sitemap: line. That is the sitemap protocol's official discovery mechanism, so whatever publishes your sitemaps (WordPress core, The SEO Framework, Yoast, Rank Math) is picked up automatically, including setups with more than one sitemap. If robots.txt lists no sitemaps, /sitemap.xml is used as the fallback.

Discovery is live: the list is read fresh on each run and never stored, so a sitemap that appears later (a new language, a new SEO plugin) is picked up without touching any settings. The Status tab shows which sitemaps the last run actually used.

Sitemap indexes are followed recursively, so a sitemap that links to per-post-type sitemaps is fully expanded. Entries pointing at a different host are ignored, since preloading only warms this site's cache.

Multilingual Sites (Polylang, WPML)#Copied!

Multilingual sites often publish one sitemap per language with no index linking them. The SEO Framework with Polylang, for example, serves /sitemap.xml for the default language and /en/sitemap.xml for English, and only robots.txt mentions both. Because discovery starts from robots.txt, all language sitemaps are found and preloaded automatically; there is nothing to configure.

SEO plugins that publish a single sitemap index covering all languages (Yoast and Rank Math in most configurations) work just as automatically, since indexes are expanded recursively.

Settings#Copied!

Adding entries replaces the discovered list entirely; discovery is off as soon as the list has one entry. Use this to:

• Exclude a sitemap: enter only the ones you want, e.g. just /sitemap.xml to skip a language sitemap listed in robots.txt.
• Preload an unlisted sitemap: add its path or URL alongside the others.
• Work around a static robots.txt: if your robots.txt is a static file without Sitemap: lines, list your sitemaps here.

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 sitemaps, and how long ago. If a sitemap could not be fetched, returned an error status, or contained no URLs, the check tells you exactly that instead of failing silently — including when only one of several sitemaps failed.

WP-CLI#Copied!

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

By default, the command fetches your sitemaps (configured or discovered from robots.txt) and preloads every URL synchronously with a progress bar.

Options:

Examples:

 1# Preload all URLs from all sitemaps
 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!

• Cache Clearing: what clears the cache in the first place
• Cache Entries Browser: watch the cache refill
• Detailed Metrics: measure your hit ratio over time