ABCode Cache Warmer is a cache warmer and cache preloader for WordPress. It rebuilds your page cache automatically after every purge, so no visitor is ever the one who waits for a cold, uncached page.<\/p>\n\n
Clearing your cache makes your site slow for a while. Every page has to be rebuilt from scratch, and it is your visitors who pay for it, the first person to land on each page waits for PHP and the database instead of getting a cached response. This plugin fixes that by visiting your pages for you, straight after a purge, so the cache is warm again before anyone real arrives.<\/p>\n\n
It works alongside any caching plugin or host cache: WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, Cache Enabler, Breeze, Nginx cache, Cloudflare, Kinsta, SiteGround and 20i StackCache among them. Your cache builds and serves pages; this plugin makes sure they are built before a visitor needs them.<\/p>\n\n
Most cache warmers request one URL at a time with a pause in between. On a site with a few hundred pages that leaves the cold-cache window open for many minutes, which is exactly the problem you were trying to solve.<\/p>\n\n
This plugin warms several URLs at once using the HTTP library already bundled with WordPress. No Composer, no vendor directory, no third-party HTTP client. Just a much shorter cold window.<\/p>\n\n
There is no one-size-fits-all crawl speed. A VPS can take eight concurrent requests without noticing; cheap shared hosting cannot.<\/p>\n\n
On first load the plugin measures your site's real response time and combines it with your PHP memory limit, CPU count and current server load to pick safe settings automatically. While a run is in progress it keeps watching: if responses start slowing down it backs off on its own, and speeds back up when the server recovers. Every value stays manually adjustable.<\/p>\n\n
Other warmers report HTTP 200 and call it a success. A 200 tells you the page loaded, not that it got cached.<\/p>\n\n
This plugin reads the cache headers on every response and reports what really happened for each URL:<\/p>\n\n
It recognises Cloudflare (including stale-while-revalidate states), LiteSpeed and QUIC.cloud, Varnish (by its transaction IDs), Fastly, CloudFront and Akamai, Sucuri, Nginx FastCGI and proxy caches, the standard Cache-Status header (RFC 9211), Kinsta, SiteGround, 20i's StackCache and StackCDN, Batcache (WordPress.com, Pressable, VIP), and (by their page signatures) WP Rocket, WP Super Cache, W3 Total Cache, WP Fastest Cache, Breeze and WP-Optimize.<\/p>\n\n
Where a host runs two layers, an origin cache on the server and a CDN edge in front of it, as 20i does, the layers are read outermost first, because a cached edge response carries frozen copies of the inner layer's headers from the moment the entry was built. A hit is credited to the layer that really served it, and a miss only counts once every layer outside it has also missed. So on 20i you will see Cached \/ StackCDN for pages the edge already held, and Warmed \/ StackCache for pages the warmer genuinely built.<\/p>\n\n
URLs are not warmed in whatever order the database returns them. The homepage goes first, then archive landing pages, then content, and the whole queue is then ordered breadth-first, so shallower pages warm before deeper ones.<\/p>\n\n
On a site structured as \/accommodation\/ \u2192 \/accommodation\/cottages\/ \u2192 \/accommodation\/cottages\/rose-cottage\/, the parent pages get warmed first. They take the most traffic and they are usually the most expensive pages to rebuild, because they run listing queries. Within each level, the most recently updated content comes first.<\/p>\n\n
You can also skip URLs by pattern, with Warming raw image files is usually pointless, and this plugin does not push you into it. Image files are served straight off disk by your web server with no PHP involved, so there is no cold cache to prevent.<\/p>\n\n There is one case where it genuinely helps: plugins that build each image on first request, such as ShortPixel Adaptive Images, Optimole, EWWW Easy IO, Jetpack or a WebP\/AVIF converter. There, the first visitor really does wait for the conversion.<\/p>\n\n For that case the plugin takes a smarter route than crawling your media library. It reads the image URLs out of the HTML it has already downloaded while warming your pages, so it warms exactly the files (and exactly the responsive sizes) your live pages reference, rather than thousands of library items no page uses. Images are always queued behind every page, and capped per run so an image-heavy site cannot drown out the page warming.<\/p>\n\n No URL limits. No locked features. No upsells. The whole plugin does the whole job.<\/p>\n\n\n No. It works alongside whatever cache you already run. Your caching plugin builds and serves the cache; this plugin makes sure the cache exists before a visitor needs it.<\/p><\/dd>\n No. While the tab is open the browser drives the run, which is the fastest option and gives you live results. Close the tab and WP-Cron takes over, so the run keeps going in the background. Come back later and the page picks up exactly where it got to, you never have to start again.<\/p>\n\n Background progress depends on WP-Cron. The Schedule tab checks whether cron is actually being serviced rather than guessing from configuration: DISABLE_WP_CRON with a server cron running wp-cron.php (the setup most managed hosts use) is reported as healthy, and a warning only appears when scheduled tasks are genuinely overdue and nothing is firing them.<\/p><\/dd>\n Yes. The Schedule tab runs warming every hour, twice a day, daily or weekly, using whichever sources you picked on the Warmer tab. Daily, twice-daily and weekly runs fire at a time you choose, in your site's timezone (most sites want the early hours, so 3am is the default) and weekly runs on the day you pick. Twice-daily runs at the two times you choose, they need not be twelve hours apart.<\/p>\n\n Purge-triggered warming deliberately has no quiet-hours setting: a purge means the cache is cold right now, and making visitors wait until 3am for warm pages would defeat the point. The load-aware throttling is what keeps that immediate response polite.<\/p><\/dd>\n Yes, and it is on out of the box, that is the whole point of the plugin. Clear your cache and, a minute later, the warmer starts rebuilding it, so the cold window closes before your visitors find it.<\/p>\n\n It listens for the purge actions fired by WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache, Cache Enabler, SiteGround Optimizer, Breeze, Hummingbird, WP-Optimize, Nginx Helper and Autoptimize. The Schedule tab shows which of those it found on your site.<\/p>\n\n StackCache on 20i hosting is fully supported, by a different route: it fires no purge action of its own, so the warmer hooks the exact events its source purges on. A full purge, switching theme, saving the Customiser, activating or deactivating a plugin, or pressing StackCache's own Purge Cache button in the admin bar or its settings page, triggers a full warm. Its single-page purges are matched with single-page warms: the publish trigger covers edits, and an approved comment re-warms just the page it landed on.<\/p>\n\n Purges that announce themselves are caught instantly. For the ones that do not, StackCache's own purge button, a host clearing the cache at server level, an eviction, a watchdog checks the cache every ten minutes by fetching your homepage and reading the same cache headers the warmer reads. A cold homepage alone is never trusted as proof of a full purge: the watchdog confirms against sentinel pages spread across the site, saved from your last run. Only a quorum of them also being cold starts a full warm, a single purged or evicted page stays a local event, and the checks themselves will have re-warmed it. However the cache gets emptied, the cold window is minutes, not until the next schedule.<\/p>\n\n Using something else? Any cache that fires an action when it clears can be wired in with one line:<\/p>\n\n Yes. The Results tab lists every retained run (when it ran, what triggered it, and how it went) and each one expands to its full per-URL results: what happened to every URL, which cache layer answered, and the time of day it was warmed. Every URL is a link that opens in a new tab, so chasing down a failure is one click. The newest run opens itself.<\/p>\n\n You choose how long runs are kept, in Advanced settings: an age in days and a maximum count. Retention is rolling, each stored run drops off individually as it passes the age you set, rather than being wiped in bulk. Nothing here needs a database table.<\/p><\/dd>\n Only that page gets warmed. Fixing a typo clears one page, so recrawling the whole site would be absurd, the warmer just re-requests the page that went cold, as a single request, entirely separately from the full-run machinery. Only a site-wide purge starts a full run.<\/p>\n\n Publishing works the same way: it warms the post plus the pages that list it, your homepage, its post type archive, and your blog page if you use a static front page. An approved comment (which most page caches silently purge the post for) re-warms just that one page, under the same setting. Targeted warms are logged on the Results tab like any run, bucketed by the hour, so what was re-warmed after each edit stays answerable.<\/p>\n\n The publish trigger matters most on hosts whose cache clears edited pages silently, such as StackCache on 20i: there is no purge action to hear, so without the publish trigger a saved post simply stays cold until something else warms it.<\/p><\/dd>\n Two things. A burst of purges (a bulk edit fires one per post) folds into the single run already waiting, and a five minute cooldown stops a site that purges constantly from crawling itself back to back. The wait before warming is adjustable on the Schedule tab, and the cooldown is filterable with The warmer backs off and retries, rather than ploughing on. An HTTP 429 is treated as an instruction, not a failure: the refused URLs go back on the queue for up to two more attempts, the crawl drops to one request at a time with a full second between, and the run stands down for the server's Retry-After window (a minimum of thirty seconds) before trying again. A URL still refused after three attempts is marked failed with a note suggesting lower concurrency. Instantly rejected requests are also kept out of the speed measurements, so a burst of rejections cannot trick the adaptive throttle into thinking the server is fast.<\/p><\/dd>\n Google Analytics, Matomo, Plausible, Fathom and anything else JavaScript-based will not see the warmer at all. Those tools count a visit when their script runs in a browser; the warmer downloads HTML and never executes JavaScript, so no tracking ever fires. It cannot trigger ad impressions for the same reason.<\/p>\n\n Server-side counters are the exception. Tools that count visits in PHP or from server logs (WP Statistics, log analysers, hosting bandwidth graphs) will see the warming requests, and only on cache misses, since a cache hit never reaches PHP. To make filtering easy, every warming request carries a Warming adds no work overall. Every cold page has to be rendered exactly once by somebody, warming only decides that it is the warmer that waits for it rather than a visitor, and lets you choose when. The only genuinely extra work is rendering pages nobody would have visited before the cache expired anyway.<\/p>\n\n While a run is going, the load it adds is simply your concurrency setting: five concurrent requests is five simultaneous visitors, no more. Everything else the plugin does is rounding error next to that.<\/p>\n\n It is also careful about when it does it. Before every batch it checks both how fast your site is responding and how loaded the machine actually is, and scales itself down accordingly, down to a single request at a time, and to a complete standstill if the server is genuinely struggling, resuming once it recovers. Those are two different signals on purpose: on shared hosting the box can be flat out serving someone else while your site still answers quickly.<\/p>\n\n The one thing it cannot see is how many PHP workers your host gives you. If that number is small, set the concurrency by hand: 2 on entry-level shared hosting, 4 or 5 on a decent VPS, 8 or more on a dedicated server.<\/p><\/dd>\n No, far cheaper. An already-warm page returns a cache hit that never touches PHP, so a scheduled run over a warm site costs a fraction of the first crawl. The expensive case is a run straight after a full purge, when everything is cold, which is exactly why the automatic run waits before it starts, and why on a large site it is worth pushing that wait up to several minutes.<\/p><\/dd>\n Local and staging sites very often use self-signed certificates, and verification would make every request fail there. The plugin only ever requests URLs on your own domain, so this is low risk, but you can turn verification on in Advanced settings.<\/p><\/dd>\n Probably not. Warming a page caches that page's HTML, it does not fetch the images on it, because only a real browser does that. If your images are ordinary files, your web server sends them without touching PHP and there is nothing to warm.<\/p>\n\n Turn images on only if you run a plugin that generates images on first request (ShortPixel Adaptive Images, Optimole, EWWW Easy IO, Jetpack, or a WebP\/AVIF converter). On a site with many thousands of images, warm the pages and leave images off.<\/p><\/dd>\n No. It means the page is intentionally excluded from caching, which is correct behaviour for carts, checkouts, account pages and anything personalised. Add those to the skip list to keep them out of future runs.<\/p><\/dd>\n Yes. Any public post type is warmable. On WooCommerce, add *<\/code> as a wildcard, useful for carts, checkouts and account pages that should never be cached anyway.<\/p>\n\nAbout images<\/h4>\n\n
Free forever<\/h4>\n\n
\n
\/wp-content\/plugins\/<\/code>, or install it through the Plugins screen.<\/li>\n\n
Does this replace my caching plugin?<\/h3><\/dt>\n
Do I need to leave the page open?<\/h3><\/dt>\n
Can it warm on a schedule?<\/h3><\/dt>\n
Does it warm automatically when I clear my cache?<\/h3><\/dt>\n
add_filter( 'abcw_purge_hooks', function ( $hooks ) { $hooks[] = 'my_cache_cleared'; return $hooks; } );\n<\/code><\/pre><\/dd>\nCan I see what was warmed after the fact?<\/h3><\/dt>\n
What happens when only one page is cleared?<\/h3><\/dt>\n
What stops it warming over and over?<\/h3><\/dt>\n
abcw_auto_cooldown<\/code>.<\/p><\/dd>\nWhat happens if my server rate limits the warmer?<\/h3><\/dt>\n
Will this inflate my analytics?<\/h3><\/dt>\n
DNT: 1<\/code> header, which privacy-respecting analytics plugins already honour, and an X-ABCode-Cache-Warmer<\/code> header that log tooling can exclude on. The abcw_request_headers<\/code> filter adjusts them.<\/p><\/dd>\nWill this slow my site down?<\/h3><\/dt>\n
Is a repeat run as expensive as the first?<\/h3><\/dt>\n
Why is SSL verification off by default?<\/h3><\/dt>\n
Should I warm my images?<\/h3><\/dt>\n
Some URLs report \"No cache\", is that a problem?<\/h3><\/dt>\n
Does it work with a page builder \/ WooCommerce \/ multisite?<\/h3><\/dt>\n
\/cart\/<\/code>, \/checkout\/<\/code> and \/my-account\/*<\/code> to the skip list. On multisite, each site has its own settings and runs independently.<\/p><\/dd>\n\n<\/dl>\n\n\n1.1.0<\/h4>\n\n
\n
abcw_internal_post_types<\/code> \/ abcw_internal_taxonomies<\/code> filters adjust the exclusions.<\/li>\n.\/<\/code> or doubled slashes warmed the same page twice under two different addresses.<\/li>\nDNT: 1<\/code> and an X-ABCode-Cache-Warmer<\/code> header, so server-side analytics can filter them out. JavaScript analytics such as Google Analytics never saw them anyway.<\/li>\nabcw_purge_hooks<\/code>, abcw_purge_post_hooks<\/code>, abcw_auto_cooldown<\/code>, abcw_load_steps<\/code>, abcw_internal_post_types<\/code>, abcw_internal_taxonomies<\/code> and abcw_request_headers<\/code> filters.<\/li>\n1.0.0<\/h4>\n\n
\n