Le cache d’objets de WordPress est souvent réduit, dans les discussions entre développeurs, à « brancher Redis et c’est réglé ». La réalité est plus subtile : l’API WP_Object_Cache qui sert d’interface entre le cœur et le backend externe (Redis, Memcached ou autre) repose sur des notions de groupes et de clés qui, mal comprises, provoquent des bugs difficiles à reproduire, en particulier sur un multisite.
Cet article ne couvre pas l’installation de Redis elle-même, largement documentée ailleurs, mais se concentre sur ce que l’API de cache fait réellement en interne, ce qui permet d’éviter les pièges les plus fréquents une fois le backend en place.
Ce qu’est un groupe de cache
Chaque appel à wp_cache_get() ou wp_cache_set() prend un paramètre de groupe, qui sert d’espace de noms logique. Le cœur de WordPress utilise des groupes prédéfinis comme options, posts, terms ou users, ce qui permet d’invalider sélectivement un groupe entier sans toucher aux autres, via wp_cache_flush_group() sur les backends qui le supportent.
wp_cache_set( 'options', $data, 'options' );
wp_cache_get( 'options', 'options' );Groupes non persistants : la distinction qui change tout
Certains groupes sont volontairement déclarés « non persistants » via wp_cache_add_non_persistent_groups(). Concrètement, ces groupes restent uniquement en mémoire PHP pour la durée de la requête en cours et ne sont jamais écrits dans le backend externe, même si un plugin de cache d’objets persistant est actif.
wp_cache_add_non_persistent_groups( array( 'counts', 'plugins' ) );C’est un choix délibéré du cœur pour des données qui changent trop souvent ou qui n’ont de sens que dans le contexte d’une seule requête, comme certains compteurs temporaires. L’erreur classique consiste à croire qu’un plugin de cache d’objets mal configuré « ignore » certaines données, alors qu’il respecte simplement une déclaration explicite de non-persistance faite par le cœur ou une extension. Avant de chercher un bug côté Redis, il vaut mieux vérifier la liste des groupes non persistants déclarés par wp_cache_get_non_persistent_groups().
Le piège des collisions de clés en multisite
Sur une installation multisite, plusieurs sites partagent la même instance Redis ou Memcached. Sans mécanisme de séparation, deux sites pourraient techniquement écrire sous la même clé de cache et se voler mutuellement des données. WordPress résout ce problème par un préfixage automatique de la clé avec l’identifiant du site (blog_id), géré par la classe WP_Object_Cache du plugin de cache d’objets utilisé.
Le piège apparaît quand un développeur appelle directement l’API du backend (par exemple le client Redis en PHP) en contournant l’API wp_cache_* de WordPress, pour gagner en performance ou en simplicité. Dans ce cas, le préfixage automatique par site n’est plus appliqué, et deux sites du réseau peuvent se retrouver à lire ou écraser la même clé, avec des effets de bord aléatoires selon l’ordre des requêtes.
Notre règle sur les projets multisite : aucun accès direct au client Redis en dehors de l’API
wp_cache_*, même pour un gain de performance apparent. Le préfixage par site n’est jamais négociable.
Réduire les allers-retours avec wp_cache_get_multiple
Quand un bloc de code a besoin de plusieurs clés de cache dans le même groupe, appeler wp_cache_get() en boucle multiplie les allers-retours réseau vers Redis ou Memcached, chacun coûtant en moyenne entre 0,3 et 1 milliseconde selon la latence réseau. La fonction wp_cache_get_multiple(), disponible depuis WordPress 5.5, regroupe ces lectures en un seul appel au backend :
$cache_keys = array( 101, 102, 103 );
$results = wp_cache_get_multiple( $cache_keys, 'posts' );Sur une page qui affiche vingt articles avec leurs métadonnées mises en cache individuellement, remplacer une boucle de vingt appels par un seul wp_cache_get_multiple() a réduit, sur l’un de nos projets, le temps passé côté cache d’objets d’environ 14 ms à 2 ms par génération de page.
Ce qu’il faut retenir
Le cache d’objets de WordPress n’est pas une simple clé-valeur transparente : les groupes non persistants, le préfixage automatique par site en multisite et les fonctions de lecture groupée font partie intégrante de son fonctionnement interne. Ignorer ces mécanismes conduit soit à des données qui semblent ne jamais se mettre en cache, soit, plus grave, à des fuites de données entre sites d’un même réseau. Passer systématiquement par l’API officielle wp_cache_*, jamais par un accès direct au backend, reste la garantie la plus simple d’éviter ces pièges.
