Qu'est-ce que le Time To First Byte (TTFB) et comment l'améliorer

Qu'est-ce que le Time to First Byte

Le Time-to-First Byte (TTFB) indique combien de temps s'est écoulé en millisecondes entre le début de la requête et la réception de la première réponse (octet) d'une page web. Le TTFB est donc aussi appelé le temps d'attente. Le TTFB est un moyen de mesurer certaines parties de la vitesse d'une page web. Le TTFB est une métrique fondamentale, ce qui signifie que le temps ajouté au TTFB sera également ajouté au Largest Contentful Paint et au First Contentful Paint.

Pourquoi le Time to First Byte est-il important

Le Time to First Byte n'est pas un Core Web Vital et il est tout à fait possible de réussir les Core Web Vitals tout en échouant à la métrique TTFB. Cela ne signifie pas que le TTFB n'est pas important. Le TTFB est une métrique extrêmement importante à optimiser et corriger le TTFB améliorera grandement la vitesse de la page et l'expérience de la page !

L'impact du TTFB pour les visiteurs

Le Time to First Byte précède toutes les autres métriques de peinture. Pendant que le navigateur attend le Time to First Byte, le navigateur ne peut rien faire et affichera simplement un écran blanc ! Cela signifie que toute augmentation du Time to First Byte entraînera un temps d'écran blanc supplémentaire et toute diminution du Time to First Byte se traduira par moins de temps d'écran blanc.

Pour obtenir cette "sensation de chargement instantané des pages", le Time to First Byte doit être aussi rapide que possible !

Pourquoi le TTFB n'est-il pas un Core Web Vital ? Le TTFB ne tient pas compte du rendu : Un TTFB faible ne signifie pas nécessairement une bonne expérience utilisateur car il ne prend pas en compte le temps nécessaire au navigateur pour rendre la page web. Même si tous les octets sont téléchargés rapidement, la page web peut encore prendre beaucoup de temps à s'afficher si le navigateur doit traiter beaucoup de JavaScript ou rendre des mises en page complexes.

Qu'est-ce qu'un bon score TTFB ?

Il est recommandé que votre serveur réponde aux demandes de navigation assez rapidement pour que le 75e percentile des utilisateurs fasse l'expérience d'un FCP dans le seuil "bon". En règle générale, la plupart des sites devraient s'efforcer d'avoir un TTFB de 0,8 seconde ou moins.

• un TTFB inférieur à 800 millisecondes est considéré comme bon.
• un TTFB entre 800 et 1800 millisecondes nécessite une amélioration
  
• un TTFB supérieur à 1800 millisecondes est considéré comme médiocre et doit être amélioré immédiatement

Le TTFB de la requête à la réponse

Du navigateur au serveur : La requête

Le temps de requête du navigateur est le temps écoulé entre le moment où le navigateur d'un utilisateur envoie une requête HTTP et le moment où cette requête atteint le serveur hébergeant le site web. Le TTFB de cette partie échappe largement au contrôle direct du site web et dépend fortement de

• La vitesse internet de l'utilisateur.
• La qualité de leur infrastructure réseau.
• La distance physique entre l'utilisateur et le serveur.○

Au cours de cette étape,  la recherche DNS, le temps de démarrage du navigateur, les recherches dans le cache du navigateur et la négociation de la connexion au serveur (TCP & TSL) prennent tous un peu de temps.

Sur le serveur : Traitement et préparation de la réponse

Une fois que le serveur reçoit la requête, l'horloge tourne pendant qu'il travaille à générer une réponse. C'est sur cette étape que la plupart des développeurs ont tendance à se concentrer et où  les efforts d'optimisation peuvent avoir l'impact le plus significatif. Les facteurs à prendre en compte incluent :

• Capacités du serveur : Matériel puissant (CPU, RAM), logiciel efficace (serveur web, base de données) et configurations optimisées comptent tous.
  
• Durée de la base de données : Si la requête nécessite de récupérer des données d'une base de données, des requêtes lentes peuvent être un goulot d'étranglement majeur.
• Optimisation du code : Un code côté serveur mal écrit (par ex. scripts inefficaces) peut entraîner de longs temps de traitement.
• Stratégies de mise en cache : Une mise en cache efficace (comme la mise en cache côté serveur ou l'utilisation d'un Content Delivery Network - CDN) peut réduire considérablement la charge de traitement pour les requêtes répétées.

Retour au navigateur : Livraison du premier octet

Après traitement, le serveur renvoie la réponse, commençant par le premier octet, au navigateur de l'utilisateur. 

• Comme pour la première étape, les conditions du réseau et la distance jouent également un rôle ici. 
• Les CDN sont particulièrement bénéfiques à cette étape car ils mettent en cache le contenu plus près des utilisateurs, minimisant le temps de trajet.
  
• Les redirections sont servies à ce stade, ce qui fait répéter le processus avec un délai supplémentaire.

Étapes techniques du Time To First Byte

Similaire au 'chemin de la requête à la réponse' dans votre navigateur, le Time To First Byte des requêtes de navigation peut être mesuré avec l' API Navigation Timing et décomposé en 5 sous-parties.

1. Temps de redirection : lorsqu'une ressource a été déplacée vers un nouvel emplacement, le temps de redirection s'ajoute à son TTFB.
2. Temps Worker & Cache : avant qu'une ressource ne soit récupérée sur internet, un navigateur essaiera d'abord de regarder dans son propre cache ou via un worker (si un worker a été configuré)
3. Temps de recherche DNS : Ensuite, un navigateur peut avoir besoin d'effectuer une recherche DNS pour traduire le nom de domaine (www.example.com) en une adresse IP
4. Temps de connexion TCP : Ensuite, le navigateur se connectera au serveur et effectuera quelques vérifications
5. Handshake SSL : Ensuite, le navigateur et le serveur chiffreront leur communication
6. Réponse du serveur : Enfin, le serveur doit envoyer le HTML. Il peut avoir besoin de générer le HTML d'abord.

Comment mesurer le Time To First Byte TTFB

Astuce PageSpeed : chaque ressource a son propre Time to First Byte. Dans ce contexte cependant, nous parlons du Time to First Byte de la page principale !

Le Time to First Byte peut grandement fluctuer entre différents utilisateurs avec différents appareils et depuis différents endroits. C'est pourquoi l'auto-mesure du Time to First Byte depuis votre ordinateur de bureau n'est probablement pas une bonne idée. Utiliser des outils comme pingdom ou GTMetrix n'est pas fiable pour la même raison.

La meilleure façon de mesurer le Time To First Byte est de collecter des données Real User Metrics (RUM) auprès de vos visiteurs. Vous pouvez le faire vous-même avec ce code ou utiliser un outil RUM comme CoreDash

Mesurer le TTFB avec des outils synthétiques

Mesurer le TTFB avec le suivi RUM

Mesurer le TTFB avec les données CrUX

CrUX (Chrome User Experience Report) est un jeu de données publiquement disponible par Google qui contient des données de performance du monde réel pour les sites web. Google utilise le jeu de données CrUX pour déterminer si vous passez ou non les Core Web Vitals.

Le jeu de données CrUX peut être consulté via des outils comme PageSpeed Insights, l'API CrUX, Looker Studio ou Google BigQuery. Utilisez l'un de ces outils pour obtenir le TTFB pour votre site.

Mesurer le TTFB avec JavaScript

Pour mesurer le Time to First Byte (TTFB) avec JavaScript, vous pouvez utiliser l'API Navigation Timing.  Vous pouvez créer un PerformanceObserver qui écoute une entrée de navigation et journalise la propriété responseStart dans la console. La propriété responseStart représente l'horodatage où le premier octet de la réponse a été reçu. La bibliothèque JavaScript web-vitals  fournit un moyen plus concis de mesurer le TTFB dans le navigateur en utilisant la fonction onTTFB.

Le code ci-dessous peut être utilisé pour mesurer le Time To First Byte (TTFB)

const formatTime = (time) => {

//arrondir à 2 décimales, utiliser Math.round() pour un entier
return Math.round(time * 100) / 100;
};

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');

// les temps de démarrage sont relatifs
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution basée sur https://www.w3.org/TR/navigation-timing-2/#processing-model
// utiliser un tableau associatif pour journaliser les résultats de manière plus lisible
let attributionArray = [];
attributionArray['Temps de redirection'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Temps Worker et Cache'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['Temps DNS'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['Temps TCP'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['Temps SSL'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Temps Requête'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['TTFB Total'] = { 'time in ms': formatTime(responseStart - activationStart) };

// journaliser les résultats
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cEntrée de navigation originale', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

Trouver les goulots d'étranglement avec Server Timing

Server Timings fournit un moyen d'envoyer des temps de performance du serveur backend au navigateur. En utilisant Server Timings, les développeurs peuvent mesurer et analyser efficacement les composants côté serveur contribuant au TTFB, aidant à identifier les domaines d'optimisation et à améliorer la performance globale du site web.

L'en-tête Server-Timing peut avoir des temps pour plusieurs métriques séparées par des virgules :

Un nom court pour la métrique (tel que database et traitement)
Une durée en millisecondes (exprimée comme dur=123)
Une description (exprimée comme desc="Ma Description")

Server-Timing: database;dur=123, processing;dur=234

Un navigateur peut maintenant lire l'en-tête server timings. Ces en-têtes server timings peuvent être envoyés à votre outil RUM préféré comme CoreDash

Comment l'hébergement affecte-t-il le Time to First Byte ?

L'hébergement affecte le Time to First Byte de plusieurs façons. En investissant dans un meilleur hébergement, il est généralement possible d'améliorer immédiatement le Time to First Byte sans rien changer d'autre. Surtout en passant d'un hébergement partagé à petit budget à des serveurs virtuels correctement configurés et gérés, le TTFB pourrait s'améliorer considérablement.

Astuce Hébergement : un meilleur hébergement implique un traitement plus rapide, une meilleure vitesse de réseau et plus de mémoire serveur, plus rapide. Un hébergement coûteux n'est pas toujours synonyme de meilleur hébergement ! De nombreuses mises à niveau sur les services d'hébergement partagé ne vous donnent que plus de stockage, pas plus de puissance CPU

Je ne recommande pas de changer d'hébergement sans connaître les causes profondes des problèmes de TTFB. Je vous conseille de mettre en place un suivi RUM & d'ajouter des en-têtes server timing.

Lorsque vous mettez à niveau votre hébergement, vous devriez généralement rechercher au moins 1 de ces 3 améliorations :

• Obtenir plus de ressources (CPU + RAM) : Surtout quand le serveur met trop de temps à générer le HTML dynamique.
• DNS plus rapide : De nombreux fournisseurs d'hébergement à petit budget sont connus pour leur mauvaise performance DNS
  
• Meilleure configuration : Recherchez des chiffrements SSL plus rapides, HTTP/3, la compression Brotli, l'accès à la configuration du serveur web (pour désactiver les modules inutiles) pour n'en nommer que quelques-uns.
  

Comment améliorer le TTFB - Accélérer la connexion initiale

Un Time to First Byte élevé peut avoir plusieurs causes. Cependant, le DNS, le TCP et le SSL affectent tous les Time to First Byte. Commençons donc par là. Même si l'optimisation de ces 3 ne donne pas les plus grands résultats, les optimiser optimisera chaque TTFB !

Accélérer le DNS

Astuce PageSpeed : DNS TCP & SSL sont généralement un problème plus important lorsque vous utilisez un hébergeur bon marché ou lorsque vous servez un public mondial tout en n'utilisant pas de CDN. Utilisez le suivi RUM pour voir votre TTFB mondial et décomposez le TTFB en ses sous-parties

Utilisez un Fournisseur DNS Rapide. Tous les fournisseurs DNS ne sont pas aussi rapides les uns que les autres. Certains fournisseurs DNS (gratuits) sont simplement plus lents que d'autres fournisseurs DNS (gratuits). CloudFlare par exemple vous donnera l'un des fournisseurs DNS les plus rapides au monde gratuitement !

Augmentez le TTL DNS. Une autre façon est d'augmenter la valeur Time to Live (TTL). Le TTL est un paramètre qui détermine combien de temps la recherche peut être mise en cache. Plus le TTL est élevé, moins il est probable que le navigateur ait besoin d'effectuer une autre recherche DNS. Il est important de noter que les FAI mettent également en cache le DNS.

Accélérer le TCP

La 'partie TCP' du TTFB est la connexion initiale au serveur web. Lors de la connexion, le navigateur et le serveur partagent des informations sur la façon dont les informations seront échangées. Vous pouvez accélérer le TCP en vous connectant à un serveur géographiquement proche de votre emplacement et en vous assurant que le serveur a suffisamment de ressources libres. Parfois, passer à un serveur léger comme NGINX peut accélérer la partie TCP du TTFB. Dans de nombreux cas, l'utilisation d'un CDN accélérera la connexion TCP !

Accélérer SSL/TSL

Une fois la connexion TCP établie, le navigateur et le serveur devront sécuriser votre connexion par chiffrement. Vous pouvez accélérer cela en utilisant des protocoles plus rapides, plus récents et plus légers (SSL Ciphers) et en étant géographiquement plus proche de votre serveur web (puisque la négociation TSL prend pas mal d'allers-retours). L'utilisation d'un CDN améliorera souvent le temps de connexion SSL car ils sont souvent très bien configurés et ont plusieurs serveurs partout dans le monde. TLS 1.3 en particulier est conçu pour garder la négociation TLS aussi courte que possible.

Comment améliorer le TTFB - Accélérer le côté serveur

Mise en cache de page

De loin le moyen le plus efficace d'accélérer le Time to First Byte est de servir le HTML depuis le cache du serveur. Il existe plusieurs façons de mettre en œuvre la mise en cache de page complète. La manière la plus efficace est de le faire directement au niveau du serveur web avec par exemple le module de mise en cache NGINX ou en utilisant Varnish comme proxy inverse de mise en cache.

Il existe également de nombreux plugins pour différents systèmes CMS qui mettront en cache des pages complètes et de nombreux frameworks SPA comme NextJS ont leur propre implémentation de mise en cache de page complète ainsi que différentes stratégies d'invalidation.

Si vous souhaitez implémenter votre propre mise en cache, l'idée de base est super simple. Lorsqu'un client demande une page, vérifiez si elle existe dans le dossier de cache. Si elle n'existe pas, créez la page, écrivez-la dans le cache et affichez la page comme vous le feriez normalement. Lors de toute demande suivante pour la page, le fichier de cache existera et vous pourrez servir la page directement depuis le cache.

Mise en cache partielle

Avec la mise en cache partielle, l'idée est de mettre en cache les parties fréquemment utilisées, lentes ou coûteuses de la page ou des ressources (comme les appels API, les résultats de base de données) pour une récupération rapide. Cela éliminera les goulots d'étranglement lors de la génération d'une page. Si vous êtes intéressé par ces types d'optimisations (vous devriez l'être !!), recherchez ces concepts : Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache et Opcode Cache.

Optimiser le code de l'application

Parfois, la page ne peut pas être servie depuis le cache (partiel) car le fichier de cache n'existe pas, de grandes parties des pages sont dynamiques ou parce que vous rencontrez d'autres problèmes. C'est pourquoi nous devons optimiser le code de l'application. Comment cela est fait dépend entièrement de votre application. Cela repose sur la réécriture et l'optimisation des parties lentes de votre code.

Optimiser les requêtes de base de données

La plupart du temps, les requêtes de base de données inefficaces sont la cause première d'un Time to First Byte lent. Commencez par journaliser les 'requêtes lentes' et les 'requêtes n'utilisant pas d'index' sur le disque. Analysez-les, ajoutez des index ou demandez à un expert d'effectuer un réglage de base de données pour corriger ces problèmes. Voir https://www.mongodb.com/docs/atlas/performance-advisor/ et https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html

Réduire la latence du réseau interne

Une mauvaise pratique que je rencontre plus de fois que je ne le voudrais est un délai dans le Time to First Byte causé par la lenteur de la communication entre l'application web et le stockage de données. Cela ne se produit généralement qu'avec les grands sites qui ont externalisé leur stockage de données vers des API cloud.

Comment améliorer le TTFB - Accélérer le côté client

Mise en cache côté client

La mise en cache côté client implique que le navigateur de l'utilisateur stocke les ressources auxquelles il a déjà accédé, comme les images et les scripts. Ainsi, lorsque l'utilisateur revient sur votre site web, son navigateur peut récupérer rapidement les ressources mises en cache au lieu de devoir les télécharger à nouveau. Cela peut réduire considérablement le nombre de requêtes faites au serveur, ce qui peut à son tour réduire le TTFB.

Pour implémenter la mise en cache côté client, vous pouvez utiliser l'en-tête HTTP Cache-Control. Cet en-tête vous permet de spécifier combien de temps le navigateur doit mettre en cache une ressource particulière.

Vous pourriez envisager de mettre entièrement en cache le HTML de la page côté client. Cela réduira considérablement le TTFB puisque nous n'avons plus besoin de requête. L'inconvénient est qu'une fois la page dans le cache du navigateur, toute mise à jour sur la version live de la page ne sera pas vue par l'utilisateur jusqu'à ce que le cache de la page expire.

Service Workers

Les service workers sont des scripts qui s'exécutent en arrière-plan du navigateur d'un utilisateur et peuvent intercepter les requêtes réseau faites par le navigateur. Cela signifie que les service workers peuvent mettre en cache des ressources comme le html, les images, les scripts et les feuilles de style, de sorte que lorsque l'utilisateur revient sur votre site web, son navigateur peut récupérer rapidement les ressources mises en cache au lieu de devoir les télécharger à nouveau.

API Speculation Rules

L'API Speculation Rules est conçue pour améliorer les performances des futures navigations. Une fois qu'un visiteur a atterri sur votre page, vous pouvez utiliser les speculationrules pour demander à un navigateur de récupérer (avec la directive prefetch) ou même de rendre (avec la directive prerender) les pages que le visiteur est le plus susceptible de visiter. L'API Speculation Rules est plus flexible et configurable que la méthode link prefetch.

Jetez un œil à cet exemple où le navigateur reçoit l'instruction de précharger l'url dans la barre de menu pour une future navigation, la gardant en mémoire afin qu'elle puisse être utilisée pour accélérer la prochaine navigation.

<script type="speculationrules">
{"prerender": 
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

Préchargement de page

Si vous ne voulez pas utiliser l'API Speculation Rules en raison de son faible support navigateur ou vous pourriez utiliser un petit script appelé quicklink. Cela préchargera tous les liens dans la fenêtre visible et éliminera pratiquement le Time To First Byte pour ces liens !

L'inconvénient des quicklinks est qu'il nécessite plus de ressources navigateur mais pour l'instant il surpassera l'API Speculation Rules.

Comment améliorer le TTFB - tirer parti d'un CDN

Un Content Delivery Network ou CDN utilise un réseau distribué de serveurs pour livrer des ressources aux utilisateurs. Ces serveurs sont généralement géographiquement plus proches des utilisateurs finaux et super-optimisés pour la vitesse.

T
TTFB avec un CDN et mise en cache en périphérie

T
TTFB sans CDN hébergé en Allemagne

Un CDN peut aider à améliorer 5 des 6 parties du Time to First Byte :

• Temps de redirection : La plupart des CDN peuvent mettre en cache les redirections en périphérie ou utiliser des edge workers pour gérer les redirections sans avoir besoin de se connecter au serveur d'origine.
• Temps de recherche DNS : La plupart des CDN offrent des serveurs DNS extrêmement rapides qui surpasseront probablement vos serveurs DNS actuels
  
• Temps de connexion TCP & Temps de Handshake SSL. La plupart des CDN sont configurés extrêmement bien et ces configurations, ainsi que la proximité plus étroite avec les utilisateurs finaux, accéléreront le temps de connexion + handshake
  
• Réponse du serveur : Les CDN peuvent accélérer le temps de réponse du serveur de deux manières. La première est en mettant en cache la réponse du serveur en périphérie (full page edge caching) mais aussi en offrant une excellente compression (Brotli) et les protocoles les plus récents (HTTP/3)

Comment améliorer le TTFB - Éviter les redirections

Le temps de redirection est ajouté au Time To First Byte. Par conséquent, en règle générale, évitez autant que possible les redirections. Les redirections peuvent se produire lorsqu'une ressource n'est plus disponible à un emplacement mais déplacée vers un autre emplacement. Le serveur répondra avec un en-tête de réponse de redirection et le navigateur essaiera ce nouvel emplacement.

Redirections de même origine. Les redirections de même origine proviennent de liens sur votre propre site web. Vous devriez avoir un contrôle total sur ces liens et vous devriez prioriser la correction de ces liens lorsque vous travaillez sur le Time to First Byte. Il existe de nombreux outils qui vous permettront de vérifier tout votre site web pour les redirections

Redirections d'origine croisée. Les redirections d'origine croisée proviennent de liens sur d'autres sites web. Vous avez très peu de contrôle sur ceux-ci.

Redirections multiples. Les redirections multiples ou chaînes de redirection se produisent lorsqu'une seule redirection ne redirige pas vers l'emplacement final de la ressource. Ces types de redirection mettent plus de pression sur le Time to First Byte et devraient être évités à tout prix. Encore une fois, utilisez un outil pour trouver ces types de redirections et corrigez-les !

Redirections HTTP-vers-HTTPS. Une façon de contourner cela est d'utiliser l'en-tête Strict-Transport-Security (HSTS), qui imposera HTTPS lors de la première visite à une origine, et dira ensuite au navigateur d'accéder immédiatement à l'origine via le schéma HTTPS lors des visites futures.

Lorsqu'un utilisateur demande une page web, le serveur peut répondre avec une redirection vers une autre page. Cette redirection peut ajouter du temps supplémentaire au TTFB car le navigateur doit faire une demande supplémentaire vers la nouvelle page.

Il existe plusieurs façons d'éviter les redirections ou de minimiser l'impact des redirections :

1. Mettez à jour vos liens internes ! Chaque fois que vous changez l'emplacement d'une page, mettez à jour vos liens internes vers cette page pour vous assurer qu'aucune référence à l'emplacement précédent de la page ne reste.
   
2. Gérez les redirections au niveau du serveur.
   
3. Utilisez des URL relatives : Lorsque vous créez des liens vers des pages sur votre propre site web, utilisez des URL relatives au lieu d'URL absolues. Cela aidera à prévenir les redirections inutiles.
   
4. Utilisez des URL canoniques : Si vous avez plusieurs pages avec un contenu similaire, utilisez une URL canonique pour indiquer la version préférée de la page. Cela aidera à prévenir le contenu dupliqué et les redirections inutiles.
   
5. Utilisez des redirections 301 : Si vous devez utiliser une redirection, utilisez une redirection 301 au lieu d'une redirection 302. Une redirection 301 est une redirection permanente, tandis qu'une redirection 302 est une redirection temporaire. L'utilisation d'une redirection 301 aidera à prévenir les redirections inutiles.