Délai avant le premier octet (TTFB)

Navigateurs pris en charge

  • 43
  • 12
  • 31
  • 11

Source

Qu'est-ce que TTFB ?

TTFB est une métrique qui mesure le temps entre la demande d'une ressource et le moment où le premier octet d'une réponse commence à arriver.

Visualisation de la durée des requêtes réseau. Les codes temporels de gauche à droite sont "Redirect", "Service Worker Init", "Service Worker Fetch event", "HTTP Cache", "DNS, TCP", "Request", "Early Hints" (103), "Response" (qui chevauche l'invite de déchargement), "Processing" et "Load". Les codes temporels correspondants sont redirectStart et redirectEnd, retrieveStart, domainLookupStart, connectStart, secureConnectionStart, connectEnd, requestStart, interimResponseStart, responseStart, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete, loadEventStart et loadEventEnd.
Schéma des phases d'une requête réseau et des durées associées. Le TTFB mesure le temps écoulé entre le startTime et le responseStart.

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

  • Heure de redirection
  • Temps 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

La réduction de la latence au niveau du temps de configuration de la connexion et sur le backend peut réduire le délai d'affichage total.

Autres définitions de TTFB

La définition précédente est la définition conventionnelle, mais avec l'introduction des Early Hints (Early Hints), ce qui est considéré comme le "premier octet" fait l'objet de débats. firstInterimResponse est une nouvelle entrée de code temporel supplémentaire de responseStart pour les différencier, mais elle n'est compatible qu'avec les navigateurs Chrome et les navigateurs basés sur Chromium. Par conséquent, certains navigateurs et outils (y compris CrUX) effectuent des mesures jusqu'à la réception des premiers octets, y compris les premiers indices.

La fonctionnalité "Early Hints" n'est qu'un exemple plus récent de la manière de réagir tôt. Certains serveurs autorisent le vidage de la réponse du document avant que le corps principal ne soit disponible, soit avec les en-têtes HTTP, soit avec l'élément <head>. Ces deux éléments peuvent être considérés comme semblables aux indications précoces, et donc masquer la définition de ce que mesure le TTFB.

En tant que mesure du moment où le navigateur reçoit les "premiers octets" des données exploitables concernant le document, toutes ces définitions peuvent être considérées comme valides. Il est très utile de renvoyer les données au plus tôt si la réponse complète risque de prendre plus de temps. Le plus important est de comprendre quelle mesure mesure l'outil que vous utilisez et comment cela est affecté par la plate-forme mesurée. Il est donc difficile de comparer le TTFB sur différentes plates-formes ou technologies en fonction des fonctionnalités qu'ils utilisent et de l'impact sur la mesure du TTFB utilisée.

Le TTFB est également souvent considéré comme un indicateur du temps de réponse du serveur ou de l'hôte. Cependant, elle sera affectée par des facteurs hors de ce contrôle direct, tels que le temps de redirection, qu'elle soit diffusée à partir d'un succès de cache par un CDN ou qu'elle doive effectuer un retour potentiellement plus long vers un serveur d'origine. Cela est particulièrement évident pour les données de terrain. En général, ces facteurs sont moins affectés par ces facteurs, car l'URL de fin est généralement testée, ce qui annule souvent à plusieurs reprises les modifications de la mise en cache. Lighthouse indique le temps de réponse du serveur plutôt que le TTFB pour clarifier cela, mais ce n'est peut-être pas le cas pour d'autres outils de l'atelier.

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

Étant donné que le TTFB précède les métriques centrées sur l'utilisateur comme First Contentful Paint (FCP) et Largest Contentful Paint (LCP), il est recommandé que votre serveur réponde suffisamment rapidement aux requêtes de navigation pour que le 75e centile des utilisateurs enregistre un FCP compris dans le "seuil" "satisfaisant". À titre indicatif, la plupart des sites doivent s'efforcer d'avoir un TTFB de 0,8 seconde ou moins.

Les bonnes valeurs TTFB sont de 0,8 seconde ou moins, les valeurs médiocres sont supérieures à 1,8 seconde, et tout ce qui se trouve entre les deux doit être amélioré.
Les bonnes valeurs TTFB sont de 0,8 seconde ou moins, et les valeurs faibles sont supérieures à 1,8 seconde.

Mesurer le délai d'affichage total

Le TTFB peut être mesuré en laboratoire ou sur le terrain de différentes manières.

Outils de terrain

Outils de l'atelier

Mesurer le TTFB en JavaScript

Vous pouvez mesurer le TTFB des demandes de navigation dans le navigateur avec l'API Navigation Timing. L'exemple suivant montre comment créer un objet PerformanceObserver qui écoute l'entrée navigation et l'enregistre 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 succincte:

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, pas seulement les requêtes de navigation. En particulier, les ressources hébergées sur des serveurs multi-origines peuvent introduire une latence en raison de la nécessité de configurer des connexions à ces serveurs. Pour mesurer le TTFB pour les 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 pour une requête de navigation, sauf qu'au lieu d'interroger les entrées 'navigation', vous interrogez plutôt les entrées 'resource'. Cela tient également compte du fait que certaines ressources chargées à partir de l'origine principale peuvent renvoyer la valeur 0, car la connexion est déjà ouverte ou une ressource est instantanément extraite d'un cache.

Améliorer le TTFB

Pour savoir comment améliorer le TTFB de votre site, consultez notre guide détaillé sur l'optimisation du TTFB.