Time to First Byte : qu’est-ce que c’est et pourquoi c’est important ? (Partie I)

En tant que propriétaire de site, tech SEO ou développeur, vous êtes probablement familier avec la difficulté d’obtenir des performances optimales dans un monde numérique où chaque milliseconde compte. Une mesure critique qui est souvent négligée, mais qui peut avoir un fort impact sur l’expérience utilisateur et la vitesse de la page est le “temps de chargement du premier octet” (Time to First Byte – TTFB).

Comprendre et optimiser cet élément crucial peut s’avérer très utile dans votre quête d’une meilleure performance et d’une plus grande satisfaction de l’utilisateur. C’est pourquoi, dans cet article, nous souhaitons examiner le TTFB plus en détail, expliquer son importance et fournir des conseils pratiques pour vous aider à réduire le score TTFB de votre site web.

Plongeons dans le vif du sujet !

Qu’est-ce que le Time to First Byte ?

Le Time to First Byte est un indicateur de performance qui mesure le temps écoulé entre une requête HTTP envoyée par un client à un serveur et le premier octet des données de la page demandée renvoyé au navigateur du client en guise de réponse. Il indique essentiellement la réactivité d’un serveur web et sert d’indicateur de la vitesse de chargement initiale d’un site web.

Le processus de calcul se compose principalement du temps de connexion au socket, du temps d’envoi de la requête HTTP et du temps de réception du premier octet de la page.

Si le temps nécessaire pour que le premier octet soit renvoyé en réponse à une demande du client est supérieur à ce que nous considérons comme optimal, le temps de chargement de la page augmentera automatiquement.

En résumé, si le serveur qui héberge les documents d’un site web peine à répondre rapidement aux requêtes entrantes, cela aura un impact négatif sur les performances, l’expérience de l’utilisateur et la facilité d’exploration.

Quel est le résultat idéal du TTFB ?

Pour répondre à cette question, nous pouvons nous référer directement à Google qui recommande des valeurs de 200 ms ou moins pour la mesure TTFB.

Il est difficile de déterminer une moyenne claire pour les sites web mondiaux, en fonction du pays cible et de la structure du serveur. Toutefois, d’après l’étude la plus importante dans ce domaine, qui met en évidence la relation entre le TTFB et les sites les mieux classés dans les SERPs, nous pouvons conclure sans risque que pour beaucoup d’entre eux, la métrique est inférieure à 500 ms, atterrissant généralement quelque part autour de 350 ms.

Dans les tests de TTFB, les résultats varient en fonction d’un certain nombre de variables telles que les performances des serveurs des différents fournisseurs d’hébergement, l’heure du test et la distance entre le serveur et le client qui envoie la requête.

Dans les tests effectués avec les outils Lighthouse et PageSpeed de Google, les scores TTFB de 600 ms ou plus sont considérés comme des résultats non satisfaisants par Google.

Pourquoi le TTFB est-il important pour le SEO ?

Pour aller droit au but, la principale raison pour laquelle le TTFB est si important pour le monde online, et plus particulièrement pour nos efforts de SEO, est qu’il affecte directement et concrètement les temps de chargement des pages et l’expérience utilisateur.

Parmi les nombreux paramètres utilisés par Google pour déterminer ses résultats de recherche (ceux que nous connaissons et ceux que nous ne pouvons que deviner), l’importance des temps de chargement des pages et de l’expérience utilisateur a augmenté.

La tendance n’a fait que s’accentuer depuis 2014, lorsque Google a annoncé qu’il évaluerait pour la première fois la vitesse des pages en tant que paramètre de positionnement, puis lorsqu’il a annoncé la mise à jour de l’algorithme Mobile-First Indexing.

Bien que de nombreux facteurs puissent avoir un impact sur les temps de chargement des pages, le TTFB est essentiel pour mesurer l’adéquation des configurations de serveur et la capacité générale du serveur à gérer le trafic entrant.

Malgré les améliorations significatives apportées aux configurations du côté client et du site web (codage, optimisation visuelle, etc.) qui affectent les temps de chargement des pages, les configurations de serveur mal mises en œuvre et la capacité de réponse du serveur ont un impact très direct sur les temps de chargement des pages.

Alors que nous nous dirigeons vers des moteurs de recherche axés sur les mobiles, il est devenu de plus en plus important d’optimiser les sites web pour les appareils mobiles dont les limites sont plus faibles que celles des ordinateurs en termes de mémoire vive, de configuration du processeur et de vitesse de connexion.

Bien qu’il soit difficile, pour nous en tant que SEO, d’optimiser pour les appareils mobiles du côté client, il y a des choses que nous pouvons faire du côté serveur pour optimiser la capacité de réponse. Nous examinerons ce point plus en détail ci-dessous.

Budget de crawl et TTFB

Outre les effets que le TTFB peut avoir sur les temps de chargement des pages et l’UX, un score TTFB élevé affecte également la fréquence de crawl de votre site. Lorsque les robots de Google envoient une requête de crawl à un site quelconque, ils régulent la fréquence de crawl en prenant en compte les temps de réponse du serveur afin d’éviter qu’il ne se bloque en raison d’une surcharge.

Par exemple, pour un serveur dont le score TTFB est de 200 ms, le nombre de requêtes de crawl que le robot Google enverra au serveur sera différent de celui d’un serveur dont le temps de réponse est de 650 ms, 1000 ms ou même 2000 ms. De tels scores indiquent clairement que nous fonctionnons avec des serveurs beaucoup plus lents et Google s’adaptera en conséquence.

Un site web dont le serveur a optimisé son TTFB et répond aux requêtes de manière optimale verra une augmentation des requêtes de crawl et de la fréquence de crawl. Par conséquent, un tel site sera moins sujet à des problèmes tels que l’indexation retardée ou les crawls retardés.

Cependant, il est important de garder à l’esprit que l’indexation et le positionnement de votre contenu sont étroitement liés à d’autres paramètres tels que la qualité technique et la qualité du contenu de votre site.

Le TTFB n’est pas un facteur décisif pour savoir si un contenu est indexé après crawl, mais un bon score ne peut pas faire de mal car le nombre de requêtes de crawl vers votre site augmentera proportionnellement à votre score TTFB.

“La réponse du serveur n’est pas le seul paramètre qui affecte la crawlabilité et le budget crawl. La qualité du contenu, la structure technique et la santé générale du site peuvent également avoir une incidence importante sur la navigabilité.” – Oskay Günaçar

Quelles sont les causes des scores de TTFB ?

Comme nous l’avons évoqué, la mesure de votre TTFB se compose de trois étapes de base :

• Le temps de connexion à la socket : le temps nécessaire pour que la requête traverse le réseau et atteigne le serveur web.
• Le traitement de la demande reçue et la préparation de la réponse.
• Le temps nécessaire pour que la réponse (ressources réseau) générée en réponse à la demande parvienne au client.

Toutes les conditions mentionnées ci-dessus devraient idéalement être optimales pour obtenir un bon score de TTFB. Pour les sites web dont le score TTFB est médiocre, le problème peut résulter de l’une ou de l’ensemble des trois étapes, tant du côté du serveur que de celui de l’utilisateur.

Le temps de connexion à la socket (envoi de la demande au serveur)

La mesure de TTFB commence par la requête HTTP envoyée par le client au serveur. Le temps nécessaire pour que la requête HTTP envoyée par le client atteigne le serveur après la connexion par socket peut varier en fonction du temps de consultation du DNS, de la vitesse du réseau de l’utilisateur, de la distance entre l’utilisateur et le serveur et de toute interruption de la connexion.

Les propriétaires de sites web ne peuvent pas intervenir directement dans ces temps de connexion où la requête envoyée par le client est envoyée au serveur.

Traitement de la demande reçue et préparation de la réponse

Le serveur reçoit la requête HTTP du client après la connexion à la socket et commence à la traiter. Au cours de ce processus, les informations ou données pertinentes pour la requête sont appelées dans la base de données. Les fichiers de la demande sont ensuite traités et édités en communiquant avec des scripts et des ressources réseau du côté du serveur.

À l’issue de ce processus, une réponse spécifique à la demande du client est générée et envoyée. C’est à ce stade que la gestion du site web intervient, pour procéder à des optimisations.

Parmi les stratégies et les applications possibles du côté du serveur pour optimiser le traitement de la demande, on peut citer l’utilisation d’un serveur de haute qualité, l’utilisation du cache, l’optimisation de la base de données et l’optimisation des ressources appelées sur le réseau.

Envoi de la réponse préparée du serveur

Lorsque le serveur crée une réponse à la demande du client dans les deux étapes précédentes, il doit la renvoyer au client. Cette étape dépend à la fois de la vitesse de connexion du serveur du site web et de la vitesse de connexion du client.

Le TTFB est déterminé lorsque le client reçoit le premier octet, c’est-à-dire lorsqu’il commence à recevoir la réponse. Tout comme le temps nécessaire à l’acquisition initiale de la demande, la distance entre le client qui envoie la demande et le serveur influe également sur le temps nécessaire à l’envoi de la réponse préparée.

Pour éviter de telles situations, il serait utile d’avoir des serveurs spécifiques aux pays où se trouvent vos utilisateurs ou de profiter des services CDN.

Les facteurs et les paramètres qui influent sur les notes de TTFB sont généralement les suivants :

• Un trafic élevé, qui peut entraîner un ralentissement du serveur pour les sites web qui ne disposent pas de ressources suffisantes.
• Des problèmes de réseau.
• L’utilisation d’un contenu dynamique trop important, qui augmente la densité du serveur.
• La non-utilisation d’applications telles que le cache serveur ou le cache client.
• L’insuffisance des ressources du serveur (RAM, CPU, disque et vitesse de connexion au réseau).
• La base de données qui n’est pas optimisée.
• Les paramètres généraux du serveur, comme le pare-feu, ne sont pas optimisés.
• L’utilisation d’un serveur et d’un service d’hébergement partagés.

Comment optimiser votre score

Lorsqu’il s’agit d’optimiser votre score TTFB, il existe certaines mesures de SEO qui peuvent être prises à la fois du côté client et du côté serveur.

1. Utiliser un CDN

La technologie des réseaux de diffusion de contenu (CDN) est l’une des principales méthodes d’amélioration des sites web dont les valeurs TTFB sont médiocres. Les services CDN sont très efficaces pour éviter les retards causés par la distance entre le client et le serveur, qui est un facteur majeur dans la détermination des scores TTFB.

Le principe de base d’un CDN est de conserver les fichiers statiques d’un site web, tels que CSS, Javascript et les images, sur des serveurs situés à différents endroits. Lorsque le CDN reçoit une requête provenant d’un endroit spécifique, les fichiers statiques du serveur le plus proche de l’endroit identifié de la requête sont envoyés au navigateur de l’utilisateur.

Les services CDN sont particulièrement utiles pour les sites web dont la base d’utilisateurs se trouve dans un ou quelques pays, où les délais liés à la distance peuvent être éliminés.

En envoyant les ressources statiques de votre site par l’intermédiaire d’un CDN, vous pouvez réduire la charge de votre serveur principal et le nombre de demandes de ressources envoyées sur le réseau depuis votre serveur.

Les ressources statiques hébergées sur des serveurs CDN sont livrées beaucoup plus rapidement aux utilisateurs que sur des serveurs traditionnels, de sorte que votre indicateur TTFB s’améliorera considérablement.

De plus, de nombreux CDN prennent également en charge l’optimisation des images, la réduction en masse des images, la minification des ressources CSS et JS, la compression HTTP2 push et Brotli.

2. Configuration du serveur

Une autre mesure que vous pouvez mettre en œuvre consiste à vous assurer que votre serveur est configuré de manière optimale. Selon le type de serveur sur lequel vous hébergez votre site web, vous devez mettre en œuvre des optimisations côté serveur et veiller à ce que les requêtes HTTP soient traitées rapidement au niveau du backend.

Si vous utilisez PHP, il est particulièrement important de veiller à ce que votre version de PHP soit à jour.

Sur le serveur, vous devez mettre en œuvre des optimisations telles que HTTP/2 et même HTTP 3, la compression Brotli (si possible), la mise en cache côté serveur et la mise en cache de la base de données (Redis).

Vous trouverez ci-dessous certaines configurations et pratiques que vous pouvez utiliser sur presque tous les types de serveurs pour optimiser les scores TTFB.

HTTP/2

En activant l’utilisation de la dernière version du « protocole » HTTP, HTTP/2, sur votre serveur, vous pouvez vous assurer que les ressources demandées sont livrées au client beaucoup plus rapidement sur le réseau.

HTTP/3

HTTP/3 est encore mieux et la dernière version de HTTP qui peut résoudre le problème de blocage en tête de ligne présent dans TCP (HTTP/2). Grâce au protocole UDP, les serveurs web qui utilisent HTTP/3 peuvent communiquer avec les clients plus facilement et plus rapidement.

TLS 1.3

Sur votre serveur et votre CDN, n’oubliez pas d’utiliser le protocole TLS le plus récent pour maintenir une vitesse de communication rapide. Avec TLS 1.3, vous pouvez réduire au maximum la durée des négociations TLS.

Brotli compression

Brotli fournit 30% de compression en plus par rapport à Gzip, ce qui permet de compresser davantage les ressources envoyées du serveur au client et de minimiser ainsi les ressources demandées.

Redis

Redis est une base de données NoSQL open-source écrite en langage C. Contrairement aux bases de données traditionnelles, elle stocke les données en mémoire plutôt que de les écrire sur un disque, ce qui permet une communication plus rapide des données côté serveur.

Server-side caching

En mettant en place une mise en cache côté serveur, vous permettrez à vos serveurs de lire les données rapidement, ce qui réduira la charge sur l’unité centrale et la mémoire vive et évitera que les ressources statiques hébergées sur le serveur soient traitées de manière répétée.

Implement load balancing

Répartissez les requêtes entrantes entre plusieurs instances de serveur afin de garantir une utilisation optimale des ressources et de minimiser le temps de traitement des requêtes.

3. Réduire le contenu dynamique

Le contenu dynamique peut également contribuer à une mauvaise note TTFB. Lors de l’utilisation d’un contenu dynamique, tel qu’une illustration flash utilisant JavaScript, le contenu doit être traité une fois du côté du serveur et une autre fois du côté du client. Cela signifie que le traitement de la demande sera retardé, ce qui augmentera le temps de réponse du serveur pour le contenu dynamique.

Pour éviter de telles situations, il convient d’utiliser le contenu dynamique avec parcimonie et de mettre en place une mise en cache du côté de l’utilisateur et/ou du serveur.

Si la mise en cache n’est pas appliquée du côté du serveur, les ressources statiques des pages web peuvent être mises en cache dans le navigateur ou du côté de l’utilisateur, ce qui permet de stocker les ressources sur l’ordinateur de l’utilisateur et de les charger beaucoup plus rapidement, optimisant ainsi les scores TTFB.

4. Mise à niveau du matériel du serveur

Il est important de mettre à niveau le matériel de votre serveur, même si vous disposez d’une excellente configuration de serveur, d’une excellente infrastructure et d’une excellente architecture de site web.

Indépendamment de tout cela, vous pouvez toujours obtenir de mauvais résultats en matière de TTFB en raison d’un manque de ressources matérielles du côté du serveur.

La mémoire vive, la vitesse de connexion à Internet, la qualité et la capacité du processeur et du disque sont autant de facteurs qui déterminent les scores TTFB d’un serveur et qui ont un impact direct sur sa réactivité.

Si vous utilisez un panneau d’interface utilisateur comme cPanel, Webmin ou Plesk sur votre serveur et que vous essayez de traiter des requêtes WordPress avec 512 Mo ou 1 Go de RAM, vous vous exposez à un désastre total. Tout ce que vous traitez sur votre serveur ralentira la vitesse de réponse de votre serveur.

Dans de telles situations, vous devez identifier combien de sources de serveur sont sollicitées par le personnel interne et vous devez disposer d’un grand nombre de sources supplémentaires qui seront utilisées pour traiter le trafic potentiel à venir sur le serveur.

Les hébergements partagés sont généralement des versions plus lentes des serveurs qui peuvent convenir à de très petits projets. Toutefois, pour les projets de moyenne et grande envergure, il est préférable d’utiliser des serveurs distincts dotés de suffisamment de matériel.

5. Optimisation de la base de données

Comme pour l’optimisation du serveur, il est possible d’améliorer votre score TTFB en concentrant vos efforts d’optimisation sur la base de données. Si vous avez vérifié votre TTFB côté serveur et constatez qu’il y a peu de traitement en cours pour les requêtes mais que le temps d’attente pour les requêtes de la base de données augmente, alors l’optimisation de la base de données pourrait être votre meilleure option.

Voici quelques mesures à prendre pour y parvenir :

• Indexation : utilisez des indexations appropriées sur les tables de votre base de données pour accélérer la récupération des données. Analysez les requêtes les plus courantes et ajoutez des indexations aux colonnes fréquemment utilisées dans les clauses WHERE ou les opérations JOIN. Voici un bon guide sur l’indexation : https://dataschool.com/sql-optimization/how-indexing-works/
• Optimisation des requêtes : examinez et optimisez vos requêtes SQL. Supprimez les JOIN inutiles, réduisez les requêtes imbriquées et utilisez les clauses LIMIT pour ne renvoyer que les données nécessaires. Utilisez des outils tels que EXPLAIN ou EXPLAIN ANALYZE pour comprendre le plan d’exécution et l’optimiser en conséquence.
• Mise en cache : mettre en œuvre des mécanismes de mise en cache pour stocker les résultats des requêtes fréquemment consultées. Cela peut se faire au niveau de l’application ou en utilisant des outils tels que Redis ou Memcached.
• Mise en commun des connexions : utilisez la mise en commun des connexions pour gérer et réutiliser efficacement les connexions à la base de données. La mise en commun des connexions permet de minimiser les frais généraux liés à l’ouverture et à la fermeture des connexions pour chaque requête, ce qui améliore les performances globales.
• Normalisation de la base de données : normalisez le schéma de votre base de données pour éliminer les redondances et garantir la cohérence des données. Cela permet de réduire la complexité des requêtes et d’en améliorer les performances.
• Dénormalisation : dans certains cas, la dénormalisation du schéma de la base de données peut s’avérer bénéfique en réduisant le nombre d’opérations JOIN. Cette approche doit être utilisée avec prudence car elle peut accroître la redondance des données et la complexité de la gestion.
• Utiliser des vues matérialisées : les vues matérialisées sont des résultats de requêtes précalculés qui sont stockés et peuvent être mis à jour périodiquement. L’utilisation de vues matérialisées peut contribuer à améliorer les performances des requêtes complexes et fastidieuses.
• Répartissez les opérations de lecture et d’écriture : répartissez la charge sur votre base de données en séparant les opérations de lecture et d’écriture. Utilisez des répliques de lecture pour gérer les charges de travail lourdes en lecture et laissez la base de données principale pour les opérations d’écriture.
• Surveillez et analysez : surveillez en permanence les performances de votre base de données afin d’identifier les goulots d’étranglement et les problèmes de performances. Utilisez les outils de profilage de base de données et les Logs pour comprendre les performances des requêtes, les requêtes lentes et d’autres problèmes potentiels.

6. Optimisation du code de l’application serveur

Comme pour l’optimisation des bases de données, il existe des mesures que vous pouvez prendre pour améliorer votre TTFB.

• Utiliser des algorithmes et des structures de données efficaces : choisissez les algorithmes et les structures de données adaptés à votre application en fonction de la complexité en termes de temps et d’espace. Optimisez les parties les plus critiques et les plus fréquemment utilisées de votre code.
• Minimisez les opérations bloquantes : elles peuvent entraîner des retards dans le traitement des demandes. Utilisez des opérations asynchrones ou non bloquantes dans la mesure du possible, en particulier pour les tâches liées aux E/S.
• Optimiser les logiciels intermédiaires et les plugins : examinez et optimisez les intergiciels et les plugins utilisés dans votre application. Supprimez les intergiciels inutiles ou remplacez-les par des solutions plus efficaces.
• Utiliser des outils de profilage du code : utilisez des outils de profilage pour identifier les goulots d’étranglement et optimiser les parties lentes de votre code. Le profilage peut vous aider à identifier les problèmes liés au processeur, à la mémoire ou aux E/S dans votre application.
• Optimisez le rendu côté serveur (SSR) : si votre application utilise le rendu côté serveur, optimisez le processus de rendu pour minimiser le temps nécessaire à la génération de la réponse HTML. Utilisez des techniques telles que le « lazy loading », le fractionnement du code ou le rendu partiel pour améliorer les performances.

7. Agents de service

Les agents de service sont un outil utile qui vous permet d’intercepter et de contrôler les demandes du réseau, de gérer la mise en cache et de fournir un support hors ligne, entre autres fonctionnalités. Les Service Workers sont utilisés pour servir plus rapidement le contenu mis en cache et réduire la charge sur votre serveur.

Il agit comme un serveur proxy entre le client et votre serveur et peut servir les fichiers mis en cache avant que la requête du client n’atteigne votre serveur principal. En utilisant cet outil, vous pouvez mettre en cache vos fichiers de grande taille et réduire la surcharge de votre serveur.

Conclusion

En conclusion, le TTFB est une métrique cruciale pour le SEO car il a un poids significatif lorsqu’il s’agit des SERPs. Non seulement il est important pour le SEO, mais un TTFB plus rapide contribue à une meilleure expérience utilisateur et améliore par la suite l’engagement des utilisateurs, réduit les taux de rebond et améliore la performance globale du site web.

Nous avons passé en revue différentes méthodes pour optimiser votre site web et améliorer votre score TTFB. Que vous choisissiez de compresser et d’optimiser les images, les fichiers CSS et JavaScript, ou de mettre en œuvre un CDN, l’objectif ultime est de maintenir l’engagement et la satisfaction de vos visiteurs dans un paysage numérique hautement concurrentiel.

Ne manquez pas la deuxième partie dans laquelle nous examinerons de manière plus concrète comment mesurer votre score TTFB.