« Transients are used to store cached data temporarily by giving it a custom name and a timeframe after which it will expire and be deleted » — la documentation officielle de WordPress résume ainsi l’API des transients : un mécanisme pour stocker une donnée calculée, sous un nom choisi, avec une durée de vie après laquelle elle disparaît d’elle-même.
Avant de songer à Redis ou Memcached, beaucoup de sites gagneraient à exploiter pleinement cette API native, disponible sans aucune extension, aussi bien pour de petits sites sur hébergement mutualisé que pour des projets plus ambitieux en attendant un cache d’objets persistant.
Ce qu’est réellement un transient
Un transient combine deux éléments : une valeur, stockée comme une option WordPress classique, et une échéance, stockée dans une seconde option nommée avec un préfixe _transient_timeout_. Sans cache d’objets persistant installé, les deux vivent dans la table wp_options, comme n’importe quel réglage du site. Avec un cache d’objets persistant, WordPress bascule automatiquement le stockage vers ce cache, sans que le code appelant ait à changer une seule ligne.
Cette double nature explique pourquoi les transients restent utiles même sur un hébergement basique : ils profitent du cache d’objets non persistant de la requête en cours, et surtout, la table wp_options elle-même bénéficie généralement d’un cache au niveau de la base de données pour les options les plus consultées.
Fonctionnement interne : lecture et écriture
L’utilisation courante suit toujours le même schéma : tenter une lecture, et si elle échoue, recalculer puis stocker.
function site_get_avis_moyens_produits() {
$cle = 'avis_moyens_produits';
$moyennes = get_transient( $cle );
if ( false === $moyennes ) {
$moyennes = site_calculer_avis_moyens(); // requête coûteuse
set_transient( $cle, $moyennes, 6 * HOUR_IN_SECONDS );
}
return $moyennes;
}
Le test doit toujours porter sur false === $moyennes et non sur une simple négation, car une valeur mise en cache peut légitimement être un tableau vide, une chaîne vide ou le nombre zéro, que PHP considère comme faux dans un test classique.
Cas d’usage typiques
- Un calcul agrégé coûteux, comme une moyenne d’avis ou un total de ventes sur une période glissante.
- Le résultat d’un appel à un service externe dont la réponse ne change pas à chaque requête.
- Une liste de suggestions ou de contenus liés, recalculée périodiquement plutôt qu’à chaque affichage.
À l’inverse, les transients ne conviennent pas à des données propres à chaque visiteur, comme un panier ou une session : leur portée est globale au site, pas individuelle.
Les pièges les plus fréquents
Le premier piège consiste à multiplier les transients sans jamais les purger explicitement, en laissant WordPress s’appuyer uniquement sur l’expiration. Sur un site avec un fort volume de contenu variable, cela peut faire grossir la table wp_options de manière notable si l’expiration choisie est trop longue.
Le second piège tient à la longueur des clés : une clé de transient est limitée à 172 caractères depuis les versions récentes de WordPress, une contrainte qui surprend quand on construit dynamiquement des clés à partir de plusieurs identifiants concaténés.
Un transient bien choisi ne remplace pas un cache d’objets persistant, mais il en règle souvent 80 % de l’utilité avec zéro configuration serveur.
Un mot sur la suppression explicite
Au-delà de l’expiration automatique, la fonction delete_transient() permet de forcer la suppression d’un transient devenu obsolète avant même l’échéance prévue, typiquement après une action utilisateur qui invalide le calcul mis en cache. C’est le complément indispensable de set_transient() dès qu’un transient dépend d’un contenu susceptible d’être modifié en dehors du cycle d’expiration normal, par exemple après la publication d’un nouvel avis client venant changer une moyenne déjà calculée.
Une confusion fréquente consiste à croire qu’un transient garantit sa présence jusqu’à l’échéance fixée. Sans cache d’objets persistant, WordPress purge parfois les transients avant leur terme lors d’une opération de nettoyage de la table wp_options, en particulier sur un site où cette table a fortement grossi. Le code appelant doit donc toujours prévoir le cas où get_transient() renvoie false plus tôt que prévu, sans en faire une anomalie bloquante.
En résumé
get_transient() et set_transient() forment une API simple, native, capable de fluidifier un site sans aucune dépendance externe. Sur un site sans cache d’objets persistant, ils restent la première réponse à un calcul coûteux répété, et sur un site qui en dispose déjà, ils continuent de fonctionner exactement de la même façon, mais avec de meilleures performances de lecture.
