« Pourquoi la page d’accueil met-elle plus d’une seconde à répondre alors que le cache de page semble actif ? » C’est la question posée par l’exploitant d’un domaine skiable après avoir constaté, via un outil de supervision externe, un temps de réponse serveur régulièrement supérieur à 1 400 millisecondes sur sa page d’accueil, malgré une configuration de cache pourtant vérifiée comme fonctionnelle.
La page affichait, en plus des informations habituelles sur les pistes ouvertes et les remontées mécaniques, un encart météo en temps réel indiquant la température et l’enneigement au sommet du domaine, actualisé via un shortcode personnalisé développé en interne quelques mois plus tôt.
Symptôme : un TTFB stable mais élevé
Le temps de réponse restait constamment élevé, sans pic ni variation liée à la charge du serveur, ce qui excluait d’emblée un problème de saturation. Ce comportement stable, quelle que soit l’heure de la mesure, orientait plutôt vers un traitement systématique et bloquant exécuté à chaque affichage, indépendant du trafic.
Diagnostic : le cache de page contournait la mise en cache habituelle
L’inspection de la configuration a révélé que la page d’accueil portait une exclusion de cache volontaire, ajoutée quelques mois auparavant pour une raison sans rapport avec la météo, jamais retirée depuis. Chaque visite déclenchait donc une génération complète de la page, shortcode météo compris.
Le shortcode lui-même effectuait un appel HTTP synchrone vers une API météo externe à chaque exécution, via wp_remote_get(), sans aucune mise en cache du résultat. Le temps de réponse de cette API, mesuré séparément, oscillait entre 900 et 1 300 millisecondes selon les conditions réseau, expliquant à lui seul l’essentiel du TTFB constaté sur la page.
Correctif : un transient à durée courte
La donnée météo n’a pas besoin d’être actualisée à chaque affichage : une fraîcheur de quelques minutes reste largement suffisante pour ce type d’information. Le correctif a consisté à envelopper l’appel API dans un transient, avec relecture systématique de la valeur en cache avant tout nouvel appel réseau.
<?php
function domaine_recuperer_meteo() {
$meteo = get_transient( 'meteo_sommet_domaine' );
if ( false === $meteo ) {
$reponse = wp_remote_get( 'https://api-meteo-exemple.fr/sommet' );
if ( ! is_wp_error( $reponse ) ) {
$meteo = json_decode( wp_remote_retrieve_body( $reponse ), true );
set_transient( 'meteo_sommet_domaine', $meteo, 10 * MINUTE_IN_SECONDS );
}
}
return $meteo;
}
Avec ce transient de dix minutes, l’appel réseau ne se produit plus qu’une fois toutes les dix minutes au maximum, quel que soit le nombre de visiteurs entre deux rafraîchissements, la quasi-totalité des visites lisant désormais une valeur déjà en cache.
Résultat mesuré
Le TTFB moyen de la page d’accueil est tombé à environ 180 millisecondes après déploiement du correctif, hors les rares visites qui déclenchent effectivement un nouvel appel réseau. L’exclusion de cache de page initiale, elle, a également été retirée après vérification qu’elle ne servait plus aucun besoin réel, ce qui a permis de servir la page directement depuis le cache pour la quasi-totalité des visiteurs.
Prévention : fixer un budget d’appels externes par page
- Toute intégration future d’un service externe doit prévoir dès le départ une mise en cache adaptée à la fraîcheur réellement nécessaire de la donnée
- Un budget maximal d’appels réseau bloquants par page, fixé en revue de code, évite l’accumulation silencieuse de plusieurs shortcodes du même type au fil des évolutions du site
- Une exclusion de cache de page doit toujours porter une date et une raison documentées, pour éviter qu’elle ne survive au besoin qui l’a justifiée
Un appel réseau synchrone sans cache reste tolérable tant qu’il est seul. Le vrai risque, c’est l’accumulation silencieuse de plusieurs appels de ce type au fil des évolutions successives d’un même site.
En résumé
Un shortcode qui interroge une API externe sans mise en cache peut, à lui seul, dégrader le temps de réponse d’une page entière, surtout si cette page échappe par ailleurs au cache global du site. Le transient reste l’outil le plus simple pour absorber ce type de dépendance externe, à condition de choisir une durée de fraîcheur cohérente avec le besoin réel de l’information affichée.
