內容簡介
ABCode Cache Warmer 是一款專為 WordPress 設計的快取預熱和快取重建外掛。它在每次清除快取後自動重建頁面快取，確保訪客不會遇到冷快取頁面，提升網站的加載速度和使用體驗。
【主要功能】
• 自動重建快取，避免冷快取頁面
• 支援多種快取外掛和主機快取
• 同時請求多個 URL，加速快取過程
• 根據伺服器性能自動調整請求速度
• 提供快取預熱成功的實時反饋
外掛標籤
開發者團隊
原文外掛簡介
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.
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.
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.
Built to be fast
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.
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.
It measures your server instead of guessing
There is no one-size-fits-all crawl speed. A VPS can take eight concurrent requests without noticing; cheap shared hosting cannot.
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.
It tells you whether it actually worked
Other warmers report HTTP 200 and call it a success. A 200 tells you the page loaded, not that it got cached.
This plugin reads the cache headers on every response and reports what really happened for each URL:
Warmed: the page was not cached, and now it is
Cached: it was already warm, nothing to do
No cache: the page is deliberately uncacheable, such as a cart or checkout
Failed: shown with the actual error
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.
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.
Choose what gets warmed
Homepage
Posts, pages and any public custom post type, all on by default
Post type archives such as /products/ or /portfolio/, plus your blog page
Category, tag and custom taxonomy archives
Attachment pages
Images referenced by the pages being warmed
Your XML sitemap, core, Yoast or Rank Math
Any extra URLs you add by hand
Warmed in the order that matters
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.
On a site structured as /accommodation/ → /accommodation/cottages/ → /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.
You can also skip URLs by pattern, with * as a wildcard, useful for carts, checkouts and account pages that should never be cached anyway.
About images
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.
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.
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.
Free forever
No URL limits. No locked features. No upsells. The whole plugin does the whole job.
Who made this
ABCode builds and maintains this plugin. If your site needs more than a warm cache, we also do WordPress speed optimisation as a service. The plugin stays free and complete either way.
