Découvrez comment optimiser la métrique "Délai avant le premier octet".
Le délai avant le premier octet (TTFB) est une métrique de performances Web fondamentale qui précède toute autre métrique significative liée à l'expérience utilisateur, comme First Contentful Paint (FCP) et Largest Contentful Paint (LCP). Cela signifie que des valeurs TTFB élevées ajoutent du temps aux métriques qui la suivent.
Il est recommandé que votre serveur réponde suffisamment rapidement aux requêtes de navigation pour que le 75e centile des utilisateurs bénéficie d'un FCP inférieur au seuil "satisfaisant". À titre indicatif, la plupart des sites doivent s'efforcer d'avoir un TTFB de 0,8 seconde maximum.
Mesurer le TTFB
Avant de pouvoir optimiser le TTFB, vous devez observer son impact sur les utilisateurs de votre site Web. Vous devez utiliser les données des champs comme source principale pour observer le TTFB car il est affecté par les redirections, tandis que les outils basés sur des ateliers sont souvent mesurés à l'aide de l'URL finale. Par conséquent, ce délai supplémentaire est manquant.
PageSpeed Insights est l'une des méthodes permettant d'obtenir des informations sur le terrain et sur les ateliers liés aux sites Web publics, qui sont disponibles dans le rapport sur l'expérience utilisateur de Chrome.
Le TTFB pour les utilisateurs réels est affiché dans la section Découvrez ce que vivent vos utilisateurs réels en haut de la page:
Un sous-ensemble de TTFB est présenté 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 atelier, consultez la page des métriques du 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 de backend distincts susceptibles de contribuer à une latence élevée. La structure de la valeur d'en-tête est flexible et accepte au minimum un identifiant 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 permet de mesurer de nombreux processus de backend d'application. Toutefois, vous pouvez porter une attention particulière à certains processus:
- Requêtes de base de données
- Délai d'affichage côté serveur, le cas échéant
- Recherches sur le disque
- Succès ou défaut 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 des 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 choisi par 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 - $dbReadStarTime) / 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 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 cet atelier, les données de l'en-tête de réponse Server-Timing seront visualisées dans le panneau des codes temporels de l'onglet Network (Réseau) dans les outils pour les développeurs Chrome:
En-têtes de réponse Server-Timing affichés dans l'onglet "Réseau" des outils pour les développeurs Chrome. Ici, Server-Timing est utilisé pour mesurer si une requête de ressource a atteint le cache CDN, et combien de temps il faut pour que la requête atteigne le serveur périphérique du CDN, puis l'origine.
Une fois que vous avez déterminé que vous avez un TTFB 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, bien que la pile frontend du Web soit toujours HTML, CSS et JavaScript, les piles backend peuvent varier considérablement. Il existe de nombreux produits de base de données et piles de backend qui possèdent chacun leurs propres techniques d'optimisation. Par conséquent, ce guide se concentrera sur ce qui s'applique à la plupart des architectures, plutôt que sur les conseils spécifiques à la pile.
Conseils spécifiques aux plates-formes
La plateforme que vous utilisez pour votre site Web peut avoir un impact important sur TTFB. Par exemple, les performances de WordPress dépendent du nombre et de la qualité des plug-ins, ou des thèmes utilisés. Les autres plates-formes sont affectées de la même manière lorsque la plate-forme est personnalisée. Nous vous invitons à consulter la documentation de votre plate-forme afin d'obtenir des conseils spécifiques aux fournisseurs en complément des conseils généraux relatifs aux performances présentés dans cet article. L'audit Lighthouse visant à réduire les temps de réponse des serveurs inclut également des conseils limités concernant les piles.
Hébergement, hébergement, hébergement
Avant même d'envisager d'autres méthodes d'optimisation, l'hébergement doit être la première chose à laquelle vous devez penser. Il n'y a pas beaucoup de conseils spécifiques qui peuvent être fournis ici, mais la 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 envoyez vers celui-ci.
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, ce n'est probablement pas un problème. Certaines des techniques d'optimisation ci-dessous vous aideront à faire en sorte que ce soit le plus possible.
Toutefois, si vous exécutez une application plus importante avec de nombreux utilisateurs impliquant 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, tenez compte des points suivants:
- Quelle est la quantité de mémoire allouée à votre instance d'application ? Si votre application ne dispose pas d'une mémoire insuffisante, elle se retrouvera incapable de traiter les pages le plus rapidement possible.
- Votre pile backend est-elle toujours à jour sur votre fournisseur d'hébergement ? À mesure que de nouvelles versions des langages de backend d'application, des implémentations HTTP et des logiciels de base de données seront disponibles, 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 très spécifiques pour votre application et souhaitez disposer du niveau d'accès le plus bas pour les fichiers de configuration du serveur, demandez-lui s'il est judicieux de personnaliser le backend de votre propre instance d'application.
De nombreux fournisseurs d'hébergement peuvent s'en charger pour vous, mais si vous commencez à observer des valeurs TTFB longues même chez des fournisseurs d'hébergement dédiés, cela peut signifier que vous devrez peut-être 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)
L'utilisation d'un CDN est assez usuelle, mais pour une bonne raison: le backend d'application peut être très bien optimisé, mais les utilisateurs situés loin de votre serveur d'origine peuvent tout de même rencontrer un taux de TTFB élevé sur le terrain.
Les CDN résolvent le problème de la proximité entre les utilisateurs et votre serveur d'origine en utilisant un réseau distribué de serveurs qui mettent en cache les ressources sur des serveurs physiquement plus proches des utilisateurs. Ces serveurs sont appelés serveurs périphériques.
Les fournisseurs de CDN peuvent également proposer d'autres avantages que les serveurs périphériques:
- Les fournisseurs de CDN offrent généralement des délais de résolution DNS extrêmement rapides.
- Un CDN diffusera probablement votre contenu à partir de serveurs périphériques à l'aide de protocoles modernes tels que HTTP/2 ou HTTP/3.
- HTTP/3, en particulier, résout 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 fournira probablement également des versions modernes de TLS, ce qui réduit la latence impliquée dans la négociation TLS. TLS 1.3 en particulier est conçu pour que la négociation TLS soit la plus courte possible.
- Certains fournisseurs de CDN proposent une fonctionnalité souvent appelée "edge worker", qui utilise une API semblable à celle de l'API Service Worker pour intercepter les requêtes, gérer les réponses dans les caches périphériques ou réécrire les réponses de manière automatisée.
- Les fournisseurs de CDN sont très efficaces pour optimiser la compression. La compression est une tâche difficile à effectuer par vous-même. Dans certains cas, elle peut ralentir les temps de réponse en cas de balisage généré de façon 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 offre la meilleure combinaison de taux de compression et de temps de réponse.
Bien que l'adoption d'un CDN implique des efforts variables, allant de simples à importants, l'optimisation de votre TTFB doit être une priorité absolue si votre site Web n'en utilise pas déjà un.
Utiliser du contenu mis en cache lorsque cela était possible
Les CDN permettent de mettre en cache le contenu sur des serveurs en périphérie qui sont physiquement proches des visiteurs, à condition que le contenu soit configuré avec les en-têtes HTTP Cache-Control appropriés. Bien que cela ne convienne pas au contenu personnalisé, le fait d'exiger un trajet jusqu'au point de départ 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 surchargés. En effet, seul le premier visiteur pendant cette période subit une latence totale vers le serveur d'origine, tandis que tous les autres peuvent réutiliser la ressource mise en cache du serveur en périphérie. Certains CDN permettent l'invalidation du cache lors des versions de site, ce qui permet de tirer le meilleur parti des deux mondes : de longs temps de cache, mais des mises à jour instantanées en cas de besoin.
Même lorsque la mise en cache est correctement configurée, cela peut être ignoré par l'utilisation de paramètres de chaîne de requête uniques à des fins de mesure analytique. Même s'ils sont identiques, ceux-ci peuvent ressembler à un contenu différent sur le CDN. La version mise en cache ne sera donc pas utilisée.
Il est également possible que les contenus plus anciens ou moins consultés ne soient pas mis en cache, ce qui peut entraîner des valeurs pour le TTFB plus élevées sur certaines pages que sur d'autres. L'augmentation de la durée de la mise en cache peut réduire l'impact de ce changement, mais sachez qu'elle augmente la probabilité de diffuser du contenu potentiellement obsolète.
L'impact du contenu mis en cache ne concerne pas seulement les utilisateurs de CDN. L'infrastructure 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 les plus consultées ou les pages mises en pré-cache peuvent souvent offrir de meilleures performances.
Éviter d'avoir plusieurs redirections de page
Les redirections sont souvent à l'origine d'un TTFB é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 existe à un autre emplacement. Une redirection peut certainement ajouter une latence indésirable à une requête de navigation, mais cela peut certainement empirer si cette redirection pointe vers une autre ressource qui entraîne une autre redirection, et ainsi de suite. Cela peut particulièrement avoir un impact sur les sites qui reçoivent un grand nombre de visiteurs à partir de publicités ou de newsletters, car ils sont souvent redirigés via des services d'analyse à des fins de mesure. En éliminant les redirections sous votre contrôle direct, vous obtiendrez de bons résultats.
Il existe deux types de redirections:
- Les redirections d'origine identique, où la redirection se produit entièrement sur votre site Web.
- Les redirections d'origine croisée : elles se produisent initialement sur une autre origine (par exemple, à partir d'un service de raccourcissement d'URL de réseaux sociaux) avant d'arriver sur votre site Web.
Vous devez vous concentrer sur l'élimination des redirections d'origine identique, car vous aurez un contrôle direct sur ce point. Vous devrez pour cela vérifier les liens de votre site Web pour voir si l'un d'entre eux génère 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 finales ne sont pas correctement incluses ou exclues dans l'URL.
Les redirections multi-origines sont plus délicates, car elles sont souvent indépendantes de votre volonté. 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 correcte, afin de ne pas ajouter une autre redirection à celles utilisées par ces services.
Les redirections HTTP vers HTTPS constituent une autre 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 schéma HTTPS lors de vos prochaines visites.
Une fois que vous avez mis en place une règle HSTS appropriée, vous pouvez accélérer le processus lors de 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 efficacement le balisage lors de sa diffusion, ce qui signifie que le balisage est géré en fragments à mesure qu'il arrive du serveur. Cette étape est essentielle en cas de charges utiles de balisage volumineuses, car cela signifie que le navigateur peut analyser les blocs de balisage de manière incrémentielle, au lieu d'attendre l'arrivée de la réponse complète avant de pouvoir commencer l'analyse.
Bien que les navigateurs soient très efficaces pour gérer le balisage de flux, il est essentiel de faire tout ce que vous pouvez pour que ce flux continue de s'exécuter afin que ces premiers éléments de balisage soient disponibles dès que possible. Si le backend bloque les choses, c'est un problème. Étant donné que les piles de backend sont nombreuses, ce guide ne traite pas de chacune d'elles ni des problèmes qui peuvent survenir dans chacune d'elles.
Par exemple, React, ainsi que d'autres frameworks permettant d'afficher le balisage à la demande sur le serveur, ont utilisé une approche synchrone de l'affichage côté serveur. Toutefois, les versions plus récentes de React ont implémenté des méthodes de serveur pour le balisage des diffusions lors de l'affichage. Cela signifie que vous n'avez pas à attendre qu'une méthode 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. Avec le fichier complet disponible immédiatement, les serveurs Web peuvent commencer à envoyer le fichier immédiatement, et la nature inhérente du protocole HTTP entraîne un balisage de flux. 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 bénéfique pour les pages qui ne nécessitent pas de balisage afin d'ê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 pour les documents et les ressources qu'ils chargent. Cela est dû au fait qu'un service worker agit en tant que proxy entre le navigateur et le serveur. L'impact sur le TTFB de votre site Web dépend toutefois de la manière dont vous avez configuré votre service worker, et de la conformité de cette configuration avec les exigences de votre application.
- Utilisez une stratégie de validation non actualisée pour les assets. 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" traite 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 ultérieures.
- Si les ressources de vos documents ne changent pas souvent, l'utilisation d'une stratégie "obsolète pendant la revalidation" peut rendre le TTFB d'une page presque instantané. Toutefois, cette méthode ne fonctionne pas très bien si votre site Web envoie un balisage généré dynamiquement, tel qu'un balisage qui change selon que l'utilisateur est authentifié ou non. Dans ce cas, vous devez toujours appeler le réseau en premier, afin que le document soit le plus à jour possible.
- Si votre document charge des ressources non critiques qui changent à une certaine fréquence, mais que l'extraction de la ressource obsolète n'affectera pas grandement l'expérience utilisateur, comme la sélection d'images ou d'autres ressources non critiques, le TTFB pour ces ressources peut être considérablement réduit à l'aide d'une stratégie de revalidation obsolète.
- Utilisez le modèle shell d'application pour les applications affichées par le client. Ce modèle convient mieux aux applications monopages où le "shell" de la page peut être diffusé instantanément depuis le 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
Quelle que soit la qualité de l'optimisation du backend de votre application, le serveur peut encore 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 l'arrivée de la réponse de navigation aussi rapidement qu'elle le pourrait. En conséquence, certaines ressources critiques ultérieures peuvent être retardées, comme les ressources CSS ou, dans certains cas, JavaScript qui affichent le balisage sur le client.
L'en-tête 103 Early Hints est un code de réponse précoce 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 critiques pour le rendu que la page doit commencer à télécharger pendant la préparation du balisage. Pour les navigateurs compatibles, cela peut se traduire par un rendu du document (CSS) plus rapide et une disponibilité plus rapide des fonctionnalités de base de la page (JavaScript).
Conclusion
Étant donné qu'il existe un grand nombre de combinaisons de piles d'applications backend, aucun article ne peut encapsuler tout ce que vous pouvez faire pour réduire le délai d'affichage de votre site Web. Toutefois, voici quelques options que vous pouvez envisager pour accélérer un peu plus les opérations côté serveur.
Comme pour l'optimisation de toutes les métriques, l'approche est en grande partie similaire: mesurez votre TTFB sur le terrain, utilisez les outils de l'atelier pour identifier les causes, puis appliquez des optimisations lorsque cela est possible. Certaines des techniques présentées ici ne sont pas forcément adaptées à votre situation, mais certaines le seront. Comme toujours, vous devez surveiller de près vos données de terrain et procéder à des ajustements si nécessaire pour garantir une expérience utilisateur la plus rapide possible.
Image principale de Taylor Vick, tirée de Unsplash.