Corriger et identifier les problèmes de Time to First Byte (TTFB)

Trouver et corriger les problèmes de Time to First Byte (TTFB)

Dans notre article précédent, nous avons parlé du Time to First Byte. Si vous souhaitez en savoir plus sur les bases, c'est un excellent point de départ !

Dans cet article, je me concentrerai sur l'identification des différents problèmes de Time to First Byte, puis j'expliquerai comment les corriger !

CONSEIL TTFB : la plupart du temps, le TTFB sera bien pire pour les nouveaux visiteurs car ils n'ont pas de cache DNS pour votre site. Lors du suivi du TTFB, il est très judicieux de faire la distinction entre les nouveaux visiteurs et les visiteurs récurrents

Étape 1 : Vérifier le TTFB dans la search console

« La première étape vers la guérison est d'admettre que vous avez un problème ». Donc, avant de faire quoi que ce soit pour corriger le Time to First Byte, assurons-nous que nous avons vraiment un problème avec le TTFB.

Malheureusement, le Time to First Byte n'est pas signalé dans la Google Search console, nous devons donc nous rabattre sur pagespeed.web.dev pour interroger les données CrUX de notre site. Heureusement, les étapes sont simples : accédez simplement à pagespeed.web.dev, entrez l'url de votre page et assurez-vous que le bouton 'origin' est coché (car nous avons besoin de données à l'échelle du site et pas seulement des données de la page d'accueil). Basculez maintenant entre Mobile et Desktop et vérifiez le Time to First Byte pour les deux types d'appareils

Dans l'exemple ci-dessous, vous verrez un site qui échoue aux Core Web Vitals en raison d'un TTFB élevé.

Étape 2 : Configurer le suivi RUM

Le Time to First Byte est une métrique délicate. Nous ne pouvons pas simplement nous fier à des tests synthétiques pour mesurer le TTFB car dans la vie réelle, d'autres facteurs contribueront aux fluctuations du TTFB. Pour obtenir des réponses à toutes les questions ci-dessus, nous devons mesurer les données dans la vie réelle et consigner tous les problèmes qui pourraient survenir avec le Time to First Byte. C'est ce qu'on appelle le Real User Monitoring et il existe plusieurs façons d'activer le suivi RUM. Nous avons développé Core/Dash juste pour ces cas d'utilisation. Core/Dash est un outil RUM peu coûteux, rapide et efficace qui fait simplement le travail ! Bien sûr, il existe de nombreuses solutions RUM et elles feront également le travail (à un prix plus élevé cependant)

Comment penser au TTFB : Imaginez qu'un serveur web est une cuisine de restaurant et qu'un utilisateur demandant une page web est un client affamé passant une commande. Le Time to First Byte (TTFB) est le laps de temps entre le moment où le client passe sa commande et le moment où la cuisine commence à préparer la nourriture.
Donc, le TTFB ne concerne PAS la vitesse à laquelle le repas entier est cuisiné (First Contentful Paint) et servi (Largest Contentful Paint), mais plutôt la réactivité de la cuisine à la demande initiale. 
Le suivi RUM se compare à l'interrogation des clients pour comprendre leur expérience culinaire. Vous pourriez constater que ceux assis plus loin de la cuisine reçoivent moins d'attention du serveur et sont servis plus tard ou que les clients réguliers bénéficient d'un traitement préférentiel tandis que les nouveaux visiteurs doivent attendre plus longtemps pour une table 

Étape 3 : Identifier les problèmes de Time to First Byte

Bien que le Chrome User Experience Report (CrUX) de Google fournisse de précieuses données de terrain, il n'offre pas de détails spécifiques sur les causes d'un TTFB élevé. Pour améliorer efficacement le TTFB, nous devons savoir exactement ce qui se passe à un niveau plus détaillé. À ce stade, il est logique de faire la distinction entre un échec global du TTFB et un échec du TTFB dans des conditions spécifiques (bien qu'en réalité, il y aura toujours un mélange).

3.1 Le TTFB échoue globalement

1. Vérifier les mauvais 'temps de requête' généraux : De mauvais temps de requête signifient que le 'problème' vient du temps que met le serveur à générer la page. C'est la cause la plus fréquente de mauvais scores TTFB ! 
2. Vérifier les autres mauvaises sous-parties du TTFB : Le TTFB n'est pas seulement une métrique unique mais peut être décomposé en plusieurs parties qui ont leur propre potentiel d'optimisation. Si la durée d'attente, la durée du cache, la durée de la recherche DNS ou la durée de connexion sont lentes, vous devrez probablement régler les paramètres de votre serveur ou commencer à chercher un hébergement de meilleure qualité. 

3.2 Le TTFB échoue dans des conditions spécifiques

1. Segmentation par pays : Comprendre la distribution géographique d'un TTFB élevé est important, en particulier pour les sites web ayant une audience mondiale. Si vous servez vos pages à partir d'un seul serveur dans un seul pays (sans mise en cache CDN edge), la distance physique entre l'emplacement de l'utilisateur et le serveur hébergeant le site web causera toutes sortes de retards et aura un impact sur le TTFB. 
   
2. Segmentation par cache : La mise en cache peut réduire le TTFB en sautant la génération côté serveur du HTML. Malheureusement, il est courant que la mise en cache soit désactivée ou contournée pour de nombreuses raisons. Par exemple, la mise en cache peut être désactivée pour les utilisateurs connectés, les pages de panier d'achat, les pages avec des chaînes de requête (par ex. de Google Ads), les pages de résultats de recherche et les pages de paiement. Si votre site web utilise la mise en cache (edge), utilisez le suivi RUM pour vérifier le taux de succès du cache (hit ratio) !
   
3. Segmentation par page (cluster) : La différence de performance Time to First Byte (ou l'absence de différence) entre les pages ou les types de pages est une autre chose que nous devons déterminer. Savoir quelles pages échouent à la métrique TTFB donnera des informations précieuses sur la façon d'améliorer le time to first byte. 
   
4. Segmentation par redirection : Le temps de redirection s'ajoute directement au TTFB. Chaque redirection ajoute du temps supplémentaire avant que le serveur web ne puisse commencer à charger la page. Mesurer et éliminer les redirections inutiles peut aider à améliorer le TTFB.
   
5. Autre segmentation : Bien que la segmentation par les variables ci-dessus couvre les suspects habituels, chaque site est unique et a ses propres défis. Heureusement, le suivi RUM est conçu pour permettre la segmentation par beaucoup plus de variables comme la RAM de l'appareil, la vitesse du réseau, le type d'appareil, le système d'exploitation, des variables personnalisées et bien plus encore. 

Étape 4 : Zoomer sur les problèmes et corriger !

Les sous-parties du Time to First Byte (TTFB) sont :

• Attente + Redirection (ou durée d'attente)
  
• Worker + Cache (ou durée du cache)
• DNS (ou durée DNS)
• Connexion  (ou durée de connexion)
• Requête (ou durée de requête)