by
Ash Brentnall | ABCode
1 (1 reviews)
ABCode Cache Warmer
Automatic cache warmer and preloader: rebuilds your page cache after every purge, in parallel, and shows exactly which URLs were cached.
ABCode Cache Warmer ranks #26,083 among WordPress.org plugins with 1+ active installations, is #890 of 1,518 in the Performance category, a 1/5 rating from 1 reviews, and was last updated Aug 4, 2026. Data from WordPress.org, refreshed twice daily — see methodology.
Tested up to WP 7 (Current: 7.1)
v1.1.0
Current Version v1.1.0
Updated 1 month ago
Last Update on 04 Aug, 2026
Refreshed 9 hours ago
Last Refreshed on
#890 of 1,518 in Performance
Rank
#26,083
—
No change
Active Installs
1+
-75%
KW Avg Position
66.3
—
No change
Downloads
289
+11 today
Support Resolved
0%
—
No change
Rating
20%
Review 1 out of 5
1
(1 reviews)
Next Milestone 10
0+
10+
25,370
Ranks to Climb
-
Growth Needed
8,000,000
Active Installs
Pro
Unlock Exact Install Count
See the precise estimated active installs for this plugin, calculated from real-time ranking data.
- Exact install estimates within tiers
- Track install growth over time
- Milestone progress predictions
Need 3 more installs to reach 10+
Rank Changes
Current
#26,083
Change
Best
#
Downloads Growth
Downloads
Growth
Peak
Upgrade to Pro
Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.
Upgrade NowReviews & Ratings
1.0
1 reviews
Overall
20%
5
1
(100%)
4
0
(0%)
3
0
(0%)
2
0
(0%)
1
0
(0%)
Track This Plugin
Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.
Start Tracking FreePlugin Details
- Version
- 1.1.0
- Last Updated
- Aug 04, 2026
- Requires WP
- 5.6+
- Tested Up To
- 7
- PHP Version
- 7.4 or higher
- Author
- Ash Brentnall | ABCode
Support & Rating
- Rating
- ★ ☆ ☆ ☆ ☆ 1
- Reviews
- 1
- Support Threads
- 0
- Resolved
- 0%
Keywords
Upgrade to Pro
Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.
Upgrade NowSimilar Plugins
Adminify – White Label, Admin Menu Editor, Login Customizer
6K+ installs
#2,752
Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits
30K+ installs
#1,007
LiteSpeed Cache
7M+ installs
#5
Wordfence Security - Firewall, Malware Scan, and Login Security
5M+ installs
#11
Hostinger Tools
3M+ installs
#20
WP Super Cache
1M+ installs
#38
Speed Optimizer - The All-In-One Performance-Boosting Plugin
1M+ installs
#43
WP Fastest Cache - WordPress Cache Plugin
1M+ installs
#47
WP-Optimize – Cache, Compress images, Minify & Clean database to boost page speed & performance
1M+ installs
#52
Maintenance
1M+ installs
#57
Frequently Asked Questions
Common questions about ABCode Cache Warmer
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.
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. 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.
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. 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.
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. 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. 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. 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. Using something else? Any cache that fires an action when it clears can be wired in with one line: add_filter( 'abcw_purge_hooks', function ( $hooks ) { $hooks[] = 'my_cache_cleared'; return $hooks; } );
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. 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.
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. 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. 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.
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 abcw_auto_cooldown.
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.
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. 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 DNT: 1 header, which privacy-respecting analytics plugins already honour, and an X-ABCode-Cache-Warmer header that log tooling can exclude on. The abcw_request_headers filter adjusts them.
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. 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. 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. 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.
