Temps jusqu'au premier octet (TTFB)

Le temps de réponse du serveur (TTFB) mesure l'intervalle entre la requête d'une ressource par un navigateur et la réception du premier octet de la réponse. Il agrège plusieurs phases distinctes : les redirections, la résolution DNS, l'établissement de la connexion, la négociation TLS, la requête elle-même et le temps de traitement du serveur avant sa réponse. Comme tout le reste du chargement de la page dépend de la réception de cette réponse, le TTFB constitue un seuil minimal pour toutes les autres métriques de chargement.

Sa valeur diagnostique provient de sa position dans la séquence. Une page dont le chargement du contenu le plus long est lent, mais dont le premier octet est rapide, présente un problème côté client, lié à la livraison des ressources, au rendu ou au blocage des ressources. La même page, avec un premier octet lent, présente un problème côté serveur ou réseau ; aucune optimisation d'image ni aucun report de script ne pourra le résoudre, car le navigateur n'a encore reçu aucune donnée. Déterminer la cause du problème est la première étape de toute analyse de performance sérieuse.

Les causes en cause se répartissent en deux catégories : réseau et serveur. Côté réseau, la distance géographique entre le visiteur et le serveur d'origine engendre une latence inévitable, les chaînes de redirection ajoutent un aller-retour complet chacune, et la négociation de connexion et TLS ajoutent des allers-retours supplémentaires pour les nouvelles connexions. Côté serveur, les causes habituelles sont : un code applicatif lent, des requêtes de base de données non indexées ou inefficaces, des appels à des services externes effectués de manière synchrone pendant la requête, une mise en cache absente ou inefficace, et la contention des ressources sur un hébergement mutualisé.

Les solutions varient en conséquence. Les réseaux de diffusion de contenu (CDN) gèrent la distance en servant les requêtes depuis des serveurs proches du visiteur et peuvent fournir des réponses mises en cache entièrement en périphérie, sans contacter le serveur d'origine. La mise en cache à plusieurs niveaux (page entière, fragments, objets et requêtes de base de données) élimine les tâches répétitives. La suppression des chaînes de redirection permet d'éviter des allers-retours complets, ce qui représente souvent l'amélioration la plus significative sur les sites utilisant des structures d'URL anciennes. Les protocoles modernes et la réutilisation des connexions réduisent la surcharge liée à la négociation. Côté application, l'optimisation des requêtes et le déplacement des tâches non essentielles hors du chemin de requête optimisent le fonctionnement du serveur.

Les mesures doivent faire la distinction entre les réponses mises en cache et celles qui ne le sont pas, ainsi qu'entre les premières visites et les visites répétées, car ces différences peuvent être considérables et une moyenne les masque. Les données de terrain segmentées par zone géographique et type de connexion sont plus informatives qu'un chiffre unique, car un site affichant des chiffres globaux acceptables peut présenter des performances très médiocres sur un marché donné. Effectuer les tests depuis l'emplacement d'hébergement du site, ce qui est généralement le cas par défaut, sous-estime systématiquement l'expérience des visiteurs distants.

Le taux d'accès au cache est l'indicateur le plus pertinent pour analyser cette métrique sur un site web protégé par un réseau de diffusion de contenu (CDN). Or, il est souvent faible pour des raisons facilement corrigibles. Les réponses marquées comme non mises en cache par défaut, les clés de cache fragmentées par des paramètres de suivi ou des en-têtes inutiles, et les délais d'expiration trop courts entraînent l'envoi de requêtes inutiles vers le serveur d'origine. Mesurer la proportion de requêtes servies depuis le serveur et identifier les facteurs à l'origine des échecs permet généralement de repérer un petit nombre de configurations responsables de la plupart d'entre elles. Améliorer cette proportion réduit la latence pour les visiteurs et la charge sur le serveur d'origine, ce qui améliore la qualité des réponses réellement nécessaires.

Étant donné que l'amélioration nécessite généralement des modifications de l'infrastructure, de la stratégie de mise en cache ou du code applicatif plutôt que des ressources front-end, c'est à ce niveau que les efforts d'optimisation des performances passent le plus souvent de la couche de présentation à la couche d'ingénierie. En pratique, ce problème est traité conjointement par performances web et le développement de produitset c'est souvent cette contrainte qu'il faut résoudre en premier, car l'optimisation frontale appliquée à une origine lente produit des résultats décevants qui sont alors attribués à tort au travail d'optimisation.