LinkedIn Link to LinkedIn Twitter Link to Twitter

Comment améliorer le Total Blocking Time (TBT) ?

Mis à jour le 09/08/2022 | Publié le 22/02/2022 | 0 commentaires

Conception de site webSEOTechniqueCore Web VitalsTotal Blocking Time (TBT)

Le temps de blocage total ou Total Blocking Time (TBT) est une métrique à mesurer en laboratoire permettant d’identifier le temps d'apparition du 1er bloc d’une page par rapport au moment où la page devient interactive de manière fiable. Un faible TBT permet de garantir que la page est facilement utilisable. Si la majorité des métriques des Core Web Vitals est à étudier si possible en données sur le terrain, le TBT lui est plus important à analyser en laboratoire.

Qu’est ce que le TBT ?

Petite piqûre de rappel, le FCP est une métrique indiquant le moment où le premier texte ou la première image est affichée. Le TTI pour "Time to Interactive" correspond au temps nécessaire pour que la page devienne entièrement interactive.

La métrique Total Blocking Time (TBT) mesure le temps total entre First Contentful Paint (FCP) et Time to Interactive (TTI). Expliqué plus techniquement, le TBT est une somme en millisecondes de toutes les périodes entre le First Contentful Paint et le Time to Interactive, lorsque la durée d’une tâche dépasse 50 ms.

Le thread principal est considéré comme « bloqué » à chaque fois qu'il y a une tâche longue. Une tâche longue s'exécute pendant plus de 50 ms.

Pour illustrer, prenons en exemple cette timeline, dans cette exemple il y a 5 tâches, dont 3 supérieures à 50ms.

Voici donc comment sera construite votre note TBT :

Le fonctionnement de calcul du Total Blocking Time avec une timeline

Ainsi, alors que le temps total passé à exécuter des tâches sur le thread principal est de 560 ms, seulement 345 ms de ce temps seront considérées comme du temps de blocage.

Note : Le TBT est le critère le plus important des Core Web Vitals (30 % de la note)

Comment mesurer le TBT ?

Le TBT est une métrique qui nécessite d’être mesurée en laboratoire. La meilleure façon de mesurer le TBT est d'effectuer un audit de performance Lighthouse sur votre site. Ainsi, je vous conseille ces 2 outils pour analyser votre TBT en « laboratoire » :

  • Chrome Dev Tools // Lighthouse
  • webpagetest.org

Google recommande que cette métrique soit analysée en laboratoire et non sur le terrain puisque l'interaction de l'utilisateur pourrait affecter le TBT de votre page d'une manière pouvant entraîner de nombreuses variations dans vos rapports.

Note : Une bonne note de TBT est de 200ms.

Améliorer sa note TBT (Total Blocking Time)

Pour savoir comment améliorer le TBT, vous pouvez exécuter un audit de performance Lighthouse et vous aider des opportunités suggérées par l'audit. Voyons ensemble pas à pas ce que sont les quatre grands cas de figure et comment les améliorer.

  1. Réduire l'impact du code tiers
  2. Réduire le temps d'exécution de JavaScript
  3. Minimiser le travail sur le thread principal / Éviter une taille excessive de DOM
  4. Éviter les tâches longues dans le thread principal

1. Réduire l’impact du code tiers

Un code tiers est tout simplement un script hébergé sur un domaine différent du domaine de l'URL que vous avez audité avec Lighthouse. Au fur et à mesure que la page se charge, Lighthouse calcule combien de temps chacun des scripts tiers bloque le thread principal. Si le temps de blocage total est supérieur à 250 ms, l'audit échoue.

Les cas récurrents sont des scripts tiers comme Google Analytics, des polices qui ne sont pas hébergées par vos soins, des scripts de A/B testing, etc.

En utilisant Lighthouse, vous pourrez rapidement évaluer les scripts tiers qu’utilise votre site et à quel point ils sont gourmands :

Vue du Total Blocking Time avec l'outil Google Page Speed (lighthouse)

Si un script tiers ralentit le chargement de votre page, vous avez seulement deux options pour améliorer les performances étant donné que vous n’en avez pas le contrôle :

  • Supprimez-le s'il n'ajoute pas ou peu de valeur à votre site
  • Optimisez le processus de chargement afin qu’il ne bloque pas le thread

Voici 4 techniques que nous allons voir pour réduire l’impact du code tiers :

  1. Utilisation de l' attribut async ou defer sur les balises
  2. Établir des connexions précoces aux origines requises
  3. Chargement paresseux « lazy load »
  4. Optimiser la façon dont vous vous servez des scripts tiers

1.1 Utilisez async ou defer

Étant donné que les scripts synchrones retardent la construction et le rendu du DOM, vous devez toujours charger les scripts tiers de manière asynchrone, sauf si le script doit s'exécuter avant que la page puisse être rendue.

Les attributs async et defer indiquent au navigateur qu'il peut continuer à analyser le code HTML pendant le chargement du script en arrière-plan, puis exécuter le script après son chargement. De cette façon, les téléchargements de scripts ne bloquent pas la construction du DOM et le rendu des pages. Le résultat est que l'utilisateur peut voir la page avant que tous les scripts aient fini de se charger.

Voici ce que cela donne en code :

<script async="" src="script.js">
<script defer src="script.js">

La différence entre async et defer est le moment auquel ils vont commencer à exécuter le script.

Expliqué simplement, il est probable que les scripts async ne soient pas exécutés dans l'ordre dans lequel ils apparaissent dans le code HTML. Cela signifie également qu'ils peuvent interrompre la construction du DOM s'ils terminent le téléchargement alors que le code HTML est toujours en cours d’analyse.

→ Utilisez async s'il est important que le script s'exécute plus tôt dans le processus de chargement.

Defer lui s’exécute après que le HTML est totalement analysé et terminé. Il garantit que les scripts seront exécutés dans l'ordre dans lequel ils apparaissent dans le code HTML et ne bloqueront pas l'analyseur.

→ Utilisez defer pour les scripts tiers moins critiques. Comme le serait par exemple un script tiers de publicité.

Note : Si vous souhaitez progresser rapidement, Google à mis en place « un cours » interactif pour optimiser le JavaScript tiers : https://web.dev/codelab-optimize-third-party-javascript/

1.2 Se préconnecter aux ressources tierces critiques

Si un script tiers est jugé comme important (critique) pour le bon fonctionnement de votre site et de sa mise en page, plutôt que d’améliorer la note en chargeant en différé le script, il est également possible de se préconnecter au nom de domaine. Ainsi, il vous sera possible d’économiser entre 50ms et 500ms. En revanche, il est déconseillé d’utiliser cette technique sur tous vos scripts tiers étant donné que cela pourrait retarder d’autre ressources importantes.

Pour cela vous pouvez utiliser le code suivant :

<link rel="preconnect" href="https://exemple.fr">

L’attribut « preconnect » est uniquement pour les connexions les plus critiques ; pour les domaines tiers moins critiques, il est préférable d’utiliser .

En revanche, il est probable que tous les navigateurs ne prennent pas en compte l’attribut « preconnect », c’est pourquoi le préchargement avec « preconnect » doit aussi être spécifié en « dns-prefetch> pour servir de solutions de secours.

Voici un exemple :

<link rel="preconnect" href="https://exemple.fr">
<link rel="dns-prefetch" href="https://exemple.fr">

1.3 Améliorer le chargement du code tiers avec lazyload

Si des codes tiers ne sont pas critiques ou sont en « dessous de la ligne de flottaison » (c'est-à-dire si les utilisateurs doivent faire défiler la page pour les afficher), le chargement différé est un bon moyen d'améliorer le TBT ainsi que les métriques LCP & FCP. De cette façon, vos utilisateurs obtiendront le contenu important de la page en priorité.

Appelée aussi chargement paresseux, cette technique consiste à charger du contenu tiers uniquement lorsque les utilisateurs font défiler jusqu'à la section concernée.

Encore une fois, les publicités ralentissent significativement la vitesse d’une page, en les chargeant lorsque les utilisateurs sont à l’endroit où elles sont affichées. Vous priorisez ainsi toutes les ressources importantes pour votre site. Selon Google, MediaVine est passé aux annonces à chargement différé et a constaté une amélioration de 200 % de la vitesse de chargement des pages.

Intersection Observer est une API de navigateur qui détecte efficacement lorsqu'un élément entre ou sort de la fenêtre d'affichage du navigateur et peut être utilisée pour implémenter cette technique.

Lazysizes est une bibliothèque JavaScript populaire pour les images à chargement différé et les iframes comme les widgets YouTube. Il a également un support optionnel pour IntersectionObserver.

Si vous utilisez WordPress, le plus simple est de télécharger un plugin le faisant pour vous comme le fait très bien WP Rocket. Je vous invite à vous informer sur le lazy load en fonction de votre technologie.

1.4. Optimisez la vitesse des scripts tiers

Il existe deux méthodes pour optimiser la vitesse du code tiers, soit par le biais d’un CDN soit en auto hébergeant vos scripts. En général, les outils vous proposant du code tiers utilisent des URL avec un CDN intégré. Donc si vous souhaitez optimiser la vitesse des scripts, le meilleur moyen est d’auto héberger vos scripts. Si vous utilisez un hébergement relativement qualitatif il est fortement probable que vos serveurs soient plus rapides et que vous ayez un contrôle total sur le cache. Cela évite également des recherches inutiles comme la recherche DNS, le temps que le navigateur établisse une nouvelle connexion HTTP, qu’il effectue une négociation SSL avec l’autre serveur, …

Il est tout de même important de savoir qu’en auto hébergeant les codes tiers, il est probable que le code ne soit pas fonctionnel, dans tous les cas il faudra mettre en place régulièrement une maintenance sur le code étant donné que les mises à jour automatiques ne seront pas actualisées de votre coté.

2. Réduisez le temps d'exécution de JavaScript

Honnêtement il n’y a pas énormément d’optimisation possible que l’on n’ait pas déjà vue pour diminuer cette métrique. Il est probable que dans cette partie de l’audit il y ait également du code tiers, ainsi vous pouvez utiliser des techniques que l’on a vues précédemment comme l’auto hébergement pour diminuer le temps d’exécution, ou même code tiers ou non à utiliser avec le lazyload.

Sinon il est possible d’appliquer ces recommandations supplémentaires :

  • Minifiez et compressez votre code .
  • Supprimez le code inutilisé .
  • Améliorez la vitesse avec le modèle PRPL (Push / Render / Pre-cache / Lazy load). Cela consiste à utiliser « preload », « async », « un cache », « lazy load ».

N’hésitez pas à compléter votre lecture avec notre article pour améliorer la note LCP, nous avons déjà parcouru longuement ces 6 points.

3. Réduisez le travail du thread principal & Évitez une taille excessive de DOM

Le processus de rendu du navigateur est ce qui transforme votre code en une page Web avec laquelle vos utilisateurs peuvent interagir. Par défaut, le thread principal du processus de rendu gère généralement la plupart du code : il analyse le HTML et construit le DOM, analyse le CSS et applique les styles spécifiés, analyse, évalue et exécute le JavaScript.

Le thread principal traite également les événements utilisateur. Ainsi, chaque fois que le thread principal est occupé à faire autre chose, votre page Web peut ne pas répondre aux interactions des utilisateurs (TBT), ce qui entraîne une mauvaise expérience.

3.1 Optimisez le CSS pour le calcul du thread

La complexité des calculs de style peut considérablement augmenter le travail du thread. Selon Rune Lillesveen (navigateur Opéra) : « Environ 50 % du temps utilisé pour calculer le style calculé d'un élément est utilisé pour faire correspondre les sélecteurs, et l'autre moitié du temps est utilisée pour construire le RenderStyle (représentation du style calculé) à partir des règles correspondantes ».

Ainsi, il serait préférable de réduire la complexité de vos sélecteurs, ce code par exemple est bon :

.title {
/* styles */
}

En revanche, ce genre de sélecteur CSS sera considéré comme une mauvaise pratique en termes de performance :

.box:nth-last-child(-n+1) .title {
/* styles */
}

Effectivement, afin de savoir que les styles doivent s'appliquer, le navigateur doit effectivement demander « est-ce un élément avec une classe de titre qui a un parent qui se trouve être le moins nième enfant plus 1 élément avec une classe ? ».

Cela peut prendre beaucoup de temps, selon le sélecteur utilisé et le navigateur en question. Pour savoir, par exemple, que l'élément est le dernier de son type, le navigateur doit d'abord tout savoir sur tous les autres éléments et s'il y a des éléments qui viennent après lui qui seraient le nième- last-child, ce qui est potentiellement beaucoup plus coûteux que de simplement faire correspondre le sélecteur à l'élément car sa classe correspond.

3.1.2 Réduire le nombre d'éléments à styliser

Un autre élément à prendre en compte est le changement de style, évitez d’ajouter du CSS inutile si l’élément était déjà correctement défini, sinon ajoutez un nouveau sélecteur CSS.

.box {
width: 20px;
height: 20px;
}
/**
* Changing width and height
* triggers layout.
*/
.box--expanded {
width: 200px;
height: 350px;
}

Et même tout simplement évitez un grand nombre de sélecteurs CSS qui peuvent être inutiles. Par exemple, une bonne pratique serait d’appliquer un maximum de style sur la balise body et pas de créer un sélecteur CSS pour chaque texte, comme le ferait un visual builder WordPress 😉

S'il n'est pas possible d'éviter la mise en page, la clé est d'utiliser Chrome DevTools pour voir combien de temps cela prend, puis de déterminer les éléments à problème afin de prioriser l’impact. Pour cela ouvrez DevTools, accédez à l'onglet Chronologie, cliquez sur Enregistrer et interagissez avec votre site. Lorsque vous arrêtez l'enregistrement, vous verrez une répartition des performances de votre site.

Malheureusement, cela à beau être un guide complet, uniquement focalisé sur le TBT il serait trop long de lister toutes les optimisations possibles, je tenais à le préciser. J’ai donc essayé le plus possible de proposer les optimisations pouvant avoir le plus d’impact et les moins complexes…

3.1.3 Quelques optimisations supplémentaires pour optimiser le CSS

Voici quelques idées supplémentaires pour réduire le thread principal en travaillant sur l’optimisation du CSS :

  • Extraire le CSS critique
  • Minifier CSS
  • Différer les CSS non critiques
  • Supprimer les CSS inutilisés.

Étant donné que ces 4 points influencent également le LCP, ils ont déjà été longuement traités, je vous invite ainsi vivement à consulter l’article en question vous guidant pas à pas dans ce processus. En même temps, le LCP (Largest Contentful Paint) est relié au FCP (First Contentful Paint) et le TBT est une mesure de blocage entre le FCP et le TTI.

3.2. Optimiser JavaScript

Les optimisations précédentes sont aussi valables pour optimiser votre JavaScript, c’est à dire minifier, différer, supprimer… Il est également à noter que d’autres optimisations dans notre article sur le LCP pourraient impacter elles aussi votre TBT comme en réduisant les charges utiles JavaScript.

4. Évitez les tâches longues dans le thread principal

Oui, c’est bientôt la fin ! J’espère que vous n’êtes pas trop déçu, en tout cas si vous êtes encore ici bravo. Je vais me répéter et j’en suis navré, mais je vous invite vivement à compléter votre lecture sur notre guide complet du LCP, qui est d’ailleurs le 2ème plus grand facteur des Core Web Vitals (25 % de la note) et qui vous guide dans les optimisations juste en dessous.

Mais bon, je vais quand même préciser les points importants pour limiter les tâches longues, qui consistent simplement à réduire le nombre de ressources et leurs tailles :

  • Optimisez votre JS / CSS
  • Optimisez vos images / iframes / vidéos et n’utilisez pas de .gif
  • Optimisez vos polices
  • Investissez dans un bon hébergement

Si vous avez des questions, des suggestions ou n’importe quoi d’autre, n’hésitez pas à me ping sur Twitter ou à écrire un commentaire ! Si cet article vous a plu, il peut être partagé avec joie. Mais surtout, merci pour votre lecture.

 

Auteur

Stan De Jesus Oliveira
Propriétaire et fondateur de createur2site

Stan De Jesus Oliveira est le propriétaire de createur2site, il accompagne les entreprises dans leur création de site web, le Web Design et le référencement naturel SEO.

0 commentaires

Soumettre un commentaire

Votre adresse e-mail ne sera pas publiée.