Certains calculs — un appel à une API externe, une agrégation de statistiques — sont trop coûteux pour être refaits à chaque affichage de page, mais leur résultat n’a pas besoin de durer indéfiniment non plus ; il faut un cache à durée de vie limitée.
Fonctionnement dans WordPress
L’API des transitoires s’utilise avec set_transient(), get_transient() et delete_transient(). Sans cache d’objets persistant actif, un transitoire est simplement stocké dans wp_options, accompagné d’une option jumelle qui note sa date d’expiration ; avec un cache persistant comme Redis, WordPress bascule automatiquement vers ce cache plus rapide, sans changement de code nécessaire.
Exemple
$donnees = get_transient( 'meteo_paris' );
if ( false === $donnees ) {
$donnees = appel_api_meteo();
set_transient( 'meteo_paris', $donnees, HOUR_IN_SECONDS );
}Pièges fréquents
La date d’expiration indique quand une donnée devient invalide, pas quand elle sera effectivement supprimée : WordPress ne nettoie ces entrées périmées que lorsqu’elles sont redemandées ou via une tâche planifiée dédiée, ce qui peut laisser des entrées obsolètes s’accumuler en base sur un site rarement visité.
Bon à savoir
Passer une durée d’expiration à 0 crée un transitoire sans limite de temps théorique, mais WordPress ne garantit alors aucune persistance réelle : sans cache persistant, l’entrée peut malgré tout être supprimée à tout moment lors d’un nettoyage automatique de la table wp_options.
Les transitoires spécifiques à un site en Multisite existent aussi sous forme réseau, avec set_site_transient() et get_site_transient(), utilisés notamment par le cœur de WordPress pour mettre en cache les vérifications de mise à jour des extensions et des thèmes.