Découvrez comment optimiser pour la métrique "Time to First Byte".
Le temps de chargement du premier octet (TTFB) est une métrique de performances Web fondamentale qui précède toutes les autres métriques d'expérience utilisateur pertinentes, telles que le FCP (First Contentful Paint) et le LCP (Largest Contentful Paint). Cela signifie que les valeurs TTFB élevées ajoutent du temps aux métriques qui les suivent.
Nous vous recommandons de configurer votre serveur de manière à ce qu'il réponde suffisamment rapidement aux requêtes de navigation pour que le 75e percentile des utilisateurs bénéficie d'un FCP dans la plage "bon". À titre indicatif, la plupart des sites doivent s'efforcer d'obtenir un TTFB de 0,8 seconde ou moins.
Mesurer le délai avant réponse
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 sur le terrain comme source principale d'observation du TTFB, car il est affecté par les redirections. En revanche, les outils basés en laboratoire sont souvent mesurés à l'aide de l'URL finale, ce qui ne permet pas de détecter ce délai supplémentaire.
PageSpeed Insights est un moyen d'obtenir des informations sur le terrain et en laboratoire pour les sites Web publics disponibles dans le rapport d'expérience utilisateur Chrome.
Le TTFB pour les utilisateurs réels s'affiche dans la section Découvrez l'expérience de vos utilisateurs en haut de la page:
Un sous-ensemble du TTFB est affiché dans l'audit du temps de réponse du serveur:
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.
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 processus backend distincts qui pourraient contribuer à une latence élevée. La structure de la valeur de l'en-tête est flexible et accepte au moins un gestionnaire que vous définissez. Les valeurs facultatives incluent une valeur de durée (via dur), ainsi qu'une description lisible par l'humain (via desc).
Serving-Timing peut être utilisé pour mesurer de nombreux processus backend d'application, mais certains d'entre eux méritent une attention particulière:
- Requêtes de base de données
- Temps d'affichage côté serveur, le cas échéant
- Recherches de disque
- Taux de réussite/échec de la mise en cache du serveur Edge (si vous utilisez un CDN)
Toutes les parties d'une entrée Server-Timing sont séparées par 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 dans la langue de votre choix pour le backend de votre 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.
Dans le champ, toute page avec un en-tête de réponse Server-Timing défini remplira 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 des délais de l'onglet Network (Réseau) de Chrome DevTools:
En-têtes de réponse Server-Timing visualisés dans l'onglet "Network" (Réseau) des outils pour les développeurs Chrome Ici, Server-Timing permet de déterminer si une requête de ressource a atteint le cache du CDN, et le temps nécessaire pour que la requête atteigne le serveur de périphérie du CDN, puis l'origine.
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 d'optimisation du TTFB
L'aspect le plus difficile de l'optimisation du TTFB est que, bien que la pile de présentation du Web soit toujours HTML, CSS et JavaScript, les piles backend peuvent varier considérablement. Il existe de nombreuses piles backend et produits de base de données, chacun ayant ses propres techniques d'optimisation. Par conséquent, ce guide se concentrera sur ce qui s'applique à la plupart des architectures, plutôt que sur des conseils spécifiques à la 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 affectées par le nombre et la qualité des plug-ins, ou par les thèmes utilisés. Les autres plates-formes sont également concernées lorsque la plate-forme est personnalisée. Pour obtenir des conseils spécifiques au fournisseur, consultez la documentation de votre plate-forme en complément des conseils plus généraux sur les performances de cet article. L'audit Lighthouse visant à réduire les temps de réponse du serveur 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, vous devez commencer par l'hébergement. Nous ne pouvons pas vous donner de conseils spécifiques, mais en règle générale, assurez-vous que l'hébergeur 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. Certaines des techniques d'optimisation suivantes vous aideront à réduire le TTFB autant que possible.
Toutefois, si vous exécutez une application plus importante avec de nombreux utilisateurs qui implique la personnalisation, l'interrogation de base 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.
Voici quelques points à prendre en compte lorsque vous choisissez un fournisseur d'hébergement:
- Combien de mémoire est allouée à votre instance d'application ? Si la mémoire de votre application est insuffisante, elle sera ralentie et aura du mal à diffuser les pages aussi rapidement que possible.
- Votre fournisseur d'hébergement met-il à jour votre pile backend ? À mesure que de nouvelles versions de langages de backend d'application, d'implémentations HTTP et de logiciels de base de données seront publiées, les performances de ces logiciels s'amélioreront au fil du temps. Il est essentiel de collaborer avec un fournisseur d'hébergement qui donne la priorité à ce type de maintenance cruciale.
- Si vous avez des exigences d'application très spécifiques et que vous souhaitez disposer du niveau d'accès le plus bas 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 occupent pour vous, mais si vous commencez à observer des valeurs de TTFB longues, même chez des fournisseurs d'hébergement dédiés, cela peut être un signe que vous devrez peut-être réévaluer les fonctionnalités de votre fournisseur d'hébergement actuel afin de proposer 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, et pour cause: vous pouvez avoir un backend d'application très bien optimisé, mais les utilisateurs situés loin de votre serveur d'origine peuvent toujours constater un TTFB élevé sur le terrain.
Les CDN résolvent le problème de 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 situés physiquement plus près de vos utilisateurs. Ces serveurs sont appelés serveurs de périphérie.
Les fournisseurs de CDN peuvent également offrir des avantages au-delà des serveurs de périphérie:
- 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 de périphérie à l'aide de protocoles modernes tels que HTTP/2 ou HTTP/3.
- HTTP/3 résout en particulier le problème de blocage de la tête de ligne présent dans TCP (sur lequel HTTP/2 s'appuie) à l'aide du protocole UDP.
- Un CDN fournit probablement également des versions modernes de TLS, ce qui réduit la latence associé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 "worker de bord", qui utilise une API semblable à celle de l'API Service Worker pour intercepter les requêtes, gérer de manière programmatique les réponses dans les caches de bord ou réécrire complètement les réponses.
- Les fournisseurs de CDN sont très bons pour optimiser la compression. La compression est difficile à réaliser par vous-même et peut entraîner des délais de réponse plus longs dans certains cas avec du balisage généré dynamiquement, qui doit être compressé instantanément.
- Les fournisseurs de CDN mettent également automatiquement en cache les réponses compressées pour les ressources statiques, ce qui offre le meilleur rapport entre le taux de compression et le temps de réponse.
L'adoption d'un CDN implique un effort variable, allant du simple au significatif. Toutefois, vous devez optimiser votre TTFB en priorité si votre site Web n'en utilise pas déjà un.
Utilisation du contenu mis en cache dans la mesure du possible
Les CDN permettent de mettre en cache le contenu sur des serveurs de périphérie 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é, exiger un aller-retour jusqu'à 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 de périphérie. Certains CDN permettent d'invalider le cache lors des versions du site. Vous bénéficiez ainsi des avantages des deux approches : des temps de cache longs, mais des mises à jour instantanées si nécessaire.
Même si le cache est correctement configuré, vous pouvez l'ignorer en utilisant des paramètres de chaîne de requête uniques pour la mesure des données analytiques. Ces contenus peuvent sembler différents pour le CDN, même s'ils sont identiques. La version mise en cache ne sera donc pas utilisée.
Les contenus plus anciens ou moins consultés peuvent également ne pas être mis en cache, ce qui peut entraîner des valeurs TTFB plus élevées sur certaines pages que sur d'autres. Augmenter les délais de mise en cache peut réduire l'impact de ce problème, mais sachez qu'une augmentation de ces délais augmente également la probabilité de diffuser du contenu potentiellement obsolète.
L'impact du contenu mis en cache ne concerne pas uniquement les utilisateurs de CDN. L'infrastructure de serveur peut être amenée à générer du contenu à partir de recherches de base de données coûteuses lorsque le contenu mis en cache ne peut pas être réutilisé. Les données consultées plus fréquemment ou les pages préchargées peuvent souvent offrir de meilleures performances.
Éviter d'avoir plusieurs redirections de page
Les redirections sont un facteur courant de temps de réponse au premier octet élevé. Les redirections se produisent lorsqu'une requête de navigation pour un document reçoit une réponse qui informe le navigateur que la ressource se trouve à un autre emplacement. Une redirection peut certainement 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 génère une autre redirection, et ainsi de suite. Cela peut particulièrement affecter les sites qui reçoivent de nombreux visiteurs via des annonces ou des newsletters, car ils sont souvent redirigés via des services d'analyse à des fins de mesure. L'élimination des redirections sous votre contrôle direct peut contribuer à obtenir un TTFB correct.
Il existe deux types de redirections:
- Redirections de même origine, où la redirection se produit entièrement sur votre site Web.
- Redirections multi-origines, où la redirection se produit initialement sur une autre origine (par exemple, à partir d'un service de raccourcissement d'URL sur les réseaux sociaux) avant d'arriver sur votre site Web.
Vous devez vous concentrer sur l'élimination des redirections de même origine, car vous pouvez les contrôler directement. Pour ce faire, vérifiez les liens de votre site Web pour voir si l'un d'eux génère un code de réponse 302 ou 301. Cela peut souvent être dû à l'absence du schéma https:// (les navigateurs utilisent alors par défaut http://, qui redirige ensuite) ou parce que les barres obliques finales ne sont pas correctement incluses ou exclues de l'URL.
Les redirections inter-origines sont plus délicates, car elles ne sont souvent pas sous votre contrôle. Toutefois, essayez d'éviter les redirections multiples dans la mesure du possible, par exemple en utilisant plusieurs abrégisseurs de liens lorsque vous partagez des liens. Assurez-vous que l'URL fournie aux annonceurs ou aux newsletters est bien l'URL finale, 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 HTTPS lors de la première visite d'une origine, puis indique au navigateur d'accéder immédiatement à l'origine via le schéma HTTPS lors des prochaines visites.
Une fois que vous avez mis en place une bonne règle HSTS, vous pouvez accélérer la première visite d'une origine en ajoutant votre site à la liste de préchargement HSTS.
Diffuser le balisage dans le navigateur
Les navigateurs sont optimisés pour traiter le balisage de manière efficace lorsqu'il est diffusé en continu, ce qui signifie qu'il est géré par blocs lorsqu'il arrive du serveur. Cela est crucial pour les charges utiles de balisage volumineuses, car cela signifie que le navigateur peut analyser les segments de balisage de manière incrémentielle, au lieu d'attendre que la réponse complète arrive avant que l'analyse puisse commencer.
Bien que les navigateurs soient très efficaces pour gérer le balisage en streaming, il est essentiel de faire tout votre possible pour que ce flux continue de s'écouler afin que ces éléments de balisage initiaux soient envoyés dès que possible. Si le backend ralentit les choses, c'est un problème. Étant donné que les piles backend sont nombreuses, il ne serait pas possible de couvrir toutes les piles et les problèmes qui pourraient survenir dans chacune d'elles dans le cadre de ce guide.
React, par exemple, et d'autres frameworks capables de rendre le balisage à la demande sur le serveur, ont utilisé une approche synchrone pour le rendu côté serveur. Toutefois, les versions plus récentes de React ont implémenté des méthodes de serveur pour le streaming de balisage au moment de l'affichage. Cela signifie que vous n'avez pas besoin d'attendre qu'une méthode d'API de serveur React affiche la réponse complète avant de l'envoyer.
Pour vous assurer que le balisage est diffusé rapidement dans le navigateur, vous pouvez également utiliser le rendu 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 du protocole HTTP entraîne le balisage en streaming. Bien que cette approche ne convienne pas à 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 bénéfique pour les pages qui ne nécessitent pas de balisage pour être personnalisées en fonction d'un utilisateur spécifique.
Utiliser un service worker
L'API Service Worker peut avoir un impact important sur le TTFB, à la fois pour les documents et pour 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 façon dont vous configurez votre service worker et si cette configuration est conforme aux exigences de votre application.
- Utilisez une stratégie d'expiration pendant la validation pour les composants. Si un élément se trouve dans le cache du service worker (qu'il s'agisse d'un document ou d'une ressource dont le document a besoin), la stratégie "obsolète lors de la validation" 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 futures interactions.
- Si vos ressources de documents ne changent pas très souvent, l'utilisation d'une stratégie "obsolète pendant la validation" peut rendre le délai avant le premier octet de la page presque instantané. Toutefois, cette méthode ne fonctionne pas aussi bien si votre site Web envoie du balisage généré dynamiquement, par exemple du balisage qui change en fonction de l'authentification de l'utilisateur. Dans ce cas, vous devez toujours d'abord accéder au réseau pour que le document soit aussi récent que possible.
- Si votre document charge des ressources non critiques qui changent de façon fréquente, mais que l'extraction de la ressource obsolète n'affecte pas beaucoup 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 d'obsolescence pendant la validation.
- Utilisez le modèle de shell d'application pour les applications rendues côté client. Ce modèle convient le mieux aux SPA, où la "coquille" de la page peut être diffusée 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 essentielles au rendu
Quelle que soit l'optimisation du backend de votre application, le serveur peut toujours avoir beaucoup de travail à effectuer pour préparer une réponse, y compris des tâches de base de données coûteuses (mais nécessaires) qui retardent la réponse de navigation. Cela peut entraîner un retard de certaines ressources critiques pour le rendu ultérieures, telles que le CSS ou, dans certains cas, le code JavaScript qui effectue le rendu du 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 est occupé à préparer 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, l'effet peut être un affichage plus rapide des documents (CSS) et une disponibilité plus rapide des fonctionnalités de base de la page (JavaScript).
Conclusion
Étant donné qu'il existe de nombreuses combinaisons de piles d'applications backend, il n'existe pas d'article qui puisse englober tout ce que vous pouvez faire pour réduire le TTFB de votre site Web. Toutefois, voici quelques options que vous pouvez explorer pour essayer d'accélérer les choses côté serveur.
Comme pour l'optimisation de chaque métrique, l'approche est largement similaire: mesurez votre TTFB sur le terrain, utilisez des outils de laboratoire pour identifier les causes, puis appliquez des optimisations si possible. Il est possible que certaines de ces techniques ne soient pas adaptées à votre situation, mais d'autres le seront. Comme toujours, vous devrez surveiller de près vos données sur le terrain et apporter les ajustements nécessaires pour garantir une expérience utilisateur la plus rapide possible.
Image principale par Taylor Vick, provenant d'Unsplash.