[et_pb_section fb_built=”1″ _builder_version=”4.16″ _module_preset=”default” custom_padding=”0px||0px||false|false” global_colors_info=”{}”][et_pb_row _builder_version=”4.16″ _module_preset=”default” custom_padding=”||0px||false|false” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_code _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”]
[/et_pb_code][et_pb_text module_class=”article” _builder_version=”4.16″ _module_preset=”default” text_font_size=”18px” text_line_height=”28px” header_3_font_size=”30px” header_4_font_size=”25px” header_5_font_size=”22px” header_6_font_size=”20px” global_colors_info=”{}”]
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 SEO 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 pour optimiser l'expérience utilisateur :
Ainsi, alors que le temps total passé à exécuter des tâches blocking sur le thread principal est de 560 ms, seulement 345 ms de ce temps blocking 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 SEO de performance Lighthouse sur votre site. Ainsi, je vous conseille ces 2 outils SEO pour analyser votre TBT en « laboratoire » :
- Chrome Dev Tools // Lighthouse
- webpagetest.org - permet de réduire les temps de chargement et réduire l'impact des ressources pour réduire le TBT
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, notamment pour identifier les scripts JavaScript bloquants. Voyons ensemble pas à pas ce que sont les quatre grands cas de figure et comment les améliorer.
- Réduire l'impact des fichiers de code tiers sur les tâches principales
- Réduire le temps d'exécution et le blocage des scripts JavaScript
- Minimiser le travail sur le thread principal / Éviter une taille excessive de DOM
- É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 et autres fichiers qu'utilise votre site et à quel point ils sont gourmands :
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 pour utiliser ressources efficacement
- 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 des fichiers de code tiers :
- Utilisation de l’ attribut async ou defer sur les balises
- Établir des connexions précoces aux origines requises
- Chargement paresseux « lazy load »
- 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, notamment sur WordPress, sauf si le script doit s'exécuter avant que la page puisse être rendue.
Les attributs de liens 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.
Pour utiliser les ressources efficacement, 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 pour optimiser la performance utilisateur.
Defer lui s'exécute après que le HTML est totalement analysé et terminé. Il garantit que les fichiers de 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 a mis en place « un cours » interactif avec des exemples d'optimisation pour optimiser le JavaScript tiers, un excellent exemple d'optimisation pratique : 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 faciliter le travail navigateur, vous pouvez utiliser le code suivant :
L'attribut « preconnect » est uniquement pour les connexions les plus critiques comme les fichiers CSS principaux ; pour les domaines tiers moins critiques servant des ressources CSS secondaires, il est préférable d'utiliser « dns-prefetch » pour optimiser le chargement des CSS.
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, améliorant ainsi le TTI (Time to Interactive).
Encore une fois, les publicités ralentissent significativement la tester la vitesse d'un site 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 en permettant de réduire les calculs coûteux, et peut être utilisée pour implémenter cette technique tout en réduisant la charge processeur.
Lazysizes est une bibliothèque JavaScript populaire pour les optimiser le SEO de ses 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 WordPress
Il existe deux méthodes pour optimiser les performances 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 WordPress avec un hébergement relativement qualitatif il est fortement probable que vos serveurs offrent de meilleures performances 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 CSS tiers, ainsi vous pouvez utiliser des techniques que l'on a vues précédemment comme l'auto hébergement des fichiers CSS pour diminuer le temps d'exécution, ou même CSS, code tiers ou non à utiliser avec le lazyload.
Sinon il est possible d’appliquer ces recommandations supplémentaires :
- Minifiez et compressez votre code pour améliorer le FID .
- Supprimez le code inutilisé pour optimiser l'exécution des tâches JavaScript.
- Améliorez la vitesse avec le modèle PRPL (Push / Render / Pre-cache / Lazy load). Cet exemple d'optimisation 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 et l'exécution de votre site, nous avons déjà parcouru longuement ces 6 points d'optimisation et leur exécution pratique.
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. Comprendre ce processus est essentiel pour réduire les tâches longues et optimiser les performances.
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 utilisateur.
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 et des métriques Core Web Vitals, pouvant causer du blocage du rendu :
.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 ? ». Cette complexité peut dégrader l'expérience utilisateur que Google évalue.
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. Ces écarts de performances navigateur utilisateurs sont mesurables par une analyse outils performance dédiée.
3.1.2 Réduire le nombre d'éléments à styliser pour optimiser le FID
Un autre élément à prendre en compte est le changement de style, comme dans cet exemple d'optimisation, é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 et ralentir l'exécution. 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.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
0 commentaires