POST /zones/{zone_id}/purge_cache : cet appel unique à l’API Cloudflare peut soit vider l’intégralité du cache CDN d’un site, soit n’invalider que les ressources explicitement concernées par une modification, selon les paramètres envoyés dans le corps de la requête. Sur un site à fort trafic dont le cache Cloudflare sert des dizaines de milliers de pages, une purge totale déclenchée à chaque publication d’article génère un pic de charge brutal sur le serveur d’origine : toutes les pages doivent être régénérées presque simultanément, au moment précis où les visiteurs continuent d’affluer normalement.
Le cache par tag (« cache tags »), disponible sur les offres Cloudflare Business et Enterprise, permet une approche bien plus ciblée : associer à chaque ressource mise en cache une ou plusieurs étiquettes (l’ID de l’article, la catégorie, l’auteur), puis purger uniquement les ressources porteuses d’une étiquette précise. Publier un article ne doit invalider que les pages qui l’affichent réellement — sa propre page, l’archive de sa catégorie, la page d’accueil si elle affiche les derniers articles — sans toucher au reste du cache.
Associer des tags aux réponses HTTP
La première étape consiste à envoyer l’en-tête Cache-Tag depuis WordPress à chaque réponse HTTP, listant les étiquettes pertinentes pour la page servie :
add_action( 'template_redirect', function () {
if ( is_singular( 'post' ) ) {
$post_id = get_the_ID();
$tags = [ "article-{$post_id}" ];
foreach ( get_the_category( $post_id ) as $categorie ) {
$tags[] = "categorie-{$categorie->term_id}";
}
header( 'Cache-Tag: ' . implode( ',', $tags ) );
}
} );
Cloudflare associe ensuite chaque ressource mise en cache aux tags présents dans cet en-tête au moment de la mise en cache initiale. C’est cette association qui permet, plus tard, une purge ciblée sans devoir connaître à l’avance la liste exacte des URLs concernées.
Déclencher la purge au bon moment
La purge doit se déclencher sur le hook save_post, mais uniquement pour les transitions de statut pertinentes (publication, mise à jour d’un article déjà publié), afin d’éviter des appels API inutiles à chaque enregistrement de brouillon :
add_action( 'transition_post_status', function ( $nouveau, $ancien, $post ) {
if ( 'post' !== $post->post_type ) {
return;
}
if ( 'publish' !== $nouveau ) {
return;
}
wp_remote_post( "https://api.cloudflare.com/client/v4/zones/{$zone_id}/purge_cache", [
'headers' => [
'Authorization' => 'Bearer ' . CLOUDFLARE_API_TOKEN,
'Content-Type' => 'application/json',
],
'body' => wp_json_encode( [
'tags' => [ "article-{$post->ID}" ],
] ),
'timeout' => 5,
] );
}, 10, 3 );
Le paramètre timeout volontairement court évite qu’une lenteur ponctuelle de l’API Cloudflare ne ralentisse perceptiblement l’action de publication pour l’utilisateur qui clique sur le bouton dans l’administration.
Rendre l’appel réellement asynchrone
Même avec un timeout court, un appel wp_remote_post synchrone bloque l’exécution jusqu’à sa résolution ou son échec. Sur un projet où la fiabilité de la purge était secondaire par rapport à la rapidité perçue de publication, le paramètre blocking a permis de détacher totalement l’appel :
'blocking' => false,
Cette option envoie la requête sans attendre de réponse, ce qui convient parfaitement à une purge de cache où un échec silencieux occasionnel (rare) est largement préférable à un ralentissement systématique de la publication.
Gérer les échecs sans bloquer l’éditeur
- Consigner les échecs de purge dans un journal dédié plutôt que d’afficher une erreur bloquante à l’auteur de l’article.
- Prévoir une purge de secours planifiée (toutes les heures, via Action Scheduler) qui rattrape les échecs silencieux accumulés.
- Ne jamais faire dépendre la publication elle-même du succès de l’appel API Cloudflare.
Les limites de cette approche
Le cache par tag suppose un plan Cloudflare qui le propose, ce qui exclut les offres gratuites et Pro. Sur ces offres plus limitées, la purge par URL individuelle (files plutôt que tags dans le corps de la requête) reste possible, mais impose de construire soi-même la liste exacte des URLs à invalider, une logique plus fragile à maintenir dans la durée.
Une purge de cache mal calibrée coûte cher deux fois : trop large, elle surcharge le serveur d’origine ; trop étroite, elle laisse une page obsolète visible aux visiteurs. Le cache par tag est la seule approche qui évite ce compromis frustrant.
En résumé
Purger l’intégralité du cache Cloudflare à chaque publication d’article est une solution qui fonctionne à petite échelle mais devient coûteuse sur un site à fort trafic. Associer des tags précis à chaque ressource via l’en-tête Cache-Tag, puis déclencher une purge ciblée et non bloquante depuis transition_post_status, permet d’invalider exactement ce qui doit l’être, sans jamais ralentir l’expérience de publication côté administration.
