Le même graphique de suivi de performance, ouvert deux jours de suite, montrait des temps de génération allant de 210 à 1 100 millisecondes pour la même page d’accueil, sans corrélation avec l’heure de la journée ni avec le nombre de visiteurs simultanés. Cette variabilité, plus difficile à expliquer qu’une lenteur constante, a orienté l’enquête vers un composant dont le comportement dépendrait d’un facteur externe au serveur lui-même.
Le site, celui d’une coopérative agricole vendant une partie de sa production à l’export, affichait en pied de page un petit widget indiquant le taux de change entre l’euro et trois devises partenaires. Écrit plusieurs années auparavant par un prestataire depuis longtemps parti, ce widget n’avait jamais fait l’objet d’un audit de performance, probablement parce qu’il semblait trop anodin pour mériter l’attention.
Isoler le composant responsable
L’onglet requêtes HTTP externes de Query Monitor a rapidement montré la cause : chaque chargement de page déclenchait un appel à wp_remote_get() vers une API publique de taux de change, sans aucune mise en cache :
function wpm_widget_taux_de_change() {
$reponse = wp_remote_get( 'https://api.exemple-taux.test/v1/latest?base=EUR' );
if ( is_wp_error( $reponse ) ) {
return '';
}
$donnees = json_decode( wp_remote_retrieve_body( $reponse ), true );
return sprintf(
'1 € = %s $ = %s £',
esc_html( $donnees['rates']['USD'] ),
esc_html( $donnees['rates']['GBP'] )
);
}
add_action( 'wp_footer', function () {
echo wpm_widget_taux_de_change();
} );Le temps de réponse de cette API externe variait selon sa propre charge, sa localisation géographique et la qualité de la connexion au moment de l’appel : parfois 80 millisecondes, parfois plus d’une seconde, expliquant à lui seul l’essentiel de la variabilité observée dans les mesures de temps de génération.
Pourquoi ce genre d’appel est particulièrement traître
Un appel réseau externe bloquant, exécuté en synchrone dans le rendu d’une page, met le processus PHP en attente jusqu’à ce que le serveur distant réponde, ou jusqu’au délai d’expiration défini. Sans limite explicite, wp_remote_get() applique un délai par défaut de cinq secondes : en cas de lenteur ou d’indisponibilité de l’API distante, chaque visiteur du site aurait pu attendre jusqu’à cinq secondes avant de voir la moindre ligne de la page, l’appel étant placé dans wp_footer mais exécuté avant l’envoi complet de la réponse au navigateur.
Le correctif : un transient à courte durée
Un taux de change n’a pas besoin d’être recalculé à chaque visite : une actualisation toutes les quinze minutes suffit largement pour un usage informatif en pied de page. La fonction get_transient() et set_transient() ont permis de mettre en cache la réponse :
function wpm_widget_taux_de_change() {
$cle = 'wpm_taux_de_change';
$donnees = get_transient( $cle );
if ( false === $donnees ) {
$reponse = wp_remote_get( 'https://api.exemple-taux.test/v1/latest?base=EUR', array(
'timeout' => 3,
) );
if ( is_wp_error( $reponse ) ) {
return '';
}
$donnees = json_decode( wp_remote_retrieve_body( $reponse ), true );
set_transient( $cle, $donnees, 15 * MINUTE_IN_SECONDS );
}
return sprintf(
'1 € = %s $ = %s £',
esc_html( $donnees['rates']['USD'] ),
esc_html( $donnees['rates']['GBP'] )
);
}Avec ce changement, un seul visiteur sur des centaines paie le coût de l’appel réseau toutes les quinze minutes ; tous les autres lisent une valeur déjà stockée dans la base, restituée en quelques millisecondes grâce au cache d’objets si celui-ci est actif.
Ce qu’il restait à vérifier
- Réduire le délai d’expiration de la requête à trois secondes, pour éviter qu’une API distante en panne ne bloque un visiteur pendant les cinq secondes par défaut.
- Prévoir une valeur de repli en cas d’échec de l’appel, plutôt que de renvoyer une chaîne vide qui masque silencieusement le problème.
- Vérifier qu’aucun autre widget hérité du même prestataire ne reproduisait le même schéma ailleurs sur le site.
Un appel externe sans cache ne ralentit pas le site de façon constante : il le rend imprévisible, ce qui est souvent plus difficile à diagnostiquer qu’une lenteur régulière.
En résumé
Le composant le plus anodin du site — un simple indicateur de taux de change en pied de page — était responsable de la variabilité observée dans les temps de génération. Un transient de quinze minutes a suffi à transformer un appel réseau bloquant en lecture locale quasi instantanée, sans changer une ligne de la logique d’affichage.
