Délai avant le premier octet (TTFB)

Navigateurs pris en charge

  • 43
  • 12
  • 31
  • 11

Source

Le délai avant le premier octet (TTFB) est une métrique fondamentale qui permet de mesurer le temps de configuration de la connexion et la réactivité du serveur Web dans l'atelier et sur le terrain. Elle mesure le délai entre la requête d'une ressource et le moment où le premier octet d'une réponse commence à arriver. Il est ainsi utile de déterminer quand un serveur Web est trop lent pour répondre aux requêtes. Dans le cas des requêtes de navigation (c'est-à-dire des requêtes pour un document HTML), elles précèdent toute autre métrique de performances de chargement significative.

Schéma des délais des requêtes réseau. Les phases de gauche à droite sont la redirection (qui chevauche l’invite de déchargement), le cache, DNS, TCP, la requête, la réponse, le traitement et le chargement. Les délais associés sont redirectStart et redirectEnd (qui chevauchent les éléments unloadEventStart et unloadEventEnd de l'invite de Unload), fetchStart, domainLookupStart, domainLookupEnd, connectStart, secureConnectionStart, connectEnd, requestStart, responseStart, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete, loadEventStart et loadEventEnd.
Schéma des phases d'une requête réseau et des codes temporels associés. TTFB mesure le temps écoulé entre startTime et responseStart.

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

  • Délai de redirection
  • Temps de démarrage du service worker (le cas échéant)
  • résolution DNS
  • Connexion et négociation TLS
  • "Requête", jusqu'à ce que le premier octet de la réponse arrive

La réduction de la latence au moment de la configuration de la connexion et sur le backend permet de réduire le TTFB.

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

Étant donné que le TTFB se produit avant les métriques centrées sur l'utilisateur telles que First Contentful Paint (FCP) et Largest Contentful Paint (LCP), nous vous recommandons de faire en sorte que votre serveur réponde aux requêtes de navigation suffisamment rapidement pour que le 75e centile des utilisateurs présente un FCP compris dans le seuil "bon". À titre indicatif, la plupart des sites doivent s'efforcer d'avoir un TTFB de 0,8 seconde ou moins.

Les bonnes valeurs TTFB sont inférieures ou égales à 0,8 seconde, les mauvaises valeurs sont supérieures à 1,8 seconde et les valeurs intermédiaires doivent être améliorées
Les bonnes valeurs TTFB sont de 0,8 seconde ou moins, et les mauvaises valeurs sont supérieures à 1,8 seconde.

Important: Le TTFB n'étant pas une métrique Core Web Vitals, il n'est pas absolument nécessaire que les sites aient un excellent TTFB. Lorsque vous optimisez les temps de chargement, réfléchissez à la manière dont votre site diffuse le contenu. Un TTFB est particulièrement important si un site fournit rapidement son balisage initial, puis doit attendre que les scripts lui envoient un contenu pertinent, comme c'est souvent le cas avec les applications monopages (SPA). En revanche, un site affiché par le serveur qui ne nécessite pas beaucoup de travail côté client peut avoir de meilleures valeurs FCP et LCP qu'un site affiché par le client, même si son TTFB est plus élevé.

Comment mesurer la TTFB

La TTFB peut être mesurée en atelier 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 requêtes de navigation dans le navigateur à l'aide de l'API Navigation Timing. L'exemple suivant montre comment créer un PerformanceObserver qui écoute une 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 avec moins de complexité:

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 aux requêtes de navigation. En particulier, les ressources hébergées sur des serveurs multi-origines peuvent introduire une latence lors de la configuration des connexions à ces serveurs. Pour mesurer la valeur TTFB des ressources du champ, utilisez l'API Resource Timing dans un PerformanceObserver:

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

  for (const entry of entries) {
    // Some resources might have a responseStart value of 0 if they're being
    // cached, or if a cross-origin resource is 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'. Il tient également compte du fait que certaines ressources chargées à partir de l'origine principale peuvent renvoyer la valeur 0 si la connexion est déjà ouverte ou si une ressource est instantanément extraite d'un cache.

Comment améliorer TTFB

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