Partons d'un principe simple : Réduire le TTFB permet d'améliorer le temps de chargement des pages
1 - Qu’est-ce que le TTFB ?
TTFB est l’abréviation de time to first byte (temps pour le premier octet).
En d'autres termes, il s’agit d'une mesure du temps nécessaire avant que le navigateur puisse recevoir son premier octet de données du serveur.
Bien évidemment, plus le temps pour obtenir ces données est long, plus il faudra de temps pour afficher votre page.
Testez rapidement votre TTFB sur cet outil : https://gf.dev/ttfb-test
A savoir que le TTFB est un ensemble de étapes ('Durée de la redirection' + 'Durée de la connexion' + 'Durée du backend'.) et si l'une d'entre elles prends du retard, tout votre site sera impacté.
Ces étapes pouvant comprendre plusieurs facteurs métriques
Google recommande une valeur sous 200ms pour le TTFB. Dans la plupart des cas, on observera plutôt entre 300 et 500ms. Au delà de 600ms il se peut qu'il soit temps de vous mettre à niveau (changement d'hébergeur ou misconfig à vérifier)
Au moment de ce test, le TTFB de notre site web est de 162ms depuis l'outil (donc Londres). A noter qu'en dessous de 100ms c'est excellent mais n'oubliez pas que cela variera énormément en fonction de la distance client/serveur !
Revenons sur ces 3 étapes :
- 1. Demande au serveur
- Lors de la visite de votre site Web, une requête HTTP est envoyée du client (navigateur) vers le serveur. Au cours de cette étape, divers facteurs peuvent entraîner des retards notamment des lenteurs de résolution DNS qui pourrait contribuer à augmenter le temps pour la requête. En effet, un serveur géographiquement éloigné peut faciliter une latence du fait de la distance que les données doivent parcourir. Un chemin non optimisé (routage) via des règles de pare-feu complexes pourrait également augmenter le temps de traitement.
- 2. Traitement du serveur
- Après envoi et réception de la requête, le serveur doit la traiter et générer une réponse. Un retard sur cet aspect peut provenir de différents aspects tels que des appels de base de données lents, trop de scripts tiers, ne pas mettre en cache votre première réponse, du code, un CMS (ex. WordPress) ou un thème mal optimisé, et des ressources serveur insuffisantes/inefficaces telles que les I/O de disque, le processeur ou la mémoire.
- 3. Réponse au client
- Après traitement de la requête, le serveur doit la renvoyer au client (ou plutôt renvoyer le premier octet). Ceci est fortement affecté à la fois par la vitesse du réseau du serveur et du client. Si le client a un Internet lent à partir d’un point d’accès Wi-Fi, cela va se refléter dans le TTFB.
La connectivité (vitesse Internet, traceroute, ...) du visiteur rentre également en jeu lors des étapes 1 & 2
2 - L'importance du TTFB
Il est important de comprendre que le TTFB n’est qu'une métrique parmi tant d'autres et qu'il n'est totalement représentatif de la vitesse de votre site Web. Le 1er octet peut en effet être très rapide mais script tiers (type javascript) trop lourd peut venir mettre à mal le reste du chargement.
Il existe une étude approfondie de MOZ sur la corrélation entre les classements de recherche et la durée du premier octet. Cependant, vous connaissez l'histoire de l'œuf et de la poule. Il est compliqué de savoir s'il s'agit de la cause ou si les sites dont le TTFB est plus faible étaient aussi plus rapides en général, ce qui pourrait être affecté par le facteur de classement de la vitesse de page de Google.
Nous n'allons donc pas débattre trop longtemps sur cela, mais simplement vous expliquer comment le travailler.
3 - Mesurer et améliorer son TTFB
Divers outils sont à votre disposition afin de regarder en détail votre TTFB
Vous pouvez par exemple :
- Utiliser un outil de développeur type DevTools pour Chrome
- Utiliser l'outil de Geekflare cité plus haut
- WebPageTest
- GTmetrix
Pour réduire votre TTFB, si vous n'avez pas la main sur la configuration de votre serveur il vous faudra contacter votre hébergeur et/ou en changer si aucun changement ne peut être appliqué sur les étapes n'étant pas à votre main.
Autre alternative, mettre en place un CDN type Cloudflare qui vous permettra de mettre en cache votre contenu statique et de le propager sur les serveurs de ce CDN afin de réduire la distance client/serveur. Cela soulagera également votre serveur qui n'aura pas à charger ces éléments.
Pensez également à la mise en cache côté serveur. Vous pouvez d'ailleurs consulter notre article sur Brotli vous permettant via quelques lignes dans un fichier '.htaccess' de compresser vos fichiers statiques et de forcer la mise en cache de ceux-ci afin d'économiser énormément de ressources.
Si vous n'avez pas Brotli mais que votre hébergeur ou que votre serveur utilise plutôt gzip, des équivalences existent.
Voici une configuration (nécessitant le mod_expires) possible :
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 7200 seconds"
ExpiresByType image/jpg "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
AddType image/x-icon .ico
ExpiresByType image/ico "access plus 2592000 seconds"
ExpiresByType image/icon "access plus 2592000 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType text/css "access plus 2592000 seconds"
ExpiresByType text/javascript "access plus 2592000 seconds"
ExpiresByType text/html "access plus 7200 seconds"
ExpiresByType application/xhtml+xml "access plus 7200 seconds"
ExpiresByType application/javascript A259200
ExpiresByType application/x-javascript "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
</IfModule>
A vous de jouer maintenant ! et n'oubliez pas que nos experts peuvent vous venir en aide via notre offre d'optimisation de contenu
