Recalculer la même information à chaque visite gaspille des ressources serveur inutilement ; WordPress conserve donc en mémoire, le temps d’une requête HTTP au minimum, tout résultat coûteux déjà obtenu.
Fonctionnement dans WordPress
L’API du cache d’objets repose sur wp_cache_get(), wp_cache_set() et wp_cache_delete(), organisées par groupes (options, posts, terms…). Par défaut, ce cache est non persistant : il vit uniquement pendant l’exécution du script PHP et disparaît à la fin de la requête. Pour qu’il survive entre deux visiteurs, il faut un cache persistant externe — Redis ou Memcached — activé via un fichier object-cache.php déposé dans wp-content/.
Exemple
$data = wp_cache_get( 'stats_auteur_42', 'mon_plugin' );
if ( false === $data ) {
$data = calcul_couteux_des_stats( 42 );
wp_cache_set( 'stats_auteur_42', $data, 'mon_plugin', 300 );
}Bon à savoir
- Sans plugin d’objet persistant, chaque visiteur relance les mêmes requêtes SQL : le cache d’objets par défaut n’accélère rien d’une visite à l’autre.
- À ne pas confondre avec un transitoire, qui persiste en base de données même sans cache persistant, ou avec un cache de page, qui stocke le HTML final déjà généré.
- Le module OPcache, lui, met en cache le bytecode PHP compilé plutôt que des données applicatives : les trois mécanismes sont complémentaires et résolvent des problèmes de performance différents.
Bon à savoir
Un plugin qui écrit dans le cache d’objets sans préfixer ses clés risque des collisions avec d’autres extensions ; utiliser un groupe de cache dédié, passé en second argument, isole proprement ses propres données du reste du site.