Optimiser le délai avant le premier octet

Découvrez comment optimiser la métrique "Time to First Byte".

Jeremy Wagner

Barry Pollard

Time to First Byte (TTFB) est une métrique fondamentale sur les performances Web qui précède toute autre métrique significative sur 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 afin que le 75e centile des utilisateurs obtiennent un FCP sous le seuil "satisfaisant". À titre indicatif, la plupart des sites doivent s'efforcer d'avoir un TTFB de 0,8 seconde ou moins.

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 réelles comme source principale d'observation du TTFB, car il est affecté par les redirections. En revanche, les outils basés sur des fonctionnalités expérimentales sont souvent mesurés à l'aide de l'URL finale.

PageSpeed Insights est un moyen simple d'obtenir des informations sur le terrain et les ateliers concernant les sites Web publics. Ces informations sont disponibles dans le rapport sur l'expérience utilisateur de Chrome.

Pour les utilisateurs réels, le TTFB est affiché dans la section Découvrez l'expérience de vos utilisateurs réels:

Un sous-ensemble de 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 dans l'atelier, consultez la page des métriques TTFB.

Comprendre un TTFB élevé avec Server-Timing

Vous pouvez utiliser l'en-tête de réponse Server-Timing dans le backend de votre application pour mesurer des processus 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 handle que vous définissez. Les valeurs facultatives incluent une valeur de durée (via dur) et une description lisible par l'humain (via desc).

Serving-Timing permet de mesurer de nombreux processus de backend d'application, mais vous pouvez accorder une attention particulière à certains d'entre eux:

• Requêtes de base de données
• Délai d'affichage côté serveur, le cas échéant
• Recherches de disque
• Succès/échecs de 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 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

Vous pouvez définir l'en-tête en utilisant le langage de votre backend d'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 ayant un ensemble d'en-têtes de réponse Server-Timing renseignera 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 seront visualisées dans le panneau de temps de l'onglet Network (Réseau) des outils pour les développeurs Chrome:

En-têtes de réponse Server-Timing visualisés dans l'onglet "Réseau" des outils pour les développeurs Chrome. Ici, Server-Timing permet de mesurer si une requête pour une ressource a atteint le cache CDN, et le temps nécessaire pour que la requête arrive sur le serveur périphérique du CDN, puis sur l'origine.

Une fois que vous avez déterminé que vous avez un problème TTFB en analysant les données disponibles, vous pouvez passer à la résolution du problème.

Méthodes d'optimisation de TTFB

L'aspect le plus difficile de l'optimisation du TTFB est que, même si la pile frontend du Web sera toujours HTML, CSS et JavaScript, les piles backend peuvent varier considérablement. Il existe de nombreuses piles de backend et produits de base de données, 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 à la plate-forme

La plate-forme que vous utilisez pour votre site Web peut avoir un impact important sur 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 affectées de la même manière. Nous vous invitons à consulter la documentation de votre plate-forme pour obtenir des conseils spécifiques à votre fournisseur, en complément des conseils plus généraux sur les performances présentés dans cet article. L'audit Lighthouse destiné à 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, l'hébergement doit être la première chose à prendre en compte. Il n'y a pas grand-chose à fournir dans ce cas de figure. Toutefois, en règle générale, assurez-vous que l'hôte de votre site Web est en mesure 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, ce n'est probablement pas un problème. Certaines des techniques d'optimisation suivantes vous aideront à réduire au maximum l'impact de cette balise.

Toutefois, si vous exécutez une application de grande envergure impliquant un grand nombre d'utilisateurs et impliquant une personnalisation, des requêtes 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.

Lorsque vous choisissez un fournisseur d'hébergement, vous devez tenir compte des points suivants:

• Quelle est la quantité de mémoire allouée à votre instance d'application ? Si votre application ne dispose pas de suffisamment de mémoire, elle risque de se bloquer et de tenter d'accélérer l'affichage des pages.
• Votre fournisseur d'hébergement maintient-il à jour votre pile backend ? À mesure que de nouvelles versions des langages de backend d'applications, des implémentations HTTP et des logiciels de base de données sont 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 crucial.
• Si vous avez des exigences d'application très spécifiques et souhaitez disposer du niveau d'accès le plus bas aux fichiers de configuration du serveur, demandez s'il est judicieux de personnaliser le backend de votre propre instance d'application.

De nombreux fournisseurs d'hébergement s'occupent de ces aspects à votre place. Toutefois, si vous commencez à observer de longues valeurs TTFB, même chez des fournisseurs d'hébergement dédiés, cela peut être le signe 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 concernant l'utilisation des CDN est déjà bien utilisé, mais à juste titre: vous pourriez 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 proximité entre les utilisateurs et votre serveur d'origine en utilisant un réseau distribué de serveurs qui mettent en cache des ressources sur des serveurs physiquement plus proches de vos utilisateurs. Ces serveurs sont appelés serveurs périphériques.

Les fournisseurs CDN peuvent également offrir des avantages au-delà des serveurs périphériques:

• Les fournisseurs CDN proposent généralement des temps de résolution DNS extrêmement rapides.
• Un CDN diffusera probablement votre contenu à partir de serveurs périphériques utilisant des protocoles modernes tels que HTTP/2 ou HTTP/3.
• Le protocole 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 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 CDN proposent une fonctionnalité souvent appelée "nœud de calcul de périphérie", qui utilise une API semblable à celle de l'API Service Worker pour intercepter les requêtes, gérer de manière automatisée les réponses dans des caches périphériques ou réécrire les réponses.
• Les fournisseurs CDN sont très efficaces pour optimiser la compression. La compression est une opération délicate et peut, dans certains cas, ralentir les temps de réponse avec le balisage généré de façon dynamique, qui doit être compressé à la volée.
• De plus, les fournisseurs CDN mettent automatiquement en cache les réponses compressées pour les ressources statiques, ce qui permet d'optimiser le taux de compression et le temps de réponse.

Bien que l'adoption d'un CDN implique des efforts variables, allant de simples à importants, il est primordial d'optimiser votre TTFB 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 du contenu sur des serveurs en périphérie qui sont physiquement plus proches 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 les contenus personnalisés, exiger un trajet jusqu'à l'origine peut faire perdre 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. En effet, seul le premier visiteur au cours de cette période connaît la latence totale de retour au serveur d'origine, tandis que tous les autres visiteurs peuvent réutiliser la ressource mise en cache depuis le serveur périphérique. Certains CDN autorisent l'invalidation du cache sur les versions du site permettant le meilleur des deux mondes : de longs temps de mise en cache, mais des mises à jour instantanées si nécessaire.

Même si la mise en cache est correctement configurée, cela peut être ignoré via l'utilisation de paramètres de chaîne de requête uniques pour les mesures analytiques. Bien qu'ils soient identiques, le contenu peut sembler différent pour le CDN. Par conséquent, la version mise en cache ne sera 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. L'augmentation des temps de mise en cache peut réduire l'impact de ce phénomène, mais sachez qu'avec un temps de mise en cache plus long, vous avez plus de chances de diffuser du contenu potentiellement obsolète.

L'impact du contenu mis en cache n'affecte pas seulement ceux qui utilisent des CDN. Lorsque le contenu mis en cache ne peut pas être réutilisé, l'infrastructure de serveurs peut avoir besoin de générer du contenu à partir de recherches coûteuses dans la base de données. Les données consultées plus fréquemment ou les pages en pré-cache sont souvent plus performantes.

Éviter les redirections de pages multiples

Les redirections contribuent fréquemment à un TTFB. Une redirection se produit 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 certes ajouter une latence indésirable à une requête de navigation, mais elle risque d'empirer si cette redirection pointe vers une autre ressource qui entraîne une autre redirection, et ainsi de suite. Cela peut avoir un impact particulièrement important sur les sites qui reçoivent un grand nombre de visiteurs à partir des publicités ou des newsletters, car ils redirigent souvent les utilisateurs vers des services d'analyse à des fins d'évaluation. L'élimination des redirections sous votre contrôle direct peut vous aider à atteindre un TTFB de qualité.

Il existe deux types de redirections:

• Redirections de même origine, où la redirection se produit entièrement sur votre site Web.
• Les redirections multi-origines, où la redirection se produit initialement sur une autre origine (par exemple, à partir d'un service de raccourcissement d'URL de réseaux sociaux) avant d'accéder à votre site Web.

Vous souhaitez vous concentrer sur l'élimination des redirections de même origine, car vous avez un contrôle direct sur ces redirections. Pour cela, vous devez 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 souvent être dû au fait que le schéma https:// n'est pas inclus (les navigateurs utilisent par défaut http://, qui redirige ensuite les utilisateurs) ou que les barres obliques finales ne sont pas incluses ou exclues de manière appropriée dans l'URL.

Les redirections multi-origines sont plus complexes, car elles sont souvent hors de votre contrôle. Essayez cependant d'éviter d'en créer plusieurs 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 la bonne URL finale, afin de ne pas ajouter d'autre redirection vers celles utilisées par ces services.

Les redirections HTTP vers HTTPS peuvent également constituer une source importante de délai 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 sur 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 règle HSTS efficace, vous pouvez accélérer les choses lors de la première visite vers une origine en ajoutant votre site à la liste de préchargement HSTS.

Balisage de flux dans le navigateur

Les navigateurs sont optimisés pour traiter efficacement le balisage lorsqu'il est diffusé en streaming, ce qui signifie que le balisage est traité par blocs à mesure qu'il arrive sur le serveur. C'est essentiel en cas de charges utiles de balisage volumineuses, car cela signifie que le navigateur peut analyser ces fragments de balisage de manière incrémentielle, au lieu d'attendre l'arrivée de la réponse complète avant de commencer l'analyse.

Bien que les navigateurs soient doués pour gérer le balisage de flux, il est essentiel de faire le maximum pour que ce flux reste fluide afin que ces éléments de balisage initiaux soient envoyés 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 chaque pile et des problèmes qui peuvent survenir dans chacune d'elles.

Par exemple, React, et d'autres frameworks permettant d'afficher le balisage à la demande sur le serveur, ont utilisé une approche synchrone pour l'affichage côté serveur. Toutefois, les versions plus récentes de React implémentent des méthodes de serveur pour le balisage de flux pendant son rendu. Cela signifie que vous n'avez pas besoin d'attendre qu'une méthode API du serveur React affiche l'intégralité de la réponse avant de l'envoyer.

Pour vous assurer que le balisage est rapidement diffusé dans le navigateur, vous pouvez également utiliser l'affichage statique, qui génère des fichiers HTML au moment de la compilation. Lorsque le fichier complet est disponible immédiatement, les serveurs Web peuvent commencer à envoyer le fichier immédiatement et, par nature, le protocole HTTP entraîne le balisage en flux continu. Bien que cette approche ne soit pas adaptée à toutes les pages de tous les sites Web (par exemple, celles nécessitant 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 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, tant pour les documents que pour les ressources qu'ils chargent. En effet, un service worker agit en tant que 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 de type "obsolète pendant la revalidation" 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 depuis le cache, puis télécharge cet élément en arrière-plan et le diffuse à partir du cache pour de futures interactions.
  • Si vous disposez de ressources de document qui ne changent pas très souvent, l'utilisation d'une stratégie de revalidation obsolète 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é de façon dynamique, par exemple un balisage qui change selon que l'utilisateur est authentifié ou non. Dans ce cas, vous devez toujours atteindre le réseau en premier, afin que le document soit aussi à jour que possible.
  • Si votre document charge des ressources non critiques qui changent régulièrement, mais que la récupération des ressources obsolètes n'affecte pas grandement l'expérience utilisateur (comme des images sélectionnées ou d'autres ressources non essentielles), le TTFB de ces ressources peut être considérablement réduit à l'aide d'une stratégie obsolète qui n'est pas actualisée.
• Si possible, utilisez une architecture de service worker de streaming. Cette architecture de service worker utilise une approche dans laquelle des parties d'une ressource de document sont stockées dans le cache du service worker et combinées à des partiels de contenu lors de la requête de navigation. L'utilisation de ce modèle de service worker a pour effet de rendre la navigation assez rapide, tandis que des charges utiles HTML plus petites sont téléchargées à partir du réseau. Bien que ce modèle de service worker ne fonctionne pas pour tous les sites Web, les temps TTFB pour les ressources de document peuvent être pratiquement instantanés pour les sites qui peuvent l'utiliser.
• Utilisez le modèle de shell d'application pour les applications affichées par le client. Ce modèle est particulièrement adapté aux applications monopages, où l'interface système de la page peut être diffusée instantanément depuis le cache du service worker, et 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 le rendu

Quelle que soit la qualité de l'optimisation du backend de votre application, le serveur peut tout de même effectuer un travail important pour préparer une réponse, y compris un travail de base de données coûteux (encore nécessaire) qui retarde l'arrivée de la réponse de navigation aussi rapidement que possible. Cela peut avoir pour effet de retarder certaines ressources importantes pour l'affichage, telles que CSS ou, dans certains cas, JavaScript qui affiche le balisage sur le client.

L'en-tête 103 Early Hints est un code de réponse anticipée 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 que la page doit commencer à télécharger des ressources essentielles lors de la préparation du balisage. Pour les navigateurs compatibles, l'affichage des documents (CSS) est ainsi plus rapide et la fonctionnalité principale de la page (JavaScript) disponible.

Conclusion

Étant donné qu'il existe un grand nombre de combinaisons de piles d'applications backend, il n'existe pas d'article unique capable d'encapsuler tout ce que vous pouvez faire pour réduire le TTFB de votre site Web. Cependant, voici quelques options que vous pouvez explorer pour essayer de faire avancer les choses un peu plus rapidement côté serveur.

Comme pour l'optimisation de chaque métrique, l'approche est très similaire: mesurez votre TTFB sur le terrain, utilisez les outils de l'atelier pour explorer les causes, puis appliquez les optimisations lorsque cela est possible. Certaines techniques ne sont peut-être pas adaptées à votre situation, mais certaines le seront. Comme toujours, vous devrez surveiller de près vos données réelles et effectuer les ajustements nécessaires pour garantir une expérience utilisateur aussi rapide que possible.

Image héros de Taylor Vick, provenant de Unsplash.