Une extension de personnalisation de contenu calcule, pour chaque visiteur, un identifiant de segment marketing à partir de son comportement de navigation en cours de session : pages vues, produits consultés, référent d’entrée sur le site. Ce calcul est mis en cache via l’API objet de WordPress avec une clé qui inclut l’identifiant de session, dans le but d’éviter de le recalculer plusieurs fois au cours d’une même requête si plusieurs blocs de la page en ont besoin.
Sur un hébergement avec un cache d’objet persistant configuré, comme Redis, un problème est apparu après quelques semaines : la mémoire du serveur Redis augmentait de façon continue, sans jamais se stabiliser, jusqu’à nécessiter un redémarrage manuel du service. La cause : ces données de segment, par nature uniques à chaque session et sans intérêt au-delà de la requête en cours, s’accumulaient indéfiniment dans le cache persistant partagé, faute d’expiration explicite suffisamment courte et faute d’un signalement à WordPress de leur nature réellement éphémère.
Ce que change WordPress 6.1
Sortie en novembre 2022, WordPress 6.1 introduit la fonction wp_cache_add_non_persistent_groups(), qui permet à une extension de déclarer explicitement qu’un groupe de cache donné ne doit jamais être transmis à un backend de cache persistant, même si un tel backend est configuré sur le site. Les données de ce groupe restent alors cantonnées à la mémoire du processus PHP en cours, exactement comme le comportement par défaut de l’API objet sur une installation sans cache persistant du tout.
Comment fonctionne ce mécanisme
add_action( 'init', function() {
wp_cache_add_non_persistent_groups( array( 'segment_visiteur_temporaire' ) );
} );
function obtenir_segment_visiteur( string $session_id ) {
$cle = 'segment_' . $session_id;
$segment = wp_cache_get( $cle, 'segment_visiteur_temporaire' );
if ( false !== $segment ) {
return $segment;
}
$segment = calculer_segment_depuis_comportement( $session_id );
wp_cache_set( $cle, $segment, 'segment_visiteur_temporaire' );
return $segment;
}
Le groupe segment_visiteur_temporaire reste utile à l’intérieur d’une même requête, par exemple si trois widgets différents demandent le même segment pour le même visiteur au cours du rendu d’une seule page, évitant ainsi trois calculs identiques. Mais grâce à la déclaration explicite, ce groupe n’est jamais transmis à Redis ou Memcached : il disparaît naturellement à la fin de chaque requête PHP, sans jamais s’accumuler côté serveur de cache partagé.
Pourquoi ne pas simplement raccourcir la durée d’expiration
On pourrait penser qu’un TTL très court, de quelques secondes, résoudrait le même problème sans passer par cette fonction. Mais cette approche reste imparfaite pour deux raisons. D’abord, sur un site à fort trafic, même une expiration de dix secondes laisse le temps à des dizaines de milliers de clés uniques par session de transiter par le serveur de cache persistant avant leur expiration effective, ce qui alourdit inutilement sa charge réseau et mémoire à un instant donné. Ensuite, un groupe déclaré non persistant communique clairement l’intention au reste de l’équipe : cette donnée n’a jamais vocation à être partagée entre processus, ce qui est une information architecturale différente d’une simple question de durée de vie.
Où placer cette déclaration
Il est important d’appeler wp_cache_add_non_persistent_groups() suffisamment tôt dans le cycle de chargement, avant toute utilisation du groupe concerné, et idéalement à chaque requête plutôt qu’une seule fois de façon persistante, car cette information n’est elle-même jamais stockée en base : elle doit être redéclarée systématiquement, ce qui justifie de l’accrocher à un hook fiable et précoce comme init plutôt qu’à un hook tardif qui pourrait s’exécuter après une première tentative d’écriture dans le groupe.
Cas d’usage typiques pour ce mécanisme
- Des données de session ou de panier temporaires, propres à un visiteur et sans valeur au-delà de sa requête courante.
- Des résultats de calcul intermédiaires utilisés uniquement pour éviter une répétition de traitement au sein d’une même page.
- Des données de débogage ou de traçage qu’une extension accumule pendant le rendu, à afficher en pied de page en mode développement.
Un cache d’objet persistant n’est pas une poubelle infinie : tout ce qui n’a pas vocation à être partagé entre visiteurs n’a rien à y faire.
Compatibilité et repli
Pour une extension qui doit rester compatible avec des versions de WordPress antérieures à 6.1, il suffit de vérifier l’existence de la fonction avant de l’appeler, avec function_exists( 'wp_cache_add_non_persistent_groups' ), cette fonction existant en réalité depuis longtemps dans l’API objet mais n’ayant jamais été officiellement documentée dans le manuel des fonctions avant cette version, ce qui explique qu’elle soit restée largement méconnue jusque-là malgré sa disponibilité technique antérieure.
En résumé
Déclarer explicitement les groupes de cache réellement temporaires comme non persistants évite qu’un backend de cache d’objet partagé ne se remplisse silencieusement de données qui n’ont aucune valeur au-delà d’une seule requête. Ce mécanisme, désormais officiellement documenté depuis WordPress 6.1, mérite d’être systématiquement envisagé dès qu’une extension manipule des données de session ou des résultats de calcul propres à un visiteur unique.
