Un site associatif listant plus de mille adhérents professionnels affichait, pour chaque fiche, un champ ACF secondaire indiquant si l’adhérent participait à l’événement annuel de l’association. Une simple case à cocher, modifiée une dizaine de fois par semaine par l’équipe d’administration. Le problème : la configuration du plugin de cache en place déclenchait une purge complète du cache de page à chaque sauvegarde d’un article, quel que soit le champ modifié.
Sur un site de mille deux cents pages, cette purge complète signifiait que la prochaine visite sur n’importe laquelle de ces pages devait régénérer entièrement son contenu, y compris des pages totalement indépendantes de l’adhérent modifié. Aux heures de forte affluence, cette purge répétée provoquait des pics de charge visibles sur le serveur.
Comprendre pourquoi la purge était aussi large
La configuration par défaut du plugin de cache écoutait le hook générique save_post, déclenché à chaque sauvegarde de contenu, sans distinction du type de contenu ni du champ réellement modifié. Ce réglage, pensé pour être universellement sûr sans configuration fine, sacrifiait la précision au profit de la simplicité, un compromis raisonnable pour un petit site mais coûteux ici.
Cibler la purge avec les hooks ACF
ACF propose un hook plus spécifique, acf/save_post, déclenché après la sauvegarde des champs personnalisés d’un article, avec accès à l’identifiant de l’article concerné. Combiné à une vérification du champ réellement modifié, ce hook a permis de construire une purge ciblée, ne touchant que les URL réellement affectées par le changement :
add_action( 'acf/save_post', function ( $post_id ) {
if ( ! is_numeric( $post_id ) ) {
return;
}
if ( get_post_type( $post_id ) !== 'adherent' ) {
return;
}
// Purge uniquement la fiche de l'adhérent et la page d'annuaire qui le liste.
monplugin_purger_url( get_permalink( $post_id ) );
monplugin_purger_url( get_permalink( get_option( 'page_annuaire_adherents' ) ) );
}, 20 );La priorité 20 sur ce hook garantit que l’exécution se fait après que le plugin de cache générique a lui-même terminé son propre traitement sur save_post, le désactivant explicitement en amont pour ce type de contenu précis, via un filtre propre au plugin de cache utilisé sur ce projet.
Aller plus loin : ne purger que si le champ pertinent a changé
Une optimisation supplémentaire a consisté à comparer l’ancienne et la nouvelle valeur du champ avant de déclencher la purge, pour éviter une régénération même ciblée quand un administrateur sauvegarde une fiche sans réellement modifier le champ de participation à l’événement :
add_action( 'acf/save_post', function ( $post_id ) {
if ( get_post_type( $post_id ) !== 'adherent' ) {
return;
}
static $anciennes_valeurs = array();
$ancienne = $anciennes_valeurs[ $post_id ] ?? get_field( 'participe_evenement', $post_id );
$nouvelle = $_POST['acf']['field_participe_evenement'] ?? null;
if ( $ancienne !== $nouvelle ) {
monplugin_purger_url( get_permalink( $post_id ) );
monplugin_purger_url( get_permalink( get_option( 'page_annuaire_adherents' ) ) );
}
}, 5 );Cette vérification a nécessité de capturer la valeur ancienne avant la sauvegarde effective, via un hook antérieur, acf/save_post s’exécutant lui-même une fois avant et une fois après l’enregistrement selon la priorité choisie, un détail qui a demandé quelques essais avant d’obtenir le comportement exact recherché.
Les gains mesurés
- Nombre de pages purgées par modification : de 1 200 en moyenne à 2, la fiche concernée et la page d’annuaire.
- Disparition des pics de charge CPU précédemment observés lors des sauvegardes en série par l’équipe d’administration.
- Temps de sauvegarde d’une fiche dans l’administration légèrement réduit, la purge complète bloquant auparavant une partie du traitement.
En résumé
Une purge de cache trop large, souvent héritée d’une configuration par défaut universelle, peut coûter cher sur un site de taille moyenne dès que les modifications de contenu sont fréquentes. Les hooks spécifiques d’ACF permettent de restreindre précisément la purge aux seules URL réellement affectées, sans dépendre d’une extension de cache tierce plus sophistiquée.
