Le préchargeur intégré de WP Rocket et CacheBoost préchauffent tous deux votre cache, mais à des échelles différentes : WP Rocket précharge une seule installation WordPress, depuis un seul emplacement, avec un jeu limité de user-agents, tandis que CacheBoost est un service externe qui préchauffe n'importe quelle stack depuis plusieurs régions et user-agents, sur des déclencheurs que vous contrôlez. Pour la plupart des sites WordPress, ils se complètent plus qu'ils ne se concurrencent. Voici un décryptage honnête du rôle de chacun.
Le préchargeur de WP Rocket : ce qu'il fait
WP Rocket inclut un préchargeur de cache intégré qui visite vos pages après un vidage du cache, en simulant une requête de navigateur réelle pour remplir le cache avant l'arrivée des visiteurs. Il est activé par défaut et fonctionne bien pour la plupart des configurations basiques.
Le préchargeur se déclenche :
- Après un vidage complet du cache
- À l'expiration de la durée de vie du cache configurée, qui vide le cache
- Après l'enregistrement ou la mise à jour d'un article
Pour un petit blog ou un site informatif, c'est souvent suffisant. Le cache reste chaud, et la plupart des visiteurs voient des pages en cache.
Les limites du préchargement WP Rocket
Le préchargeur de WP Rocket fait certains choix d'architecture qui comptent à grande échelle :
User-agents limités : le préchargeur remplit le cache desktop et, quand « Cache séparé pour les appareils mobiles » est activé, la variante mobile aussi (il envoie une seconde requête avec un user-agent mobile). Ce qu'il ne préchauffe pas, ce sont les variantes de cache pour les user-agents de crawlers comme Googlebot ou GPTBot, ni aucun user-agent personnalisé dont dépend votre configuration.
Une seule région : les requêtes proviennent de votre propre serveur ou d'une IP fixe. Si vous utilisez un CDN comme Cloudflare avec un cache edge régional, seul le nœud edge géographiquement le plus proche de votre serveur est préchauffé. Les visiteurs des autres régions subissent des miss CDN et atteignent l'origine à froid.
Pas de déclenchement distant : le préchargeur s'exécute sur des événements WordPress. Vous pouvez le lancer côté serveur depuis un script de déploiement grâce à l'extension WP-CLI (wp rocket preload), mais il n'existe aucun point d'accès HTTP/REST pour le déclencher à distance depuis une GitHub Action, un webhook ou un système de monitoring externe. Et si votre cache est vidé par un processus côté serveur qui contourne WordPress, le préchargeur ne le sait pas.
Limites de concurrence : le préchargeur est volontairement conservateur pour ne pas surcharger les hébergements mutualisés. Sur les sites plus grands (1 000+ pages), un préchargement complet peut prendre 20 à 30 minutes.
Pas d'historique d'exécution : il n'existe aucun journal indiquant quand les préchargements ont eu lieu, combien d'URLs ont été couvertes, ni si certaines ont échoué. Déboguer un « pourquoi le site était-il lent à 14h ? » devient difficile.
Là où CacheBoost va plus loin
CacheBoost est conçu autour des limites ci-dessus :
| Fonctionnalité | Préchargeur WP Rocket | CacheBoost |
|---|---|---|
| Variantes de user-agent | Desktop + mobile | Desktop, mobile, Googlebot, GPTBot, personnalisé |
| Régions | Une seule (locale) | France, USA, Europe, Asie |
| Déclenchement externe | WP-CLI uniquement (pas de HTTP) | API REST |
| Contrôle de la concurrence | Fixe (conservateur) | Configurable par boost |
| Historique et journaux | Non | Historique complet avec décomptes d'URLs et erreurs |
| Rapports par e-mail | Non | Rapport e-mail à chaque exécution |
| Intégration CI/CD | Non | GitHub Actions, n'importe quel client HTTP |
Avez-vous besoin des deux ?
Pour la plupart des sites, oui : ils se complètent plutôt qu'ils ne se concurrencent.
Le préchargeur de WP Rocket gère les événements natifs WordPress : enregistrements d'articles, vidages de cache planifiés, déclencheurs de purge propres à WP Rocket. Il s'exécute à l'intérieur de WordPress et a un accès direct au système d'événements.
CacheBoost gère ce que WP Rocket ne peut pas : le préchauffage multi-régions, les variantes de user-agent crawler et personnalisées, les exécutions déclenchées à distance au déploiement via HTTP, et les sites dont le cache est vidé par des mécanismes externes (Varnish, règles de pages Cloudflare, scripts personnalisés).
Une configuration combinée typique :
- Préchargeur WP Rocket : gère le préchauffage par article en temps réel après les mises à jour de contenu
- CacheBoost (nocturne) : préchauffage complet du sitemap depuis plusieurs régions et user-agents
- CacheBoost (au déploiement) : déclenché via GitHub Actions après les déploiements de code
Quand CacheBoost seul a du sens
Si vous n'utilisez pas WP Rocket, ou si vous gérez un site non-WordPress avec Varnish, Redis ou une couche de cache personnalisée, CacheBoost couvre toute la surface de préchauffage sans aucune dépendance à WordPress.
Le plugin WordPress CacheBoost et l'API fonctionnent quel que soit votre plugin de cache. Le plugin détecte automatiquement WP Rocket, W3 Total Cache, LiteSpeed Cache et WP Super Cache, mais il fonctionne aussi sur des sites sans aucun plugin de cache, simplement en préchauffant via des requêtes HTTP vers les URLs de votre sitemap.
