WP Rocket's built-in preloader and CacheBoost both warm your cache, but at different scopes: WP Rocket preloads one WordPress install, from one location, for a limited set of user-agents, while CacheBoost is an external service that warms any stack from multiple regions and user-agents, on triggers you control. For most WordPress sites they complement each other rather than compete. Here's an honest breakdown of where each one fits.
WP Rocket's preloader: what it does
WP Rocket includes a built-in cache preloader that visits your pages after a cache flush, simulating a real browser request to fill the cache before visitors arrive. It's enabled by default and works well for most basic setups.
The preloader is triggered:
- After a full cache flush
- When the configured cache lifespan expires and clears the cache
- After a post is saved or updated
For a small blog or informational site, this is often sufficient. The cache stays warm, and most visitors see cached pages.
Where WP Rocket preloading has limits
WP Rocket's preloader makes certain architectural choices that matter at scale:
Limited user-agents: The preloader warms the desktop cache and, when "Separate Cache for Mobile Devices" is enabled, the mobile variant too (it sends a second request with a mobile user-agent). What it won't warm is cache variants for crawler user-agents like Googlebot or GPTBot, or any custom user-agent your setup depends on.
Single region: Requests originate from your own server or a fixed IP. If you're using a CDN like Cloudflare with regional edge caching, only the edge node geographically closest to your server gets warmed. Visitors in other regions get CDN misses and hit the origin cold.
No remote trigger: The preloader runs on WordPress events. You can fire it server-side from a deploy script with the WP-CLI extension (wp rocket preload), but there's no HTTP/REST endpoint to trigger it remotely from a GitHub Action, a webhook, or an external monitoring system. And if your cache is flushed by a server-side process that bypasses WordPress, the preloader doesn't know.
Concurrency limits: The preloader is intentionally conservative to avoid overloading shared hosting environments. On larger sites (1,000+ pages), a full preload can take 20–30 minutes.
No run history: There's no log of when preloads ran, how many URLs were covered, or whether any failed. Debugging a "why was the site slow at 2pm?" question is difficult.
Where CacheBoost goes further
CacheBoost is designed around the limitations above:
| Feature | WP Rocket preloader | CacheBoost |
|---|---|---|
| User-agent variants | Desktop + mobile | Desktop, mobile, Googlebot, GPTBot, custom |
| Regions | Single (local) | France, USA, Europe, Asia |
| External trigger | WP-CLI only (no HTTP) | REST API |
| Concurrency control | Fixed (conservative) | Configurable per boost |
| Run history & logs | No | Full run history with URL counts and errors |
| Email reports | No | Per-run email reports |
| CI/CD integration | No | GitHub Actions, any HTTP client |
Do you need both?
For most sites, yes: they complement each other rather than compete.
WP Rocket's preloader handles the WordPress-native events: post saves, scheduled cache clears, WP Rocket's own flush triggers. It runs inside WordPress and has direct access to the event system.
CacheBoost handles what WP Rocket can't: multi-region warming, crawler and custom user-agent variants, remote deploy-triggered runs over HTTP, and sites with external cache flush mechanisms (Varnish, Cloudflare page rules, custom scripts).
A typical combined setup:
- WP Rocket preloader: handles real-time per-post warming after content updates
- CacheBoost (nightly): full sitemap warm from multiple regions and user-agents
- CacheBoost (on deploy): triggered via GitHub Actions after code deployments
When CacheBoost alone makes sense
If you're not using WP Rocket, or if you're running a non-WordPress site with Varnish, Redis, or a custom cache layer, CacheBoost covers the full warming surface without any WordPress dependency.
The CacheBoost WordPress plugin and API work regardless of which cache plugin you use. The plugin auto-detects WP Rocket, W3 Total Cache, LiteSpeed Cache, and WP Super Cache, but it also works on sites with no cache plugin at all, simply by warming via HTTP requests to your sitemap URLs.
