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.

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.

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.

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. 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.

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.

Yes. Any public post type is warmable. On WooCommerce, add /cart/, /checkout/ and /my-account/* to the skip list. On multisite, each site has its own settings and runs independently.