Pourquoi mesurer le TTFB par gabarit plutôt qu'en moyenne ?

Un site affiche un temps de réponse serveur moyen de quatre cents millisecondes, ce qui paraît honorable, et pourtant ses fiches produit mettent près de deux secondes à commencer à répondre. Le chiffre moyen n'est pas faux, il est simplement inutilisable : il additionne quelques milliers de pages servies depuis un cache en trente millisecondes et quelques centaines de pages générées intégralement, puis divise le tout. Aucune décision technique ne peut sortir d'un nombre pareil. La seule mesure qui permette d'agir consiste à relever le temps de réponse gabarit par gabarit, en séparant les pages selon la façon dont elles sont produites, ce qui demande une demi journée de mise en place et rend visibles des écarts que personne ne soupçonnait.

Pourquoi la moyenne ne dit rien

Le problème n'est pas la métrique elle même, qui est parfaitement pertinente, mais son agrégation sur des populations de pages hétérogènes. Ce point rejoint les difficultés de lecture que nous évoquons régulièrement dans la rubrique référencement naturel à propos des indicateurs de performance.

Un chiffre unique pour des pages incomparables

Une page d'accueil statique, une fiche produit interrogeant un stock en temps réel et une page de résultats de recherche interne n'ont rien de commun dans leur mode de production. La première sort d'un cache, la deuxième déclenche un appel réseau vers un système externe, la troisième exécute une requête coûteuse sur une base entière. Les agréger revient à calculer la vitesse moyenne d'un parc automobile comprenant des vélos et des camions : le résultat existe, il ne décrit aucun véhicule réel et ne permet de décider de rien.

L'effet du cache sur la moyenne

Sur un site correctement mis en cache, quatre vingt dix pour cent des réponses sont servies en quelques dizaines de millisecondes. Ces réponses tirent la moyenne si bas que les pages lentes deviennent invisibles, même lorsqu'elles représentent une part significative du chiffre d'affaires. Pire, une amélioration du cache fait baisser la moyenne sans que la moindre page lente n'ait été corrigée, ce qui produit un rapport de performance flatteur et une expérience utilisateur inchangée sur les parcours qui comptent réellement.

Les robots ne parcourent pas les mêmes pages

Un moteur de recherche explore massivement des pages d'archive, de pagination et de filtres que les visiteurs humains n'atteignent presque jamais. Ce sont souvent les plus lentes, puisqu'elles ne bénéficient d'aucun cache faute de trafic. Le budget d'exploration se consomme alors sur les pages les plus coûteuses à produire, ce qui ralentit la découverte des contenus nouveaux. La moyenne, dominée par les pages populaires et rapides, ne montre rien de cette mécanique pourtant déterminante pour l'indexation. L'analyse des journaux du serveur permet de le vérifier en quelques minutes : il suffit de comparer le temps de traitement moyen des requêtes provenant des robots à celui des requêtes provenant des navigateurs, et l'écart dépasse souvent un facteur trois sur les sites à catalogue.

La moyenne masque la queue de distribution

Ce qui dégrade l'expérience n'est pas le comportement médian mais les cinq pour cent de réponses les plus lentes, celles qui provoquent un abandon. Une moyenne stable peut parfaitement recouvrir une dégradation nette de cette queue de distribution, par exemple lorsqu'un appel externe commence à répondre irrégulièrement. Seuls les percentiles élevés rendent ce phénomène visible, et ils doivent être calculés sur des populations de pages homogènes pour signifier quelque chose.

Ce que le temps de réponse influence réellement

Le temps de réponse serveur conditionne tout ce qui suit : aucun élément visuel ne peut apparaître avant que la première donnée ne soit reçue. Il pèse donc directement sur les indicateurs d'expérience mesurés par les moteurs, et il constitue le plancher incompressible du chargement. Optimiser des images sur une page qui met une seconde et demie à répondre relève de l'ordre inverse, et c'est pourtant l'ordre habituellement suivi, parce que l'optimisation des images est plus simple à mettre en œuvre. Il faut ajouter que le temps de réponse serveur est la seule composante du chargement entièrement sous contrôle de celui qui exploite le site, les autres dépendant du terminal, du réseau et du navigateur du visiteur.

Découper la mesure par gabarit

La méthode tient en une idée simple : constituer un échantillon d'adresses représentatives, une par gabarit, et les mesurer toujours de la même façon. Ce découpage complète utilement la lecture des Core Web Vitals dans la Search Console, qui agrège de son côté par groupes d'adresses.

Identifier les gabarits qui comptent

Un site classique en compte entre six et douze : accueil, page de contenu, liste de catégorie, fiche produit, résultats de recherche, panier, compte, page de contact, archive par date, page d'auteur. Le recensement se fait à partir des fichiers de gabarits du thème plutôt qu'à partir de l'arborescence, puisque c'est le gabarit qui détermine le coût de production. Deux adresses de rubriques différentes utilisant le même fichier n'ont aucune raison d'être mesurées séparément. À l'inverse, un même gabarit servant des contenus de volumétrie très différente mérite deux adresses témoins, une petite et une grande, l'écart entre les deux indiquant si le coût croît avec la quantité de données affichées.

Une adresse témoin par gabarit

Pour chaque gabarit, on retient une adresse représentative et stable, qui ne sera ni supprimée ni profondément modifiée. L'adresse témoin doit correspondre à un cas moyen et non à un cas extrême : une fiche produit avec un nombre habituel de variantes, une catégorie avec un nombre habituel d'articles. Cette liste, écrite une fois dans un fichier, constitue la base de tout le dispositif et doit être versionnée au même titre que le code du site.

Distinguer page en cache et page générée

Chaque adresse doit être mesurée deux fois : une fois telle qu'elle est servie normalement, une fois en contournant le cache. La première mesure décrit ce que vit un visiteur ordinaire, la seconde le coût réel de production, qui est celui que subissent le premier visiteur après une purge et le robot d'exploration. L'écart entre les deux valeurs est l'information la plus utile de tout le relevé, puisqu'il indique exactement combien le cache masque de dette technique. Un rapport de un à trente entre les deux valeurs n'a rien d'anormal en soi, mais il signifie que toute purge de cache, toute mise en production et toute exploration soutenue exposeront brutalement le coût réel de génération.

Mesurer connecté et non connecté

Sur une boutique ou un site à espace membre, les pages vues par un utilisateur connecté échappent presque toujours au cache. Un panier ou un tableau de bord client peut donc être dix fois plus lent que la page publique correspondante, alors même qu'il se situe au cœur du parcours d'achat. Ce cas doit figurer explicitement dans le relevé, avec une session authentifiée dédiée, faute de quoi la partie la plus critique du site reste entièrement hors mesure.

Retenir la médiane et un percentile élevé

Une mesure isolée ne vaut rien, la variabilité d'un serveur étant considérable. Il faut au minimum dix relevés par adresse, dont on retient la médiane et le quatre vingt quinzième percentile. La médiane décrit le comportement habituel, le percentile décrit ce que subissent les visiteurs malchanceux. Un gabarit dont la médiane est bonne et le percentile mauvais souffre d'un problème intermittent, généralement un appel externe ou une contention sur la base de données. Ce profil se distingue nettement d'un gabarit uniformément lent, dont la cause est structurelle et se corrige dans le code, alors qu'un problème intermittent se corrige d'abord par un délai maximal et une stratégie de repli.

Choisir un point de mesure stable

Mesurer depuis un poste de travail introduit la latence du réseau local et celle du fournisseur d'accès, qui varient d'une heure à l'autre. La mesure doit partir d'une machine fixe, idéalement hébergée dans la même région que les visiteurs, et toujours la même. Ce qui compte n'est pas la valeur absolue mais sa comparabilité dans le temps, et un point de mesure changeant rend toute la série inexploitable, y compris rétroactivement.

Lire les écarts entre gabarits

Une fois le tableau rempli, les problèmes se désignent eux mêmes. Chaque profil d'écart correspond à une famille de causes assez restreinte, ce qui rend le diagnostic rapide.

La liste de catégorie qui dérive

Un gabarit de liste dont le temps de génération augmente avec le nombre de contenus trahit presque toujours une requête effectuée à l'intérieur de la boucle d'affichage, une par élément listé. Le symptôme caractéristique est une croissance linéaire avec le nombre d'éléments par page. La correction consiste à préparer les données en une seule requête avant la boucle, ce qui divise fréquemment le temps par cinq sans toucher à l'affichage. Le second suspect, sur une boutique, est le calcul du prix affiché lorsqu'il dépend de promotions, de quantités disponibles ou de règles de taxation évaluées produit par produit.

La fiche produit et ses appels externes

Une fiche produit lente alors que le reste du site est rapide signale un appel synchrone vers un système tiers : stock, tarification, disponibilité en magasin, avis clients. Ces appels doivent être rendus asynchrones ou mis en cache avec une durée courte, et surtout dotés d'un délai maximal court. Sans délai maximal, une lenteur passagère du système distant se transforme en indisponibilité de la boutique entière, scénario que nous rencontrons plusieurs fois par an.

La recherche interne

La recherche native de WordPress s'appuie sur une comparaison textuelle qui n'utilise aucun index et parcourt l'intégralité de la table des contenus. Sur quelques centaines d'articles, personne ne s'en aperçoit. Au delà de quelques milliers, chaque recherche devient une opération lourde, et une poignée de robots suffit à saturer la base. Le passage à un index dédié est alors la seule solution durable, et il se justifie économiquement dès que la recherche interne participe aux conversions.

Les pages d'archive à faible trafic

Ces pages ne sont jamais en cache, précisément parce que personne ne les visite, et elles sont pourtant explorées régulièrement. Leur lenteur consomme du budget d'exploration au détriment des contenus utiles. Deux réponses existent selon leur valeur réelle : les rendre non indexables lorsqu'elles n'apportent rien, ou les optimiser au même titre que les autres lorsqu'elles servent la navigation. Ne rien décider revient à financer l'exploration de pages sans intérêt.

Le panier et le compte client

Ces gabarits échappent au cache par nature et concentrent une part importante des traitements applicatifs. Un temps de réponse élevé y pèse directement sur le taux de finalisation, sans qu'aucun indicateur agrégé ne le montre puisque le volume de pages concernées reste faible. Leur optimisation passe par la réduction du nombre de requêtes et par la mise en cache des fragments réellement partagés entre utilisateurs, ce qui demande une analyse fine mais rapporte immédiatement.

Mettre en place un suivi durable

Une mesure ponctuelle donne un diagnostic, un suivi régulier donne un moyen de détecter les régressions avant qu'elles ne deviennent des incidents.

Automatiser le relevé

Un script d'une trentaine de lignes parcourt la liste des adresses témoins, effectue les relevés en séparant les appels avec et sans cache, et écrit les résultats horodatés dans un fichier. Exécuté chaque nuit, il produit en quelques semaines une série exploitable qui rend visible toute dérive progressive. Ce dispositif ne demande aucun outil commercial et fonctionne indifféremment depuis un serveur ou depuis une machine de supervision. Le format d'enregistrement le plus pratique reste une ligne par relevé, avec la date, le gabarit, le mode et la valeur, ce qui se dépouille ensuite dans n'importe quel tableur sans traitement particulier.

Comparer avant et après chaque déploiement

La valeur du suivi apparaît au moment d'une mise en production. Un relevé effectué juste avant et juste après le déploiement attribue immédiatement une régression à sa cause, alors que la même régression découverte trois semaines plus tard demandera plusieurs heures de recherche. Cette comparaison mérite de figurer dans la procédure de mise en production, au même titre que la vérification des pages principales et le contrôle des adresses de redirection.

Croiser avec les données de terrain

Les mesures synthétiques décrivent un serveur, les données collectées auprès des visiteurs réels décrivent une expérience. Les deux sont nécessaires et ne se substituent pas : une mesure synthétique excellente coexiste parfois avec des données de terrain médiocres, généralement parce que la population réelle se connecte depuis des réseaux mobiles ou depuis une région éloignée du serveur. Le croisement des deux sources oriente vers la bonne famille de solutions.

Fixer un seuil par gabarit

Un seuil unique appliqué à tous les gabarits produit soit des alertes permanentes sur les pages naturellement coûteuses, soit aucune alerte sur les pages qui devraient être instantanées. Chaque gabarit doit avoir son propre seuil, défini à partir de sa valeur habituelle majorée d'une marge, et l'alerte doit se déclencher sur un écart relatif plutôt que sur une valeur absolue. C'est la seule façon d'obtenir des alertes que l'on prend encore au sérieux au bout de six mois.

Traiter la cause plutôt que le symptôme

La tentation, devant un gabarit lent, consiste à le mettre en cache plus agressivement. C'est parfois la bonne réponse, mais cela revient souvent à masquer une requête défectueuse qui ressortira au premier contournement du cache, par exemple lors d'une exploration massive. La règle raisonnable consiste à mesurer d'abord le coût de génération réel, à le corriger si possible, et à considérer le cache comme une optimisation ajoutée par dessus un socle déjà sain. La configuration du gestionnaire de processus décrite dans notre article sur la manière de configurer PHP-FPM pour un trafic modéré constitue une partie de ce socle.

Documenter ce qui a été mesuré

La liste des adresses témoins, la méthode de contournement du cache, le point de mesure et les seuils retenus doivent tenir dans une note courte conservée avec le projet. Sans elle, la série de mesures perd sa comparabilité dès qu'une autre personne reprend le dispositif, et l'ensemble du travail est à refaire. Cette note tient en une page et détermine si le suivi survivra ou non au départ de celui qui l'a mis en place. Elle doit aussi mentionner les changements d'infrastructure survenus pendant la période observée, un changement de serveur ou de fournisseur de base de données créant une rupture dans la série qu'il faut savoir interpréter plutôt que confondre avec une régression applicative. Consigner ces changements d'infrastructure dans le même document que les mesures évite d'attribuer à une régression de code ce qui relève d'un déménagement de serveur.