# WP Rocket et Cloudflare APO ensemble : la tempête de purges croisées > Publier un article déclenchait deux purges complètes de cache coup sur coup, l'une par WP Rocket, l'autre par Cloudflare APO, chacune ignorant l'existence de l'autre. - Auteur : WordPress Développement - Publié le : 2021-05-02 - Mis à jour le : 2021-05-02 - Catégorie : Performance - URL : https://www.wpmoderne.fr/performance/wp-rocket-cloudflare-apo-purges-croisees/ ## L’essentiel - Deux couches de cache qui ne se parlent pas purgent deux fois pour rien - Chaque purge totale relance une charge MySQL évitable - Répartir les rôles évite la tempête de purges Ce qu'on observe : chaque publication d'article sur ce site déclenche, en l'espace de quelques secondes, deux purges de cache complètes et indépendantes. La première vient de WP Rocket, qui vide son cache de page local dès qu'un contenu est modifié. La seconde vient de Cloudflare APO (Automatic Platform Optimization), qui reçoit sa propre notification de changement de contenu et purge à son tour l'intégralité du cache edge, sans savoir que WP Rocket vient déjà d'agir. Le résultat visible côté visiteurs : les premières requêtes qui suivent chaque publication tombent systématiquement sur un cache froid, à la fois côté serveur et côté edge Cloudflare, ce qui multiplie les pages générées dynamiquement au moment précis où le trafic peut affluer (partage sur les réseaux, notification aux abonnés). ## Pourquoi c'est un problème, en particulier pour MySQL Une purge de cache de page complète signifie que la prochaine requête sur chaque URL du site doit régénérer la page depuis zéro : exécution de `WP_Query`, hooks de thème, éventuels appels à des API externes. Sur ce site, avec plusieurs milliers de pages indexées, une purge totale suivie d'un pic de trafic se traduit par une rafale de requêtes MySQL simultanées, alors que le cache objet lui-même reste froid pour les mêmes clés que le cache de page vient de vider. Le fait que la purge se déclenche deux fois, à quelques secondes d'intervalle, aggrave le problème : la charge MySQL provoquée par la première vague de régénération n'a pas encore redescendu que la seconde purge relance une nouvelle vague de requêtes sur des pages qui venaient tout juste d'être remises en cache. > L'essentiel à retenir : Deux couches de cache qui ne se parlent pas purgent deux fois pour rien ; Chaque purge totale relance une charge MySQL évitable ; Répartir les rôles évite la tempête de purges ## Ce qu'on voit dans les journaux serveur Le pic de charge MySQL, visible dans les journaux `slow query log`, coïncide exactement avec les deux appels de purge journalisés côté WP Rocket (`rocket_clean_domain`) et côté Cloudflare (webhook `zone.cache_purge` visible dans l'historique d'activité API du compte Cloudflare). Sur une publication en heure de forte affluence, ce double pic a provoqué une saturation temporaire du pool PHP-FPM, avec plusieurs requêtes rejetées faute de worker disponible. ## Pourquoi c'est un problème d'architecture, pas de réglage Le problème ne vient pas d'un mauvais réglage isolé, mais du fait que les deux extensions ont été installées avec leurs comportements par défaut, chacune ignorant la présence de l'autre. WP Rocket ne sait pas que Cloudflare APO existe sur ce compte, et Cloudflare APO ne sait pas que WP Rocket gère déjà un cache de page côté serveur. Les deux couches font consciencieusement leur travail, en double, sans coordination. ## Quoi faire : répartir qui purge quoi La correction consiste à définir clairement une hiérarchie entre les deux caches plutôt que de les laisser agir en parallèle : - Désactiver la purge automatique de Cloudflare APO sur les événements de publication de contenu, en la laissant gérée exclusivement par WP Rocket via son intégration Cloudflare native (présente dans les réglages de l'extension). - Configurer WP Rocket pour qu'il purge d'abord son propre cache local, puis déclenche lui-même, via son API d'intégration, la purge Cloudflare correspondant uniquement aux URL modifiées plutôt qu'une purge totale. - Réserver la purge totale Cloudflare aux cas exceptionnels (changement de thème, mise à jour majeure), déclenchée manuellement plutôt qu'automatiquement à chaque publication. ``` // Dans WP Rocket : Réglages → Cloudflare // Activer "Purge Cloudflare en même temps que WP Rocket" // Désactiver côté Cloudflare : Speed → Optimization → Automatic Platform // Optimization → décocher la purge automatique liée au contenu ``` ## Ce qu'on constate après correction Après ce changement, une seule purge se déclenche par publication, ciblée sur les URL réellement modifiées (l'article lui-même, la page d'accueil, les archives de catégorie concernées) plutôt que l'intégralité du site. Le pic de charge MySQL observé lors des publications a disparu des journaux, remplacé par une régénération progressive limitée aux pages effectivement visitées. > Deux caches superposés sans hiérarchie claire ne s'additionnent pas : ils se marchent dessus, et c'est la base de données qui encaisse la facture. ## En résumé Faire cohabiter WP Rocket et Cloudflare APO sans définir qui a la responsabilité de purger quoi conduit à des purges croisées redondantes, coûteuses en charge MySQL au pire moment (juste après une publication, quand le trafic afflue). La solution ne consiste pas à retirer l'une des deux couches, mais à établir une hiérarchie explicite : une purge locale précise déclenche une purge edge ciblée, jamais l'inverse, et jamais les deux en parallèle sans coordination.