Délai avant le premier octet (TTFB)

Barry Pollard
Jeremy Wagner

Browser Support

  • Chrome: 43.
  • Edge: 12.
  • Firefox: 35.
  • Safari: 11.

Source

Qu'est-ce que le TTFB ?

Le TTFB est une métrique qui mesure le temps écoulé entre la demande d'une ressource et le début de l'arrivée du premier octet d'une réponse.

Visualisation des délais de requête réseau. Les temps de la gauche vers la droite sont les suivants : redirection, initialisation du service worker, événement de récupération du service worker, cache HTTP, DNS, TCP, requête, premiers indices (103), réponse (qui se chevauche avec l'invite de déchargement), traitement et chargement. Les temps associés sont redirectStart et redirectEnd, fetchStart, domainLookupStart, domainLookupEnd, connectStart, secureConnectionStart, connectEnd, requestStart, interimResponseStart, responseStart, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete, loadEventStart et loadEventEnd.
Diagramme des phases de requête réseau et des délais associés. Le TTFB mesure le temps écoulé entre startTime et responseStart.

Le TTFB correspond à la somme des phases de requête suivantes:

  • Durée de la redirection
  • Heure de démarrage du service worker (le cas échéant)
  • résolution DNS
  • Connexion et négociation TLS
  • Requête, jusqu'à l'arrivée du premier octet de la réponse

Réduire la latence au moment de la configuration de la connexion et au niveau du backend peut réduire votre TTFB.

TTFB et premiers indices

L'introduction des 103 Early Hints crée une certaine confusion quant à ce que mesure le TTFB "premier octet". Les 103 premiers hints sont considérés comme les "premiers octets". finalResponseHeadersStart est une entrée de synchronisation supplémentaire dans responseStart qui mesure le début de la réponse finale du document (généralement une réponse HTTP 200) à mesurer.

Les premiers indices ne sont qu'un exemple plus récent de réponse anticipée. Certains serveurs permettent d'effectuer un vidage anticipé de la réponse du document avant que le corps principal ne soit disponible, soit avec uniquement les en-têtes HTTP, soit avec l'élément <head>, qui peuvent tous deux être considérés comme ayant un effet similaire à celui des premiers indices. C'est une autre raison pour laquelle tous ces éléments sont mesurés en tant que reponseStart, et donc en tant que TTFB.

Il est vraiment utile de renvoyer les données plus tôt si la réponse complète va prendre un certain temps. Toutefois, cela rend difficile la comparaison du TTFB entre différentes plates-formes ou technologies en fonction des fonctionnalités qu'elles utilisent et de l'impact de ces fonctionnalités sur la mesure du TTFB utilisée. Le plus important est de comprendre ce que mesure l'outil que vous utilisez et comment cela est affecté par la plate-forme mesurée.

Quel est un bon score TTFB ?

Étant donné que le TTFB précède les métriques axées sur l'utilisateur telles que le FCP (First Contentful Paint) et le LCP (Largest Contentful Paint), nous vous recommandons de configurer votre serveur de manière à ce que le 75e centile 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.

Une valeur TTFB acceptable est de 0, 8 seconde ou moins. Une valeur TTFB mauvaise est supérieure à 1, 8 seconde. Une valeur TTFB comprise entre ces deux valeurs doit être améliorée.
Une valeur de TTFB satisfaisante est de 0,8 seconde ou moins, et une valeur mauvaise est supérieure à 1,8 seconde.

Mesurer le délai avant réponse

Vous pouvez mesurer le TTFB en laboratoire ou sur le terrain de différentes manières.

Outils sur le terrain

Outils de l'atelier

Mesurer le TTFB en JavaScript

Vous pouvez mesurer le TTFB des requêtes de navigation dans le navigateur avec l'API Navigation Timing. L'exemple suivant montre comment créer un PerformanceObserver qui écoute une entrée navigation et la consigne dans la console:

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

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

La bibliothèque JavaScript web-vitals peut également mesurer le TTFB dans le navigateur de manière plus concise:

import {onTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

Mesurer les demandes de ressources

Le TTFB s'applique à toutes les requêtes, et pas seulement aux requêtes de navigation. En particulier, les ressources hébergées sur des serveurs multi-origines peuvent entraîner une latence, car il est nécessaire de configurer des connexions à ces serveurs. Pour mesurer le TTFB des ressources dans le champ, utilisez l'API Resource Timing dans un PerformanceObserver:

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

L'extrait de code précédent est semblable à celui utilisé pour mesurer le TTFB d'une requête de navigation, sauf qu'au lieu d'interroger des entrées 'navigation', vous interrogez des entrées 'resource'. Il tient également compte du fait que certaines ressources chargées à partir de l'origine principale peuvent renvoyer une valeur de 0, car la connexion est déjà ouverte ou qu'une ressource est instantanément récupérée à partir d'un cache.

Améliorer le délai avant première réponse

Pour obtenir des conseils sur l'amélioration du TTFB de votre site, consultez notre guide détaillé sur l'optimisation du TTFB.