speed-ttfb

Le TTFB exprime en millisecondes le temps de réponse d’un serveur. Il est pris en compte par Google et les autres moteurs de recherche pour évaluer la vitesse à laquelle les contenus sont disponibles. Alors, vous l’aurez compris, c’est un indicateur qui importe autant pour vos temps de chargement que pour votre SEO.

Une métrique qui évalue ce que vous ne voyez pas encore

Lorsqu’un.e internaute se rend sur votre site, le navigateur demande les informations à un serveur (origine, serveur distant, CDN…) qui les lui envoie pour afficher les éléments qui doivent apparaître sur la page. Ce temps nécessaire pour que le serveur envoie le 1er octet au navigateur est représenté par le TTFB - à ne pas confondre avec le Start Render qui, lui, indique le moment où le 1er élément s’affiche sur la page.

Autrement, dit, le TTFB indique la réactivité du serveur pour traiter une requête HTTP, ce qui se déroule en plusieurs étapes, incluant la latence du réseau :

  • établissement de la connexion réseau
  • négociation de la connexion sécurisé (TLS) 
  • envoi de la requête HTTP
  • envoi du premier octet de la page.

Plus ce processus est rapide, plus le navigateur est informé tôt du fait que le serveur est bien actif et qu’il va envoyer une réponse. Dans le cas contraire, le navigateur va attendre une réponse jusqu’à un timeout défini par le navigateur.

S’il est impossible de récupérer la page, voici par exemple les erreurs qui peuvent être générées : 

  • 401 – Unauthorized : la page est protégée par un mot de passe
  • 403 – Forbidden : le serveur a reçu la demande mais refuse de la traiter (par exemple, parce que le mot de passe est incorrect)
  • 404 – Not found : la page est introuvable, soit parce qu’il y a une erreur dans l’URL, soit parce que la page n’existe pas
  • 500 – Internal error : le serveur rencontre un problème
  • 503 – Service unavailable : le service est temporairement indisponible (on peut la rencontrer en cas de pic de charge)

Pourquoi le Time To First Byte est important ?

Il aide à détecter des lenteurs applicatives (base de données, moteur de recherche, microservices, …)

Le temps de réponse serveur est directement lié à la vitesse à laquelle les données sont récupérées par le navigateur. Aussi, si le temps de réponse serveur est élevé, la fluidité du site est affectée, l’expérience de navigation est dégradée, vos internautes sont frustré.e.s de devoir attendre que la page se charge et finissent par la quitter si ce délai est trop long - au mieux en n’ayant rien lu ou rien acheté, au pire pour aller chez un concurrent.

Il est lié aux performances SEO 

Le temps de réponse serveur est un critère important pour votre référencement. En effet, outre le temps de chargement de la page, plus votre serveur répond rapidement, plus les robots de Google peuvent crawler des pages facilement. Si on ne peut pas affirmer le lien entre webperf et ranking SEO, on observe une corrélation entre la vitesse d’un site et le nombre de pages crawlées, comme en témoigne par exemple Rue Du Commerce. Google recommande d’ailleurs de ne pas dépasser les 200 ms de TTFB. 

Comment analyser le Time To First Byte ?

Cette métrique dépend des capacités des serveurs et de la connexion internet. Pour un suivi ponctuel, nous conseillons d’utiliser WebPageTest. Pour un suivi quotidien, nous recommandons Pingdom qui permet de vérifier les temps de réponse partout dans le monde en envoyant des “ping” à intervalle régulier.

Comment vous situer ?

Lighthouse estime qu’un TTFB est anormalement élevé à partir de 600 ms mais... considère qu’un TTFB est bon en dessous de 200 ms. Il devrait idéalement être inférieur à 100 ms.

Cela dit, ces indications doivent être considérées en fonction de ce que vous mesurez. Pour une page, avoir un bon TTFB est important pour la vitesse perçue. Pour une ressource individuelle, tout dépend du niveau de criticité de la ressource en question - c’est moins prioritaire de réduire le TTFB pour des ressources dont le niveau de criticité est bas.

Si vous êtes éditeur de script tiers, travaillez sans relâche sur votre TTFB car votre script impacte le temps de chargement de beaucoup de sites !

Qu’est-ce qui dégrade le TTFB ?

Le contenu dynamique 

Bien qu’il soit incontournable, l’un des pires ennemis du TTFB, c’est le contenu dynamique (contenus personnalisés insérés par le serveur, requêtes en base de données, requêtes du serveur à des services tiers, …) ! Pourquoi ? Parce que le problème principal du contenu dynamique est que plus il y en a, plus il faut aller le récupérer auprès de bases de données et/ou en s'adressant à des services tiers. Le fait de multiplier ces demandes de données ralentit les temps de réponse serveur ; chaque étape ajoute des millisecondes à vos temps de chargement.

Par ailleurs, générer des pages avec beaucoup de données nécessite du calcul de la part du serveur, ce qui ralentit également le chargement de la page.

Les pics de trafic

Les pics de trafic peuvent saturer votre serveur et entraîner une hausse du TTFB. Les variations de cet indicateur peuvent d’ailleurs vous alerter sur d’éventuels problèmes de charge. Conseil pratique : en cas de pic de charge, veillez à mettre en place une page de débordement pour préserver l’expérience de navigation.

L’appel à des API

L’appel à des API peut aussi dégrader le TTFB, surtout lorsqu’il s’agit de traiter des volumes importants de données. 

La configuration de votre serveur 

La configuration de votre serveur peut jouer sur le TTFB. Plus il y a de paramètres et de conditions à prendre en compte, plus votre serveur aura besoin de temps pour réaliser des calculs. Par exemple, le traitement des requêtes de bases de données pour le formatage destiné à l’utilisateur.rice final peuvent ralentir le chargement de la page. 

Comment améliorer votre TTFB ?

Optimisez la configuration de votre serveur

Selon la configuration de votre serveur d’application, vous pouvez améliorer votre TTFB. Comme nous l’avons vu, moins le serveur a de calculs à effectuer, plus il peut envoyer rapidement une réponse au navigateur. Alors, pour préserver votre temps de réponse serveur, sachez rester simple.

Cachez les données

Au niveau HTTP ou de l'application, mettre du contenu en cache fait gagner du temps à votre serveur. Il économise ainsi des requêtes pour récupérer les données puisqu’il a accès plus vite à des éléments pré-construits via le cache. Il dispose alors plus rapidement d’un fichier HTML prêt à l’emploi pour le navigateur. 

Tenez compte des avantages mais aussi des limites du lazyloading

Pour envoyer des informations le plus vite possible au navigateur, usez intelligemment de la technique du lazyloading. Elle peut être utile pour des pages qui comportent beaucoup de contenus dynamiques, sans quoi ces contenus seraient inclus dans la page HTML, ce qui aurait un impact sur le TTFB.
Toutefois, le lazyloading peut se révéler contre-productif s’il s’applique à un trop grand nombre d'éléments de la page, car il n’apporterait pas grand chose par rapport à une page sans lazyloading qui mettrait du temps à se charger.

Compressez, mais avec mesure

Plus vous compressez vos données, moins elles ont besoin de temps pour circuler de votre serveur au navigateur ; grâce au format Gzip ou Brotli, vous réduisez la taille des fichiers qui voyagent ainsi plus légers. Pourtant vous devez composer avec un paramètre : le temps et la puissance de CPU nécessaires à la compression. En effet, tant que le fichier n’est pas complètement compressé, aucun octet n’est envoyé au navigateur, et votre TTFB est donc repoussé.
Ainsi, un niveau de compression important permet de servir plus rapidement la page à l’internaute, mais le temps de réponse serveur peut être impacté négativement. Et vice versa, vous pouvez avoir un temps de réponse serveur très rapide mais des données qui ont besoin de beaucoup de temps pour s’afficher. Il faut donc trouver l’équilibre entre tous les paramètres.

De manière générale, comme pour une recette de cuisine réussie, l’efficacité des optimisations webperf tient à un savant dosage entre les différents ingrédients. Chaque action menée dans un sens peut avoir des effets sur d’autres indicateurs, c’est pourquoi les optimisations doivent s'articuler intelligemment entre elles pour être performantes.

Si vous souhaitez en savoir plus sur le fonctionnement du moteur de Fasterize,
et comment nos fonctionnalités se combinent pour améliorer votre webperf :

Demandez une démo

 


Hello SMX Paris !