Découvrez comment optimiser la métrique "Time to First Byte".
Publié le 19 janvier 2023, dernière mise à jour le 28 novembre 2025
Le Time to First Byte (TTFB) est une métrique fondamentale des performances Web qui précède toutes les autres métriques d'expérience utilisateur importantes, telles que le First Contentful Paint (FCP) et le Largest Contentful Paint (LCP). Cela signifie que des valeurs TTFB élevées ajoutent du temps aux métriques qui suivent.
Nous vous recommandons de faire en sorte que votre serveur réponde aux requêtes de navigation suffisamment rapidement pour que le 75e centile des utilisateurs bénéficie d'un FCP dans le seuil "Bon". En règle générale, la plupart des sites doivent s'efforcer d'avoir un TTFB de 0,8 seconde ou moins.
Comment mesurer le TTFB
Avant de pouvoir optimiser le TTFB, vous devez observer son impact sur les utilisateurs de votre site Web. Vous devez vous appuyer sur les données de terrain comme source principale pour observer le TTFB, car il est affecté par les redirections, tandis que les outils de laboratoire sont souvent mesurés à l'aide de l'URL finale, ce qui ne tient pas compte de ce délai supplémentaire.
PageSpeed Insights est un moyen d'obtenir des informations réelles et de laboratoire pour les sites Web publics disponibles dans le rapport sur l'expérience utilisateur de Chrome.
Le TTFB pour les utilisateurs réels est indiqué dans la section Découvrez l'expérience de vos utilisateurs réels en haut de la page :
Pour les données de laboratoire, les problèmes de TTFB sont indiqués dans l'insight Latence de la requête de document :
Pour découvrir d'autres façons de mesurer le TTFB sur le terrain et en laboratoire, consultez la page de la métrique TTFB.
Comprendre les différences entre le TTFB sur le terrain et en laboratoire
Le TTFB en laboratoire et sur le terrain peut différer pour plusieurs raisons. Lorsque c'est le cas, il est important de comprendre pourquoi afin de pouvoir utiliser efficacement les données de laboratoire pour améliorer l'expérience utilisateur.
Lorsque le TTFB en laboratoire est beaucoup plus élevé que le TTFB sur le terrain, cela indique que l'environnement de laboratoire est plus limité que l'expérience utilisateur standard. Cela ne pose pas nécessairement de problème, car les résultats et les recommandations de l'atelier restent valides, mais cela peut exagérer l'impact et l'amélioration.
Lorsque le TTFB de terrain est beaucoup plus élevé que le TTFB de laboratoire, cela indique des problèmes qui ne sont pas apparents lors de l'exécution en laboratoire, tels que l'utilisation de la mise en cache côté serveur, des redirections ou des différences de réseau. Dans ce cas, les résultats et les recommandations de l'atelier peuvent être moins utiles, car ils ne tiennent pas compte de l'un des principaux problèmes.
Pour savoir si la mise en cache côté serveur a un impact sur le TTFB en laboratoire, essayez de tester des pages moins courantes ou d'utiliser différents paramètres d'URL pour obtenir du contenu non mis en cache, afin de voir si le TTFB est plus proche du TTFB sur le terrain. Il peut également être utile de pouvoir contourner la mise en cache côté serveur avec un paramètre d'URL particulier. Consultez la section Contenu mis en cache.
Pour les redirections et les différences de réseau, l'analyse de la façon dont le trafic arrive sur notre site et de sa provenance peut être utile pour déterminer s'il s'agit de problèmes potentiels.
Déboguer un TTFB élevé sur le terrain avec Server-Timing
L'en-tête de réponse Server-Timing peut être utilisé dans le backend de votre application pour mesurer les différents processus de backend susceptibles de contribuer à une latence élevée. La structure de la valeur d'en-tête est flexible et accepte, au minimum, un handle que vous définissez. Les valeurs facultatives incluent une valeur de durée (via dur), ainsi qu'une description facultative lisible par l'humain (via desc).
Serving-Timing peut être utilisé pour mesurer de nombreux processus de backend d'application, mais vous devez prêter une attention particulière à certains d'entre eux :
- requêtes de base de données
- Temps d'affichage côté serveur, le cas échéant
- Recherches de disque
- Succès ou échecs de cache du serveur périphérique (si vous utilisez un CDN)
Toutes les parties d'une entrée Server-Timing sont séparées par un deux-points, et plusieurs entrées peuvent être séparées par une virgule :
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
L'en-tête peut être défini à l'aide du langage de votre choix pour le backend de l'application. En PHP, par exemple, vous pouvez définir l'en-tête comme suit :
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Lorsque cet en-tête est défini, il affiche des informations que vous pouvez utiliser à la fois dans l'atelier et sur le terrain.
Sur le terrain, toute page avec un en-tête de réponse Server-Timing défini renseigne la propriété serverTiming dans l'API Navigation Timing :
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
Dans l'atelier, les données de l'en-tête de réponse Server-Timing sont visualisées dans le panneau Timings de l'onglet Network dans les outils pour les développeurs Chrome :
Ici, Server-Timing permet de mesurer si une requête de ressource a atteint le cache CDN, et le temps nécessaire pour que la requête atteigne le serveur périphérique du CDN, puis l'origine.
Les codes temporels du serveur sont également affichés dans la piste "Réseau" du panneau Performances des outils pour les développeurs Chrome :
Une fois que vous avez déterminé que le TTFB est problématique en analysant les données disponibles, vous pouvez passer à la résolution du problème.
Méthodes pour optimiser le TTFB
L'aspect le plus difficile de l'optimisation du TTFB est que, même si la pile d'interface Web est toujours HTML, CSS et JavaScript, les piles de backend peuvent varier considérablement. Il existe de nombreux produits de base de données et de piles de backend, chacun disposant de ses propres techniques d'optimisation. Par conséquent, ce guide se concentre sur ce qui s'applique à la plupart des architectures, plutôt que sur des conseils spécifiques à une pile.
Conseils spécifiques à la plate-forme
La plate-forme que vous utilisez pour votre site Web peut avoir un impact important sur le TTFB. Par exemple, les performances de WordPress sont influencées par le nombre et la qualité des plug-ins, ou par les thèmes utilisés. Les autres plates-formes sont également affectées lorsqu'elles sont personnalisées. Pour obtenir des conseils spécifiques à un fournisseur, consultez la documentation de votre plate-forme. Ils complèteront les conseils plus généraux sur les performances fournis dans cet article. L'insight Lighthouse inclut également des conseils limités spécifiques à la pile.
Hébergement, hébergement, hébergement
Avant même d'envisager d'autres approches d'optimisation, l'hébergement doit être votre première préoccupation. Il n'y a pas beaucoup de conseils spécifiques à donner ici, mais une règle générale consiste à s'assurer que l'hôte de votre site Web est capable de gérer le trafic que vous lui envoyez.
L'hébergement partagé est généralement plus lent. Si vous gérez un petit site Web personnel qui diffuse principalement des fichiers statiques, cela ne pose probablement pas de problème. Utilisez certaines des techniques d'optimisation suivantes pour réduire au maximum votre TTFB.
Toutefois, si vous exécutez une application plus volumineuse avec de nombreux utilisateurs, qui implique la personnalisation, l'interrogation de bases de données et d'autres opérations intensives côté serveur, votre choix d'hébergement devient essentiel pour réduire le TTFB sur le terrain.
Lorsque vous choisissez un fournisseur d'hébergement, voici quelques éléments à prendre en compte :
- Quelle quantité de mémoire est allouée à votre instance d'application ? Si votre application ne dispose pas de suffisamment de mémoire, elle risque de s'emballer et de ne pas pouvoir diffuser les pages aussi rapidement que possible.
- Votre fournisseur d'hébergement maintient-il votre pile de backend à jour ? À mesure que de nouvelles versions des langages de backend d'application, des implémentations HTTP et des logiciels de base de données sont publiées, les performances de ces logiciels s'améliorent au fil du temps. Il est essentiel de s'associer à un fournisseur d'hébergement qui accorde la priorité à ce type de maintenance cruciale.
- Si vous avez des exigences très spécifiques pour votre application et que vous souhaitez un accès de niveau inférieur aux fichiers de configuration du serveur, demandez-vous s'il est judicieux de personnaliser le backend de votre propre instance d'application.
De nombreux fournisseurs d'hébergement s'en chargent pour vous, mais si vous commencez à observer des valeurs TTFB élevées, même chez des fournisseurs d'hébergement dédiés, cela peut indiquer que vous devez réévaluer les capacités de votre fournisseur d'hébergement actuel afin d'offrir la meilleure expérience utilisateur possible.
Utiliser un réseau de diffusion de contenu (CDN)
Le sujet de l'utilisation d'un CDN est bien connu, mais pour une bonne raison : vous pouvez avoir un backend d'application très bien optimisé, mais les utilisateurs situés loin de votre serveur d'origine peuvent toujours rencontrer un TTFB élevé sur le terrain.
Les CDN résolvent le problème de la proximité des utilisateurs par rapport à votre serveur d'origine en utilisant un réseau distribué de serveurs qui mettent en cache les ressources sur des serveurs physiquement plus proches de vos utilisateurs. Ces serveurs sont appelés serveurs périphériques.
Les fournisseurs de CDN peuvent également offrir des avantages au-delà des serveurs périphériques :
- Les fournisseurs de CDN offrent généralement des temps de résolution DNS extrêmement rapides.
- Un CDN diffuse probablement votre contenu à partir de serveurs périphériques à l'aide de protocoles modernes tels que HTTP/2 ou HTTP/3.
- HTTP/3 résout en particulier le problème de blocage en tête de ligne présent dans TCP (sur lequel repose HTTP/2) en utilisant le protocole UDP.
- Un CDN fournit probablement des versions modernes de TLS, ce qui réduit la latence liée au temps de négociation TLS. TLS 1.3, en particulier, est conçu pour que la négociation TLS soit aussi courte que possible.
- Certains fournisseurs de CDN proposent une fonctionnalité souvent appelée "edge worker", qui utilise une API semblable à l'API Service Worker pour intercepter les requêtes, gérer de manière programmatique les réponses dans les caches périphériques ou réécrire complètement les réponses.
- Les fournisseurs de CDN sont très doués pour optimiser la compression. La compression est difficile à réaliser par vous-même et peut entraîner des temps de réponse plus lents dans certains cas avec un balisage généré de manière dynamique, qui doit être compressé à la volée.
- De plus, les fournisseurs de CDN mettent automatiquement en cache les réponses compressées pour les ressources statiques, ce qui permet d'obtenir le meilleur compromis entre taux de compression et temps de réponse.
Bien que l'adoption d'un CDN implique un effort variable, de minime à important, l'optimisation de votre TTFB doit être une priorité si votre site Web n'en utilise pas déjà un.
Utiliser du contenu mis en cache dans la mesure du possible
Les CDN permettent de mettre en cache le contenu sur des serveurs périphériques situés physiquement plus près des visiteurs, à condition que le contenu soit configuré avec les en-têtes HTTP Cache-Control appropriés. Bien que cela ne soit pas approprié pour le contenu personnalisé, le fait de devoir revenir à l'origine peut annuler une grande partie de la valeur d'un CDN.
Pour les sites qui mettent fréquemment à jour leur contenu, même une courte durée de mise en cache peut entraîner des gains de performances notables pour les sites très fréquentés, car seul le premier visiteur pendant cette période subit la latence complète vers le serveur d'origine, tandis que tous les autres visiteurs peuvent réutiliser la ressource mise en cache à partir du serveur périphérique. Certains CDN permettent d'invalider le cache lors des lancements de sites, ce qui permet de bénéficier du meilleur des deux mondes : des durées de mise en cache longues, mais des mises à jour instantanées si nécessaire.
Même si la mise en cache est correctement configurée, elle peut être ignorée si des paramètres de chaîne de requête uniques sont utilisés pour les mesures analytiques. Le CDN peut les considérer comme des contenus différents, même s'ils sont identiques. La version mise en cache ne sera donc pas utilisée.
Il est également possible que les contenus plus anciens ou moins visités ne soient pas mis en cache, ce qui peut entraîner des valeurs TTFB plus élevées sur certaines pages que sur d'autres. Augmenter les durées de mise en cache peut réduire l'impact de ce problème, mais sachez que cela augmente également le risque de diffuser du contenu potentiellement obsolète.
L'impact du contenu mis en cache ne concerne pas seulement les utilisateurs de CDN. L'infrastructure du serveur peut avoir besoin de générer du contenu à partir de recherches coûteuses dans la base de données lorsque le contenu mis en cache ne peut pas être réutilisé. Les données consultées plus fréquemment ou les pages pré-mises en cache peuvent souvent offrir de meilleures performances.
Éviter d'avoir plusieurs redirections de page
Les redirections sont un facteur courant de TTFB élevé. Les redirections se produisent lorsqu'une requête de navigation pour un document reçoit une réponse informant le navigateur que la ressource existe à un autre emplacement. Une redirection peut ajouter une latence indésirable à une requête de navigation, mais la situation peut s'aggraver si cette redirection pointe vers une autre ressource qui entraîne une autre redirection, et ainsi de suite. Cela peut particulièrement affecter les sites qui reçoivent un grand nombre de visiteurs provenant d'annonces ou de newsletters, car ils sont souvent redirigés vers des services d'analyse à des fins de mesure. Éliminer les redirections que vous contrôlez directement peut vous aider à obtenir un bon TTFB.
Il existe deux types de redirections :
- Redirections de même origine, où la redirection se produit entièrement sur votre site Web.
- Redirections interorigines, où la redirection se produit initialement sur une autre origine (par exemple, à partir d'un service de raccourcissement d'URL de réseau social) avant d'arriver sur votre site Web.
Concentrez-vous sur l'élimination des redirections de même origine, car vous pouvez les contrôler directement. Pour cela, vous devez vérifier les liens de votre site Web pour voir si l'un d'eux renvoie un code de réponse 302 ou 301. Cela peut être dû au fait que le schéma https:// n'est pas inclus (les navigateurs utilisent donc par défaut http://, qui redirige ensuite) ou que les barres obliques de fin ne sont pas incluses ou exclues de manière appropriée dans l'URL.
Les redirections interorigines sont plus complexes, car elles échappent souvent à votre contrôle. Toutefois, essayez d'éviter les redirections multiples dans la mesure du possible, par exemple en utilisant plusieurs réducteurs de liens lorsque vous partagez des liens. Assurez-vous que l'URL fournie aux annonceurs ou aux newsletters est l'URL finale correcte, afin de ne pas ajouter une autre redirection à celles utilisées par ces services.
Les redirections HTTP vers HTTPS peuvent également être une source importante de temps de redirection. Pour contourner ce problème, vous pouvez utiliser l'en-tête Strict-Transport-Security (HSTS), qui applique le protocole HTTPS lors de la première visite d'une origine, puis indique au navigateur d'accéder immédiatement à l'origine via le protocole HTTPS lors des visites ultérieures.
Une fois que vous avez mis en place une bonne règle HSTS, vous pouvez accélérer les choses lors de la première visite d'une origine en ajoutant votre site à la liste de préchargement HSTS.
Diffuser le balisage vers le navigateur
Les navigateurs sont optimisés pour traiter efficacement le balisage lorsqu'il est diffusé, ce qui signifie que le balisage est traité par fragments à mesure qu'il arrive du serveur. C'est crucial pour les charges utiles de balisage volumineuses, car cela signifie que le navigateur peut analyser les fragments de balisage de manière incrémentielle, au lieu d'attendre que l'intégralité de la réponse arrive avant de pouvoir commencer l'analyse.
Bien que les navigateurs soient très efficaces pour gérer le balisage en flux continu, il est essentiel de faire tout votre possible pour que ce flux continue de circuler afin que les premiers éléments de balisage soient transmis le plus rapidement possible. Si le backend ralentit les choses, c'est un problème. Étant donné que les piles de backend sont nombreuses, il n'est pas possible de couvrir chacune d'entre elles et les problèmes qui pourraient survenir dans chacune d'elles.
React, par exemple, et d'autres frameworks capables d'afficher le balisage à la demande sur le serveur ont utilisé une approche synchrone pour le rendu côté serveur. Cependant, les versions plus récentes de React ont implémenté des méthodes de serveur pour le balisage en streaming au fur et à mesure de son rendu. Cela signifie que vous n'avez pas besoin d'attendre qu'une méthode d'API de serveur React affiche l'intégralité de la réponse avant de l'envoyer.
Une autre façon de s'assurer que le balisage est diffusé rapidement dans le navigateur consiste à utiliser l'affichage statique, qui génère des fichiers HTML au moment de la compilation. Le fichier complet étant disponible immédiatement, les serveurs Web peuvent commencer à l'envoyer immédiatement, et la nature inhérente de HTTP entraîne un balisage en streaming. Bien que cette approche ne soit pas adaptée à toutes les pages de tous les sites Web (par exemple, celles qui nécessitent une réponse dynamique dans le cadre de l'expérience utilisateur), elle peut être utile pour les pages qui ne nécessitent pas de balisage personnalisé pour un utilisateur spécifique.
Utiliser un service worker
L'API Service Worker peut avoir un impact important sur le TTFB pour les documents et les ressources qu'ils chargent. En effet, un service worker agit comme un proxy entre le navigateur et le serveur. Toutefois, l'impact sur le TTFB de votre site Web dépend de la configuration de votre service worker et de la conformité de cette configuration avec les exigences de votre application.
- Utilisez une stratégie stale-while-revalidate pour les éléments. Si un élément se trouve dans le cache du service worker, qu'il s'agisse d'un document ou d'une ressource requise par le document, la stratégie stale-while-revalidate diffuse d'abord cette ressource à partir du cache, puis télécharge cet élément en arrière-plan et le diffuse à partir du cache pour les interactions futures.
- Si vous disposez de ressources de document qui ne changent pas très souvent, l'utilisation d'une stratégie stale-while-revalidate peut rendre le TTFB d'une page presque instantané. Toutefois, cela ne fonctionne pas très bien si votre site Web envoie un balisage généré de manière dynamique, par exemple un balisage qui change selon que l'utilisateur est authentifié ou non. Dans ce cas, vous devez toujours interroger le réseau en premier, afin que le document soit aussi récent que possible.
- Si votre document charge des ressources non critiques qui changent fréquemment, mais que la récupération de la ressource obsolète n'affecte pas de manière significative l'expérience utilisateur (par exemple, certaines images ou d'autres ressources non critiques), le TTFB de ces ressources peut être considérablement réduit à l'aide d'une stratégie stale-while-revalidate.
- Utilisez le modèle shell d'application pour les applications affichées côté client. Ce modèle est idéal pour les applications monopages, où le "shell" de la page peut être diffusé instantanément à partir du cache du service worker, et où le contenu dynamique de la page est renseigné et affiché plus tard dans le cycle de vie de la page.
Utiliser 103 Early Hints pour les ressources critiques pour l'affichage
Même si le backend de votre application est optimisé, le serveur peut encore avoir besoin d'effectuer un travail important pour préparer une réponse, y compris un travail de base de données coûteux (mais nécessaire) qui retarde l'arrivée de la réponse de navigation aussi rapidement que possible. Cela peut retarder certaines ressources ultérieures essentielles au rendu, telles que le CSS ou, dans certains cas, le JavaScript qui affiche le balisage sur le client.
L'en-tête 103 Early Hints est un code de réponse anticipé que le serveur peut envoyer au navigateur pendant que le backend prépare le balisage. Cet en-tête peut être utilisé pour indiquer au navigateur qu'il existe des ressources essentielles au rendu que la page doit commencer à télécharger pendant la préparation du balisage. Pour les navigateurs compatibles, cela peut accélérer l'affichage des documents (CSS) et le chargement des pages.
L'un des inconvénients de 103 Early Hints est que, comme la mise en cache, ils peuvent masquer le TTFB "réel" d'un site. Si une infrastructure de serveur est lente (parce qu'elle manque de puissance ou que le code doit être optimisé), cela peut être moins évident lorsque le code 103 Early Hints est utilisé, car le TTFB semble rapide. Les sites utilisant 103 Early Hints devraient envisager de mesurer le temps de réponse réel du serveur (via Server-Timing ou finalResponseHeadersStart de l'API PerformanceNavigationTiming).
Conclusion
Étant donné qu'il existe de nombreuses combinaisons de piles d'applications backend, aucun article ne peut résumer tout ce que vous pouvez faire pour réduire le TTFB de votre site Web. Toutefois, vous pouvez explorer certaines options pour essayer d'accélérer un peu les choses côté serveur.
Comme pour l'optimisation de chaque métrique, l'approche est globalement similaire : mesurez votre TTFB sur le terrain, utilisez des outils de laboratoire pour analyser les causes, puis appliquez des optimisations lorsque cela est possible. Certaines techniques ne sont peut-être pas adaptées à votre situation, mais d'autres le sont probablement. Comme toujours, vous devrez surveiller de près vos données de terrain et apporter les ajustements nécessaires pour garantir une expérience utilisateur aussi rapide que possible.