
Warm-up summary and visited URLs, with success counts and request timings.
A fast cache only helps when the page is already in it.
After a cache expires or is cleared, the next visitor may have to wait while WordPress builds the page again. Cache Warmer visits your pages ahead of time, giving your existing caching system the opportunity to prepare a cached response before a customer, reader or campaign visitor arrives.
Choose the pages that matter, control the pace and see what happened. Start a warm-up when you need it, run it on a schedule, or queue published content after an edit.
Cache Warmer complements your caching setup. It does not create a page-cache engine or change which pages your cache considers eligible. It works by making HTTP requests that can populate a properly configured plugin, server or CDN cache.
Spend less time managing the queue and more time warming pages. Version 1.5 brings a substantial queue-processing performance improvement for large warm-up configurations. It avoids repeatedly sorting large configuration payloads and handles excluded URLs in bounded batches, while preserving queued work, recovery and configured HTTP visit limits.
In one production observation on a large WooCommerce store, warming worker executions dropped from roughly 100 seconds to 1–3 seconds after the update. This measures individual background-worker executions, not page-load speed or total crawl duration. Results vary with the queue, hosting, page response times and scheduler availability.
Progress reporting now shows completion timestamps, elapsed time that includes pauses, clearly labelled average visit speed and skipped totals on every log page.
Warm your homepage, landing pages, articles and public product pages without manually opening them one by one. After a deployment or cache purge, start a run to help rebuild the cache for the pages you have selected.
This is especially useful when important pages receive too little regular traffic to stay warm on their own.
Build a focused crawl or cover more of your public site:
Depth 0 visits entry points only. Use a larger depth when you want to discover linked pages, and set exclusions to keep the crawl focused.
Set an automatic interval in minutes, or start a run manually from WordPress. Enable post-update warming to queue published content after publication or editing, with a configurable delay.
Scheduled runs and post-triggered runs have separate histories, so you can see what ran and why. Background processing uses Action Scheduler.
Control the maximum pages per minute, request timeout, crawl depth and included assets. Start with a small group of pages, inspect the results and expand the crawl to suit your site’s capacity.
The speed setting is a ceiling, not a promised throughput. Response times and background-worker availability also determine how quickly a run completes.
Inspect visited URLs, successful and failed requests, HTTP response codes, error messages and request timings. When returned by the server, logs include cache headers such as cf-cache-status, x-cache and X-WP-Super-Cache.
A dashboard chart summarizes request timings before and after warming. Use the evidence to investigate cache misses, redirects, slow pages and broken URLs. These are HTTP measurements from the warmer, not a visitor’s browser rendering time or Core Web Vitals score.
Choose whether to request discovered scripts, styles, images and fonts. Configure user agents, request headers, cookies and URL parameters for the cache variants you intend to warm.
Optional second visits without custom cookies or URL parameters help cover the corresponding plain request. Request variants need to match your cache rules; additional variants also increase the work performed.
Pending URLs are stored in the database, and workers coordinate processing of the queue. Interrupted background work can resume through subsequent workers; failed page requests receive a bounded retry and remain visible in the logs.
Configure warm-up log retention to manage history. Recovery information is retained where needed rather than silently discarded.
Run local warming from your WordPress server without an external-warmer subscription. An optional licensed service can request pages from configured external locations. See External Services below for the information shared when that integration is enabled.
Get started with a few cacheable pages, run a warm-up and inspect their cache headers. Then choose the schedule and crawl coverage that fit your site.
Local warming sends HTTP requests to configured entry points and discovered page or asset URLs, which may include external hosts. Those hosts receive the warmer’s connection information and configured request headers, including any cookies or URL parameters you supply. Configure only destinations and credentials appropriate for the crawl.
Adding or changing an external-warmer license key sends the site domain and key to https://validate.cachewarmer.xyz/ for validation. When external warming is enabled, the selected service endpoints receive the domain, license key, target URLs and configured request headers, including user-agent and cookie values. Those servers then request the target URLs and return results to the plugin.
Local warming does not require this service. Review the configured servers and avoid sending sensitive session cookies or credentials unless appropriate for your intended use. Contact [email protected] for access, service terms and privacy information.