Le TTFB est souvent utilisé pour mesurer la vitesse à laquelle un serveur Web répond à une requête, et la plupart des services de test Internet le mentionnent. Plus il est rapide, meilleur est le serveur Web (en théorie). Mais cette théorie est contestable.
Wikipedia définit le TTFB comme « la durée entre l'utilisateur ou le client qui fait une requête HTTP et le premier octet de la page reçue par le navigateur du client ». Mais qu’indiquent réellement les sites de test de pages Web populaires ? Pour le savoir, nous avons créé un serveur de test qui ajoute des retards à la réponse HTTP pour savoir ce qui est réellement mesuré. La réponse nous a beaucoup surpris et a montré que le TTFB ne constitue pas un indicateur valable.
Lorsqu'un navigateur Web demande une page à un serveur Web, il envoie lui-même la demande et certains en-têtes qui donnent, par exemple, des précisions sur les formats de réponse acceptables. Le serveur répond par une ligne d'état (généralement HTTP/1.1 200 OK pour indiquer que la page était disponible), suivie de plusieurs en-têtes (contenant des informations sur la page) et du contenu de la page.
Le serveur de test TTFB de Cloudflare fonctionne un peu différemment. Lorsqu'il reçoit une requête, il envoie la première lettre de HTTP/1.1 200 OK (le H) et attend ensuite 10 secondes avant d'envoyer le reste des en-têtes et la page elle-même. (Vous pouvez récupérer le code du serveur TTFB ici ; il est écrit en Go.)
Si vous demandez à WebPageTest de télécharger une page du serveur TTFB de Cloudflare, vous obtenez le résultat suivant, pour le moins surprenant. WebPageTest a considéré que le délai de réception du premier octet correspondait au moment de la réception du H (et celui où la page elle-même a été envoyée). On le voit bien avec le temps d'attente de 10 secondes.
C'est exactement le chiffre rapporté par gomez.
Le TTFB indiqué ne correspond pas au moment où est reçu le premier octet de données de la page, mais au premier octet de la réponse HTTP. Ce sont deux choses très différentes, car les en-têtes de réponse peuvent être générés très rapidement, mais ce sont les données qui affecteront la mesure la plus importante de toutes : la durée d'affichage de la page pour l'utilisateur.
Chez Cloudflare, nous utilisons beaucoup nginx et, lors de nos recherches sur le TTFB, nous avons constaté une différence significative dans la TTFB de nginx selon que la compression est utilisée ou non. La compression Gzip des pages Web réduit considérablement le temps de chargement d'une page Web, mais elle-même est coûteuse en termes de temps. De ce fait, le TTFB est plus long, même si le téléchargement complet est plus rapide.
Pour illustrer cela, nous avons pris la page Wikipedia la plus volumineuse (List of Advanced Dungeons and Dragons 2nd Edition Monsters) et l'avons chargée via nginx, avec et sans compression gzip. Le tableau ci-dessous indique le TTFB et le temps total de téléchargement avec la compression activée et désactivée.
| TTFB | Page loadedVous remarquerez qu'avec la compression gzip, la page a été téléchargée 5 fois plus vite, mais le TTFB était 8 fois plus important. Cela est dû au fait que nginx attend que la compression ait commencé avant d'envoyer les en-têtes HTTP ; lorsque la compression est désactivée, il envoie immédiatement les en-têtes. Donc, si l'on se fie au TTFB, il semble que la compression soit une mauvaise idée. Cependant, en observant le temps de téléchargement, on constate le contraire.
Du point de vue de l'utilisateur final, le TTFB est presque sans intérêt. Dans cet exemple (réel), il est en fait inverse au temps de téléchargement : plus le TTFB est élevé, plus le téléchargement est court. En regardant dans le code source de nginx, nous nous sommes rendu compte que nous pouvions tricher et envoyer les en-têtes rapidement pour donner l'impression que notre TTFB était excellent même avec une compression, mais finalement nous avons renoncé : cela aussi aurait affecté l'expérience utilisateur, car nous aurions perdu un paquet précieux quand le TCP démarre lentement. Cela aurait donné une bonne image de Cloudflare dans certains tests, mais aurait en fait nui à l'utilisateur final.
Le TTFB n'est probablement utile qu'en tant que tendance. De plus, il est préférable de le mesurer au niveau du serveur lui-même afin d'éliminer la latence du réseau. En examinant une tendance, il est possible de déterminer s'il y a un problème sur le serveur Web (tel qu’une surcharge).
Mesurer le TTFB à distance signifie que vous mesurez en même temps la latence du réseau, ce qui masque ce que le TTFB mesure réellement : la vitesse à laquelle le serveur Web est capable de répondre à une requête.
Chez Cloudflare, le TTFB n'est pas un indicateur pertinent. Nous cherchons à optimiser l'expérience des utilisateurs finaux, donc le temps réel d'affichage de la page pour l'utilisateur final. Nous fournirons des outils spécialement conçus pour suivre le parcours des utilisateurs finaux, afin que tous nos éditeurs puissent voir et étudier l'expérience de leurs visiteurs.