Transloadit

Qu’est-ce que le délai avant le premier octet ?

Le délai avant le premier octet (TTFB) est le temps écoulé entre le début d’une requête ou d’une navigation et l’arrivée du premier octet de la réponse. Selon le point de départ de la mesure, il peut inclure la redirection, la résolution DNS, la connexion et l’établissement de TLS, en plus du traitement serveur.

Fonctionnement du délai avant le premier octet

Le TTFB marque le moment où une réponse commence à arriver : tout ce qui précède ce moment entre dans son calcul, et rien de ce qui suit n’y entre. Pour une navigation vers une page mesurée dans le navigateur, web.dev énumère les phases additionnées : durée de redirection, démarrage du service worker, résolution DNS, connexion et négociation TLS, puis la requête jusqu’au premier octet de la réponse. Les navigateurs exposent ce moment sous le nom responseStart dans les API Navigation Timing et Resource Timing. Lorsque la réponse est présente dans le cache du CDN, le trajet vers l’origine disparaît du total, ce qui explique pourquoi une même URL peut présenter des valeurs très différentes selon que la réponse est absente ou présente dans le cache. Lorsqu’un CDN se trouve sur le parcours, un en-tête de réponse Server-Timing peut détailler davantage la mesure : Amazon CloudFront, par exemple, peut indiquer si la réponse était présente ou absente du cache et, en cas d’absence, rapporter séparément la latence jusqu’au premier octet de l’origine et la sienne. Les serveurs et les intermédiaires choisissent les métriques Server-Timing à envoyer ; l’en-tête ne montre donc que ce qu’ils rapportent. Pour la diffusion de médias, le TTFB situe le délai avant le début du transfert d’une liste de lecture, d’un segment, d’une image ou d’une réponse d’API ; il ne dit rien du temps nécessaire pour télécharger ensuite le corps.

Points clés

  1. Pourquoi deux outils rapportent-ils des TTFB différents pour une même requête ? Ils démarrent la mesure à des moments différents. La bibliothèque web-vitals mesure une navigation depuis son début, ou depuis l’activation pour une page prérendue, jusqu’à responseStart, ce qui inclut les redirections, la résolution DNS, la connexion et TLS. Chrome DevTools nomme une phase plus restreinte « Waiting (TTFB) » : elle suit les phases distinctes de résolution DNS, de connexion et d’envoi de la requête, et couvre la latence d’un aller-retour plus le temps pris par le serveur pour préparer la réponse. La mesure time_starttransfer de curl part du début du transfert et inclut la résolution de nom, l’établissement de la connexion et la négociation TLS. Un journal de CDN couvre un périmètre encore plus restreint : le champ time-to-first-byte de CloudFront est mesuré sur le serveur, de la réception de la requête à l’écriture du premier octet de la réponse, et n’inclut donc aucun temps de réseau côté client. Faites correspondre les définitions avant de comparer les chiffres ou de fixer un objectif.
  2. Existe-t-il une valeur cible ? Pour les navigations vers des pages, web.dev donne un repère approximatif : 0,8 seconde ou moins est une bonne valeur, et plus de 1,8 seconde est une mauvaise valeur. Le TTFB n’est pas un Core Web Vital, et web.dev présente ces seuils comme des repères approximatifs, car une page rendue côté serveur peut avoir un TTFB plus élevé tout en affichant son contenu plus tôt qu’une page rendue dans le navigateur. Ces repères concernent les requêtes de navigation, c’est-à-dire les documents HTML ; web.dev ne donne aucun seuil pour les images, les segments vidéo ou les appels d’API.
  3. Peut-on mesurer le TTFB en conditions réelles pour des médias servis depuis un nom d’hôte de CDN ? Seulement si le CDN le permet en envoyant un en-tête de réponse Timing-Allow-Origin qui mentionne l’origine de la page ou le caractère générique *. Pour une ressource d’une autre origine envoyée sans cet en-tête, l’API Resource Timing renvoie 0 pour responseStart, ainsi que pour les horodatages de résolution DNS, de connexion et de requête. responseStart vaut également 0 pour une ressource récupérée instantanément depuis un cache ; excluez donc les zéros au lieu de les inclure dans la moyenne. Le même en-tête détermine si une page peut lire les métriques Server-Timing provenant d’une autre origine.
  4. Une réponse 103 Early Hints compte-t-elle comme le premier octet ? Dans les API des navigateurs, oui : responseStart renvoie l’heure de la première réponse intermédiaire lorsqu’il y en a une, et web.dev précise que la réponse 103 compte comme les premiers octets. finalResponseHeadersStart donne plutôt le début de la réponse finale. Chrome a rapporté la réponse finale dans responseStart à partir de la version 115, puis est revenu sur ce changement dans la version 133. Les données TTFB de Chrome peuvent donc varier entre ces versions pour les sites qui envoient des réponses Early Hints. L’envoi anticipé des en-têtes de réponse a un effet similaire. Un TTFB plus faible après l’activation de l’un ou l’autre mécanisme ne prouve donc pas, à lui seul, que le contenu principal arrive plus tôt.

Quand le délai avant le premier octet est important

Comparez le TTFB d’une même URL selon que le résultat est absent ou présent dans le cache du CDN, dans des conditions par ailleurs similaires, pour voir quelle latence le parcours sans résultat en cache ajoute au parcours de diffusion. Un TTFB faible ne garantit pas une réponse complète rapide, car les temps de téléchargement et de rendu restent distincts.

Comment Transloadit vous aide à gérer le délai avant le premier octet

Sur le Smart CDN de Transloadit, l’absence d’un résultat dans le cache entraîne un traitement qui est évité lorsque le résultat s’y trouve. En cas d’absence, la requête importe l’original depuis votre stockage et exécute votre Template pour produire le résultat ; si le résultat est présent, il est livré depuis le cache en périphérie du réseau sans rien exécuter. La page produit du Smart CDN rapporte séparément les temps des requêtes à cache froid et à cache chaud, et conseille de tenir compte du temps de récupération de la source et de transformation lorsque le cache est froid.

La page produit ne précise pas si ses mesures correspondent au délai avant le premier octet ou au temps de réponse complet, ni si des octets de réponse sont envoyés avant la fin du traitement en l’absence de résultat dans le cache. Elle présente ces temps comme des mesures datées qui varient selon la charge de travail. Mesurez votre propre Template en comparant, pour une même URL, une requête dont le résultat est absent du cache à une requête dont le résultat y est présent. Une première requête et une requête répétée ne constituent pas automatiquement cette paire : l’URL peut déjà être en cache en périphérie du réseau, et le Robot /file/serve indique par défaut aux navigateurs de mettre les résultats en cache. Une requête répétée depuis un navigateur peut donc recevoir une réponse locale. La page produit conseille de vérifier les en-têtes de cache des réponses lors du débogage.

Explorer les capacités de diffusion de Transloadit

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle

Reliez les téléversements, le traitement, l’IA, le stockage et la diffusion via une seule API déclarative — la pile d’encodage, la montée en charge et l’évolution constante des formats sont prises en charge pour vous.

Essayer Transloadit gratuitement