Un appel HTTP vers un service tiers qui échoue une première fois échouera très probablement une seconde fois, quelques secondes plus tard, dans les mêmes conditions. C’est un constat presque trivial, et pourtant de nombreuses extensions continuent d’appeler une API externe à chaque affichage de page, même quand cette API vient de répondre une erreur l’instant d’avant sur la requête précédente.
Ce comportement devient un vrai problème de performance dès qu’un service tiers connaît une interruption prolongée : chaque visiteur du site déclenche un nouvel appel, qui attend le délai d’expiration configuré avant d’échouer, ralentissant l’affichage de la page pour tout le monde. Un cache négatif simple corrige cette situation sans complexité excessive.
Le comportement par défaut, et pourquoi il coûte cher
Prenons une extension qui affiche un taux de change en direct récupéré via une API externe, sur la fiche d’un produit vendu en devise étrangère. Sans précaution particulière, chaque affichage de la fiche produit déclenche un nouvel appel HTTP.
function recuperer_taux_change() {
$reponse = wp_remote_get( 'https://api.taux-change.example/derniere-valeur' );
if ( is_wp_error( $reponse ) ) {
return null;
}
return json_decode( wp_remote_retrieve_body( $reponse ), true );
}Si l’API distante devient indisponible pendant dix minutes, chaque visiteur de chaque fiche produit pendant cette période déclenche un appel qui attend son délai d’expiration avant d’échouer. Sur un site à fort trafic, cela représente potentiellement des centaines d’appels bloquants pour un résultat toujours identique : l’échec.
Mettre en place un cache négatif avec les transients
Le principe est simple : quand un appel échoue, on mémorise cet échec dans un transient de courte durée. Tant que ce transient existe, on ne retente pas l’appel : on retourne directement une valeur de repli, ou null, sans solliciter le réseau.
function recuperer_taux_change() {
if ( get_transient( 'taux_change_echec_recent' ) ) {
return null; // on n'insiste pas, l'échec est encore frais
}
$reponse = wp_remote_get( 'https://api.taux-change.example/derniere-valeur' );
if ( is_wp_error( $reponse ) || 200 !== wp_remote_retrieve_response_code( $reponse ) ) {
set_transient( 'taux_change_echec_recent', true, 90 ); // fenêtre de cache négatif
return null;
}
return json_decode( wp_remote_retrieve_body( $reponse ), true );
}La fenêtre de 90 secondes n’a rien d’universel : elle dépend du profil de trafic du site et de la tolérance de l’affichage à une donnée légèrement obsolète. Pour un taux de change consulté ponctuellement, quelques minutes de cache négatif sont largement acceptables. Pour une donnée plus critique, une fenêtre plus courte, de l’ordre de dix à vingt secondes, limite les tentatives sans pour autant masquer trop longtemps une éventuelle reprise du service.
Distinguer le cache négatif du cache positif classique
Il est tentant de fusionner cache positif et cache négatif dans un seul transient, mais les deux répondent à des besoins différents. Le cache positif mémorise une valeur valide pour éviter un appel redondant. Le cache négatif mémorise l’absence de valeur pour éviter un appel voué à l’échec. Les confondre complique le code sans bénéfice réel, et rend plus difficile le réglage indépendant de chaque durée.
- Utiliser deux clés de transient distinctes, une pour le cache positif, une pour le cache négatif.
- Choisir une durée de cache négatif nettement plus courte que celle du cache positif.
- Ne jamais afficher le cache négatif comme une donnée valide : préférer masquer l’élément plutôt qu’afficher une valeur par défaut trompeuse.
Ce que ce mécanisme ne remplace pas
Un cache négatif n’est pas un disjoncteur applicatif complet. Il ne distingue pas les types d’échec, ne remonte aucune alerte à l’équipe technique, et ne s’adapte pas automatiquement à la fréquence des pannes. Il se contente d’éviter la répétition immédiate d’un appel qui vient d’échouer, pendant une fenêtre fixe et courte. Pour un mécanisme plus sophistiqué, capable d’ouvrir et de refermer un circuit selon un taux d’échec observé, une solution dédiée reste nécessaire.
Un cas limite à surveiller
Si l’appel échoue systématiquement, par exemple à cause d’une clé d’API expirée, le cache négatif se recharge indéfiniment toutes les 90 secondes, sans jamais alerter personne du problème sous-jacent. Il est donc utile de coupler ce mécanisme à un compteur d’échecs consécutifs, journalisé, pour qu’une panne prolongée finisse par être remarquée plutôt que silencieusement absorbée.
Un cache négatif bien réglé protège la performance du site pendant une panne courte ; il ne dispense jamais de surveiller activement les appels externes critiques.
En résumé
Ce mécanisme reste volontairement modeste : quelques lignes autour d’un get_transient() et d’un set_transient() suffisent à éviter qu’une panne d’un service tiers ne se traduise par des centaines d’appels HTTP inutiles à chaque affichage de page. C’est un premier filet de protection, simple à mettre en œuvre, avant d’envisager une architecture de résilience plus complète.
