Vous avez probablement déjà croisé la route du Total Blocking Time (TBT) si vous cherchez à optimiser vos Core Web Vitals Google et votre score PageSpeed Insights.
Pour résumer, cette métrique webperf est un équivalent du First Input Delay (FID, qui fait partie des Core Web Vitals) qui permet d’évaluer la réactivité des pages. Plus le TBT est court, plus la page a de chances d’être réactive.
Mais allons plus loin que ce bref résumé pour comprendre exactement ce que mesure le Total Blocking Time, comment l’évaluer, et les techniques pour l’améliorer.
Que mesure le Total Blocking Time (TBT) ?
Après avoir cliqué sur un bouton ou un lien, l’internaute attend une réponse immédiate, et cette sensation d’immédiateté se situe aux alentours de 100 ms.
Idéalement, pour une expérience utilisateur optimale, le temps de réaction du navigateur devrait même être de 50 ms. Sacré challenge !
Or, si une page ne réagit pas aux clics ou ne répond pas aux interactions, c’est le signe que le fil principal (main thread) du navigateur est occupé par d’autres tâches. Ces tâches (tasks) peuvent être plus ou moins longues, et on parle de “long tasks” quand elles durent plus de 50 ms. Sans vouloir dénoncer, ces long tasks sont dans la plupart des cas provoquées par des scripts JavaScript.
Ainsi, le TBT évalue l’accumulation de toutes les plages de temps liées à des tâches qui dépassent les 50 ms, au-delà de ces 50 ms, et pendant lesquelles le navigateur ne peut pas répondre aux interactions.
En pratique, voici comment le Total Blocking Time est calculé :
Le fil principal de la page 1 a deux fois moins de tâches à traiter, mais son TBT est 6 fois plus long parce que l’accumulation du temps d’exécution des long tasks qui dépassent les 50 ms est plus important
Quelles différences entre le Total Blocking Time et le First Input Delay (FID) ?
Alors que le TBT est une accumulation des durées pendant lesquelles un navigateur ne peut pas répondre aux interactions - comme nous venons de le voir -, le First Input Delay mesure le temps entre le moment où un utilisateur interagit pour la première fois avec une page et le moment où le navigateur est réellement en mesure de répondre à cette interaction.
Autre différence notable : le FID se mesure d’après les interactions d’utilisateurs réels avec du Real User Monitoring (RUM), alors que le TBT se mesure en environnement synthétique ou simulé.
De ce fait, le TBT ne tient pas compte des comportements des utilisateurs, ou du fait que la page a ou non un aspect interactif qui peut influencer le moment où les utilisateurs vont être tentés de cliquer quelque part ou de scroller.
Enfin, le First Input Delay fait partie des Core Web Vitals, mais pas du score PageSpeed.
En revanche, depuis la version 6 de Lighthouse, qui sert de base au score PageSpeed Insights, le TBT fait partie du calcul du score PageSpeed.
Comment mesurer le Total Blocking Time ?
Le Total Blocking Time peut être mesuré à l’aide de Lighthouse ou PageSpeed Insights, sachant que ces outils imposent les conditions de test définies par Google, et sur lesquelles vous n’avez pas la main (ces conditions ne sont pas forcément à votre avantage, ni toujours représentatives de l’audience de votre site web).
Sur PageSpeed, vous trouverez votre Total Blocking Time dans la section dédiée aux données Lab data, avec des détails sur des recommandations de Google pour optimiser vos performances.
Notez que le TBT peut être mesuré avec des données Field, mais Google ne le recommande pas et préconise plutôt le FID ou l’INP pour mesurer l’interactivité avec des données de terrain.
Le Total Blocking Time peut également être évalué avec Chrome Dev Tools, et aussi Web Page Test si vous souhaitez définir des conditions de test spécifiques (navigateur, appareil, zone géographique…), ainsi que GTmetrix, SpeedCurve, Calibre…
Visualisation des tâches dans Chrome Dev Tools,
chaque tâche étant représentée sur l’axe horizontal avec sa durée
Choisir les conditions de test est particulièrement pertinent pour simuler des conditions qui correspondent à celles de la majorité de vos visiteurs, et que vous pouvez découvrir grâce à Google Analytics, ou via vos outils d’analyse web.
Pourquoi optimiser le Total Blocking Time ?
Cette question peut sembler rhétorique, mais voici les avantages principaux à retenir pour un site qui optimise le Total Blocking Time :
- une expérience utilisateur améliorée grâce à des pages plus réactives
- et donc de meilleurs taux de conversion avec des utilisateurs satisfaits et engagés,
- une baisse des taux de rebond, car les utilisateurs ont moins de chances de quitter le site par frustration en estimant qu’il ne fonctionne pas,
- une meilleure image de la qualité de votre site et de votre marque ;
- une meilleure note PageSpeed Insights, puisque le TBT entre dans le calcul de ce score ;
- potentiellement un meilleur First Input Delay aussi, puisque ce qui améliore l’interactivité contribue à un meilleur FID,
- par conséquent de meilleurs Core Web Vitals,
- et en toute logique, un meilleur SEO, puisque Google tient compte de la qualité de l’UX dans son algorithme de ranking.
Comment améliorer le Total Blocking Time ?
Avant de vous lancer dans des actions pour optimiser votre vitesse de chargement, pensez au Budget performance !
Il est indispensable pour une vue d’ensemble, savoir d’où vous partez, définir vos objectifs, et évaluer l’impact de vos actions pour accélérer le chargement de vos pages.
En ce qui concerne le Total Blocking Time, le seuil recommandé par Google est de maximum 200 ms (même si, comme nous l’avons vu plus tôt, le seuil pour une bonne UX est de 100 ms).
Et concrètement, quelles sont les techniques pour améliorer le Total Blocking Time ?
- Réduisez l’impact des scripts tiers
- supprimez les scripts qui ne sont pas utiles pour vos pages,
- différez les scripts qui ne sont pas essentiels au début du chargement de la page,
- utilisez des façades qui se chargent rapidement, en attendant le chargement de vos third parties ;
- Réduisez la quantité, le poids et le temps d’exécution de vos JavaScripts
- optimisez votre code JavaScript (minifiez, concaténez et compressez) ;
- Servez vos ressources avec HTTP/3 pour paralléliser vos requêtes ;
- Réduisez le travail du fil principal
- déplacez les tâches longues vers un thread distinct,
- découpez les long tasks en tâches plus petites, et aidez-vous des API qui permettent de savoir le navigateur est occupé ou disponible pour répondre aux interactions,
- vérifiez les erreurs JavaScript et les conflits entre fichiers pour éviter le phénomène de thrashing qui entraîne un rechargement ou un repaint des pages,
- utilisez les CSS pour les animations et les effets au lieu de JavaScript quand c’est possible.
Total Blocking Time : monitorez, optimisez, automatisez
Nous venons de voir les principales bonnes pratiques pour mesurer et pour améliorer le TBT.
Avec des pages et un code optimisé, vous allez faire gagner du temps à vos utilisateurs, et dans le même temps améliorer votre UX, votre SEO et votre CA. De notre côté, nous avons la solution pour aussi faire gagner du temps à vos équipes techniques.
En effet, le travail d’optimisation du front-end d’un site nécessite une attention constante, or un site évolue en continu. Il s’enrichit de nouveaux contenus, de nouvelles fonctionnalités…
Alors, pour ne pas perdre le fruit de votre dur labeur et que les résultats restent visibles à long terme, automatisez toutes les optimisations nécessaires pour respecter les recommandations de Google, et maintenez-les dans la durée sans efforts : faites confiance à notre moteur !
En plus d’appliquer automatiquement les techniques pour optimiser votre TBT, et l’ensemble de vos métriques de web performance, Fasterize se charge de les maintenir même quand votre site évolue ou fait l’objet d’une refonte.
Vous soulagez à la fois vos utilisateurs et vos équipes techniques, en plus de soutenir votre SEO et votre business.
TBT, Core Web Vitals, Speed Index...
Vous voulez maîtriser toutes les métriques webperf essentielles ?
