Le time to first quoi?
Utilisée depuis des les débuts d’Internet, le Time to First Byte (TTFB) est une mesure popularisée en 2012 pour évaluer la réactivité d’un serveur web. Aujourd’hui, cette mesure est l’une des premières utilisées pour évaluer la performance d’un serveur. Plus précisément, il s’agit de la mesure du temps attendu par le navigateur avant de recevoir son premier octet de donnée provenant du serveur. Plus il faut du temps pour obtenir ces données, plus il faut du temps pour afficher votre page.
Pour comprendre encore plus ce que c’est, examinons plus en détail les actions réalisées après que vous entrez une adresse Internet dans votre fureteur:
1ere étape: La mise en file d’attente et temps d’attente
Pour une multiplicité de raisons, votre navigateur mettra d’abord la requête en attente. Soit qu’il y a des requêtes prioritaires, qu’il y a déjà plus de 6 connexions TCP déjà entamées et plus souvent qu’autrement, le navigateur se permet d’allouer de l’espace dans la mémoire cache du disque.
2e étape: La recherche DNS
Un serveur Domain Name System (DNS) a pour but de convertir un nom de domaine, comme une adresse Internet tapée dans un navigateur, en adresse IP. Le système procède donc à la recherche d’un serveur DNS qui pourra associer la page en une adresse IP particulière pour pouvoir poursuivre le reste de la requête.
3e étape: Requête envoyée
L’adresse IP trouvée, le navigateur peut maintenant poursuivre la requête.
4e étape: “En attente du traitement par le serveur”
C’est dans cette étape exactement où le TTFB intervient, où le navigateur attend le 1er octet d’une réponse. C’est avec cette mesure d’indication qu’on puisse évaluer l’efficacité du serveur. Par contre, il ne faut pas oublier que le temps de traitement comprend un aller-retour de latence et le temps que le serveur a pris pour préparer la réponse.
5e étape: Le téléchargement du contenu
La requête est désormais finalisée, on peut finalement afficher le résultat.
Est-ce déjà plus clair ?
Pourquoi est-ce donc pertinent?
D’abord, il est important de mentionner que le TTFB N’EST PAS une mesure pour évaluer la vitesse d’un site web, mais bien son taux de réactivité. Les opinions par rapport à cette mesure sont plutôt mitigées. Certaines personnes, comme le directeur de la technologie chez Cloudfare, John Graham-Cumming et Jesse Nickles, le fondateur de l’hébergeur Little Bizzy disent qu’il n’a pas de sens et que les gens ne devraient pas s’en soucier tandis que l’ingénieur de performance web chez Google Ilya Grigorik juge que c’est une mesure importante à considérer.
Au lieu de plonger dans le débat si la mesure est importante ou non, il est essentiel d’évaluer comment la calculer et comment pouvoir l’optimiser. Tous les ajouts et les mises à jour que vous faites sur votre site influencent votre TTFB. Les sites avec plusieurs éléments ont une réactivité évidemment plus faible à ceux qui en ont moins.
Dans les principaux facteurs de ralentissement, on dénote notamment un trafic web élevé, des problèmes de réseau, de l’utilisation d’un contenu dynamique, comme l’utilisation d’un disque dur ou de la RAM et de la vitesse de votre base de données. En plus de ça, la configuration du serveur, que ce soit dans ses paramètres PHP, ceux de la base de données utilisés ou encore l’utilisation d’un serveur mutualisé.
En général, tout ce qui est inférieur à 100 ms est excellent. Un temps de réponse dans la gamme de 300 à 500 ms est un résultat plutôt standard. Si vous avez plus de 600 ms, il se peut que vous ayez quelque chose de mal configuré sur votre serveur ou qu’il soit temps de vous mettre à niveau vers une meilleure configuration web.
Alors comment calculer cette mesure de référence? Plusieurs services en ligne sont offerts, comme entre autres KeyCDN qui vérifie les statistiques à partir de 14 emplacements différents ,mais il est également possible de le calculer soi-même, avec la fonction curl.
Comment optimiser ce fameux Time to First Byte?
Des facteurs de ralentissements mentionnés ci-haut, les deux premiers, le trafic web élevé et les problèmes de réseaux, ne sont pas contrôlables et malgré tout, une optimisation reste nécessaire. C’est avec les deux suivants qu’on possède plus de marge de manoeuvre. Donc avec ces facteurs, voici 4 conseils efficaces vous permettant de moduler cette mesure.
1. Mise en cache de vos fichiers
Pour éviter la présence de contenu dynamique, la manière la plus facile de ralentir votre TTFB, la mise en cache demeure la situation idéale. Beaucoup pensent seulement que la mise en cache peut seulement aider à réduire vos temps de chargement, mais aussi elle aide à diminuer le TTFB car elle aide à réduire le temps de traitement du serveur.
2. Réduction des requêtes
Souvent, le trop grand nombre de requêtes effectuées sur une page web est l’un des plus grands risques de ralentissement du TTFB. Pour identifier ces liens qui requiert un trop grand nombre de requêtes, il existe des plugiciels (plugin) d’identification comme New Relic. Vous aurez donc ainsi l’opportunité de fouiller qui prennent du temps, afin de pouvoir cibler plus facilement les cas problématiques
3. Mise en oeuvre d’un réseau de diffusion de contenu (CDN)
Un Content Delivery Network (CDN ou réseau de diffusion de contenu en français) est un ensemble de serveurs situés à des emplacements différents et mis en réseau via internet. Particulièrement si vous avez un site Web qui sert les visiteurs dans différentes parties du pays ou dans le monde entier, cela peut réduire considérablement votre TTFB.
4. Utilisation d’un hébergeur rapide
Ça peut sembler évident, mais c’est un facteur majeur dans l’amélioration du Time to First Byte. Par exemple, en évaluant le TTFB de la page Planethoster.info via l’un des calculateurs de cette mesure disponible en ligne, on peut facilement constater que la mesure est excellente, en dessous de 200 ms dans une majorité de pays, comme vous le voyez dans les résultats ci-dessous.
Et vous, comment se comporte votre TTFB? Est-ce une mesure efficace pour vos serveurs?
Effectivement, pour réduire le TTFB sur des technologies telles que WordPress, il est absolument indispensable de se munir d’un plugin de cache et d’optimisation complet, sinon, les scores s’envolent.
Pour info : Pour le test sur (l’excellent) « tools KeyCDN », se rendre de « Performance » et non pas dans « Speed Test ».
Je viens de faire quelques tests pour comparer mes scrores (HybridCloud PlanetHoster) avec les scores d’un hébergeur mutualisé concurrent 🙂 On est chez PlanetHoster sur des TTFB de 30 ms (France) 90 ms (Allemagne) contre les scores concurrents : 800ms (France), 2,5 secondes!!! (pour l’Allemagne).
On comprend maintenant la différence de tarif de ces « offres uniques » et des hébergements dédiés/cloud.
Concernant New Relic, il serait intéressant de publier un tutoriel présenter son fonctionnement.
CDN : attention, seulement pour les sites avec du trafic international. Mais, quel CDN conseillez-vous ?