Comment réduire le temps de blocage sur votre site WordPress ?

Comment réduire le temps de blocage total (TBT) sur votre site WordPress

Les internautes apprécient les sites web agréables, faciles à utiliser et rapides. Pour leur fournir la meilleure expérience utilisateur possible, les webmasters doivent s’intéresser à quelques indicateurs, dont le temps de blocage total (TBT), qui représente 30 % du score global calculé par l’outil Lighthouse de Google Chrome. Il s’agit par conséquent d’un levier d’optimisation incontournable !
Découvrez ce qu’est le temps de blocage total, comment il influe sur les performances de votre site WordPress, et comment l’améliorer pour donner satisfaction aux visiteurs.

Qu’est-ce que le temps de blocage total (TBT) dans Lighthouse ?

Le temps de blocage total est une mesure de performance importante, qui indique la vitesse de chargement du site et d’exécution des codes JavaScript afin que les composants puissent interagir rapidement avec l’utilisateur. Il correspond à la somme de toutes les périodes entre le First Contentful Paint (FCP) et le Time to Interactive (TTI) lorsque la durée d’une tâche dépasse 50 ms. Le score est toujours exprimé en millisecondes. Il compte pour 30 % de la note totale attribuée par Lighthouse.

 

Lighthouse est un outil open source automatisé qui aide les développeurs à améliorer la qualité des pages web. Il se base sur six indicateurs « Core Web Vitals » pour établir un score global :

• le First Contentful Paint (FCP) : délai entre le clic sur l’URL du site et celui où le navigateur affiche le premier bit de contenu de la page.
• le Speed ​​Index : temps de chargement des éléments de la page situés au-dessus de la ligne de
• le Largest Contentful Paint (LCP) : délai d’affichage de la plus large portion de contenu de la page.
• le Total Time to Interactive (TTI): temps nécessaire pour qu’une page devienne interactive
• le Total Blocking Time (TBT): temps de blocage total pour chaque tâche longue (> 50 ms) qui se produit entre FCP et TTI.
• le Cumulative Layout Shift : indicateur de la stabilité visuelle d’une page web.

Métrique	Poids	Qu’est-ce qu’un bon score (vert) ?
First Contentful Paint	10%	0-2 s
Speed Index	10 %	0-4,3 s
Largest Contentful Paint	25%	0-2,5 s
Time to Interactive	10%	0-5 s
Total Blocking Time	30%	< 300 ms
Cumulative Layout Shift	15 %	0-0,1

 

Comment mesurer le temps de blocage total ?

Vous pouvez mesurer le score TBT en calculant le temps total pendant lequel une page est bloquée en attente de réponse à une action de l’utilisateur. Le total est calculé en additionnant le temps de blocage de toutes les longues tâches entre le First Contentful Paint (FCP) et Time to Interactive (TTI).

Pour être plus clair, chaque navigateur comporte un processus qui transforme le code en une page web. L’efficacité du traitement de ce code et des styles permet au visiteur de visualiser immédiatement le contenu.

Le navigateur doit accomplir plusieurs tâches avant de pouvoir afficher la page : l’analyse du script HTML, la construction de la structure et du contenu d’une page web (DOM), ainsi que l’exécution de son code CSS et JS.

Pour éviter un temps de blocage élevé, le navigateur doit contourner les fichiers JS et CSS lors de l’analyse du code et du rendu de la page. Il faut donc « dire » au navigateur ce qu’il doit charger en priorité.

Comprendre les tâches longues

Si les tâches mettent plus de 50 millisecondes à s’exécuter, elles sont appelées des « tâches longues » et considérées comme « bloquées ». Dans ce cas, la page ne répond plus aux actions de l’utilisateur telles que les pressions sur l’écran ou sur les touches du clavier, les clics de souris, etc.

Le calcul du temps de blocage total est basé sur ces tâches longues. Une tâche longue monopolise considérablement le navigateur web et bloque l’exécution d’autres tâches essentielles telles que la réaction à un clic de souris.

Le thread principal est considéré comme « bloqué » à chaque fois qu’il y a une longue tâche. L’ordinateur enregistre l’intervalle généré par chaque requête et additionne tous ces temps de blocage individuels pour obtenir le temps de blocage total.

Un exemple. Chaque fois que Lighthouse détecte une tâche longue (> 50 ms), il mesure également la durée de blocage :

Comme vous pouvez le constater, le Total Blocking Time est calculé en additionnant la partie « bloquante » des différentes tâches longues. La partie bloquante d’une tâche longue est la partie située au-delà de 50 ms (en rouge sur notre graphique).

Voici une autre répartition de tâche pour identifier le TBT :

• La chronologie ci-dessous comporte cinq tâches, dont trois sont des tâches longues (durée > 50 ms) :

• Le graphique suivant montre le temps de blocage pour chacune des tâches longues, respectivement 200 ms, 40 ms et 105 ms (Total : 345 ms) :

2 outils pour mesurer le temps de blocage total

Deux outils sont recommandés pour mesurer le TBT et les performances du site au moyen de la technologie Lighthouse.

1. Google PageSpeed ​​Insight (PSI)

1. GTmetrix

Les deux outils fournissent un score TBT, mais les chiffres sont légèrement différents. Cet écart est dû à divers facteurs, notamment la mise en œuvre de Lighthouse, la méthodologie de test, le lieu de test, etc.

Qu’est-ce qu’un bon score TBT ?

Vous devez vous efforcer de maintenir le TBT en dessous de 300 ms pour garantir une expérience utilisateur satisfaisante. Votre score TBT est simplement une comparaison du TBT de votre page et des TBT de milliers de sites de haut rang lorsqu’ils sont chargés sur un mobile ou un desktop.

Le classement se fait selon un code couleur :

• Vert : 0-300 ms (rapide)
• Orange : 300-600 ms (modéré)
• Rouge : 600+ms (lent)

Le temps de blocage total est souvent associé à la métrique FID (First Input Delay). Explications.

Quelle est la différence entre le temps de blocage total et le délai de première entrée ?

Alors que le temps de blocage total peut être calculé simplement en s’appuyant sur des données théoriques, le délai de première entrée (FID) requiert des données d’utilisateurs réels et ne peut pas être simulé dans un environnement de test. Les données sont issues de plusieurs sources, telles que les Chrome User Experience Reports (CrUX), où les données collectées proviennent d’utilisateurs réels.

Lorsque votre site web ne dispose pas de suffisamment de données « réelles » pour calculer le score FID, l’alternative consiste à examiner la métrique TBT, qui figure parmi les « données de laboratoire ». Il s’agit de données artificielles collectées à partir d’un seul appareil suivant un ensemble de conditions de réseau fixes.

Le TBT et le FID mesurent l’interactivité de différentes façons et capturent la première impression d’un utilisateur sur l’interactivité et la réactivité d’un site.

Par exemple, GTmetrix teste le TBT au lieu du FID, car il diagnostique pratiquement les mêmes optimisations avec les proxys adéquats :

En optimisant votre temps de blocage total, vous améliorez également le score de délai de première entrée, l’une des métriques Core web Vitals qui sont liées entre elles. Bien entendu, l’inverse est également vrai.

Un FID inférieur à 100 ms est bon signe :

Quelle est la différence entre le temps de blocage total et le délai avant interactivité ?

Le délai avant interactivité (TTI) est une autre mesure liée à l’interactivité de votre page. C’est l’une des métriques du rapport Lighthouse servant à mesurer les performances de votre site web.

La principale différence est que Time to Interactive mesure le temps il faut pour qu’une page soit entièrement interactive, tandis que Total Blocking Time indique quelles tâches JS ont pris le plus de temps à s’exécuter.

La mesure du TTI est vitale, car certains sites se concentrent sur la visibilité du contenu au détriment de l’interactivité réelle. Cela peut s’avérer frustrant pour l’utilisateur : il pense que le site est prêt, mais lorsqu’il essaie de cliquer quelque part, rien ne se passe.

Le TTI (en orange ci-dessous) marque une page comme entièrement interactive si le thread principal n’a enregistré aucune tâche longue pendant environ 5 secondes.

Voici un petit test. Dans l’image suivante, quand pensez-vous pouvoir interagir ? Quand le bouton bleu devient-il « cliquable » dans votre esprit ?

Un TTI de moins de 5 secondes est essentiel pour une bonne expérience utilisateur.

Quel est l’impact du temps de blocage total sur les performances ?

Pour comprendre l’impact du TBT sur les performances, il faut souligner son poids sur le score Lighthouse.

En tant que mesure de l’expérience utilisateur, le TBT représente compte actuellement pour 30 % de la note globale dans Lighthouse v8 (il n’existait pas dans Lighthouse v5).

Le TBT mesure le temps total pendant lequel votre page web a été complètement bloquée, empêchant l’utilisateur d’interagir avec son contenu. C’est une métrique théorique importante, car elle définit l’utilisabilité de votre page.

Il existe plusieurs principes fondamentaux à respecter pour que votre TBT ne dépasse pas 300 ms, mais d’abord, il faut analyser les causes d’un mauvais TBT.

Qu’est-ce qui cause un temps de blocage total élevé ?

Il y a quatre raisons qui font grimper le score TBT au-dessus de 300 ms :

1. Un code JavaScript (JS) confus ou inutilisé
2. Un temps d’exécution JS élevé
3. Un travail important effectué sur le thread principal
4. Une utilisation intensive d’un code tiers

La section Opportunités et diagnostics de votre rapport Lighthouse vous aidera à identifier les solutions potentielles à mettre en œuvre :

Le rapport montre l’impact de chaque erreur sur vos gains estimés ; les résoudre améliorera considérablement votre TBT et les performances de votre site.

Voici la liste des recommandations de PageSpeed ​​Insights à prendre en compte pour améliorer votre score TBT :

• Supprimer les JavaScript (JS) inutilisés
• Réduire le temps d’exécution de JavaScript
• Minimiser les CSS et JS
• Éliminer les ressources bloquant le rendu
• Réduire l’impact du code tiers
• Activer la compression de texte
• Éviter de créer des chaînes de requêtes critiques
• Éviter les énormes charges utiles du réseau
• Minimiser la charge sur le thread principal

Comment abaisser le temps de blocage total en dessous de 300 ms sur votre site WordPress

Pour diminuer un score TBT qui excède les 300 ms, vous devez vous concentrer sur les préférences d’ordre et de chargement de vos ressources, ainsi que sur le nombre et la taille des requêtes. Le moyen le plus efficace de réduire le temps de blocage total dans WordPress est d’optimiser les fichiers JavaScript (y compris le code tiers).

Huit démarches d’optimisation de performances de votre site WordPress permettent de corriger le temps de blocage total et améliorer la vitesse de votre site.

1. Différer JS
2. Retarder JS
3. Pré-extraire les requêtes DNS
4. Minimiser JS
5. Utiliser la compression GZip
6. Réduire les fichiers CSS
7. Optimiser la livraison CSS
8. Réduire le temps de réponse du serveur et le temps pour le premier octet (TTFB)
9. Différer JS

Différer JS signifie retarder le chargement des fichiers JS jusqu’à ce que le contenu le plus pertinent s’affiche afin d’augmenter les performances de votre site WordPress. La réduction du temps consacré à l’analyse, à la compilation et à l’exécution des fichiers JS contribue également à l’amélioration du TBT.

Dans la section diagnostic de Lighthouse : traitement des commandes « Éliminer les ressources bloquant le rendu », « Supprimer le code JavaScript inutilisé » et « Éviter d’enchaîner les requêtes critiques ».

• Solution manuelle :
• Utilisez l’attribut « Defer »: pour différer JS, vous pouvez utiliser les attributs booléens « defer » pour la balise de script en HTML :

<script src= »code.js » defer></script>

Les fichiers JS ne seront exécutés qu’une fois le reste de la page chargé.

• Utilisez un plugin WordPress :
• Asset CleanUp: ce plugin gratuit scanne et détecte le contenu à charger sur la page. Lors de l’édition d’une page, il suffit de sélectionner le code CSS ou JS inutile.

Remarque importante : l’auteur du plugin recommande d’utiliser Asset CleanUp avec un plugin de cache comme WP Rocket pour obtenir de meilleurs résultats.

• WP Rocket, plugin WP très puissant a une option pour différer l’analyse de JavaScript ainsi que les fichiers JS WordPress :

2. Retarder JS

L’exécution retardée de JavaScript améliore les performances et le TBT en retardant le chargement de tous les fichiers JS jusqu’à ce que l’utilisateur touche l’écran, fasse défiler le contenu ou clique sur un bouton.

Dans la section diagnostic de Lighthouse : traitement de la commande « Éviter d’enchaîner les demandes critiques ».

• Solution manuelle :

Elle consiste à utiliser la fonction setTimeout ()method, qui appellera une fonction après le temps spécifié en millisecondes. Vous pouvez trouver différents extraits de code pour retarder les fonctions JS, mais en voici un bon exemple :

Si l’on suppose que vous souhaitiez réaliser le scénario suivant :

“User clicks on a button → Wait 2 seconds → the page will display a “Hello, How Are You?”:

<button onclick=”setTimeout(myFunction, 2000)”>Try it</button>

<script>

function myFunction() {

  alert(‘Hello, How Are You? ‘);

}

</script>

• Utilisez un plugin WordPress :
• Flying Scripts : un plugin pour retarder JS et attribuer plus de ressources aux fichiers JS critiques pour une priorisation plus facile.
• WP Meteor : un plugin pour reporter les scripts JS et améliorer notablement la vitesse perçue par les visiteurs (très important pour l’expérience utilisateur).
• Gonzales : permet de désactiver sous condition CSS, JS, et même les plugin selon la page que vous visitez.
• Asset CleanUp (expliqué dans la section ci-dessus).
• Plugin de cache WP Rocket : un moyen pratique et simple pour retarder les fichiers JS d’un seul clic.

3. Pré-chargement des requêtes DNS

DNS-prefetch est une tentative de résolution des noms de domaine avant que les ressources ne soient demandées.

Quand est-ce utile ? Si vous avez un code tiers sur votre site web par exemple une vidéo hébergée sur Vimeo ou certaines polices Google. DNS-prefetch peut donner un petit coup de pouce à votre site web en minimisant le temps de chargement et les ressources provenant d’un autre site web. En d’autres termes, DNS-prefetch vous permet d’établir des connexions précoces avec des scripts tiers, réduisant ainsi les délais et apportant des résultats plus efficaces.

Dans la section diagnostic de Lighthouse : traitement des commandes « Réduire l’utilisation des tiers » et « Pré-connecter aux sources requises ».

• Solution manuelle :

Utilisez « rel=dns-prefetch » dans la section « head ». En d’autres termes, vous pouvez spécifier manuellement le domaine que le navigateur doit pré-charger :

<link rel= »dns-prefetch » href= »//votredomaine.com »>

• Utilisez un plugin WordPress :
• Le plugin Perfmatters comporte des options de pré-chargement DNS
• Le plugin WP Rocket intègre également une section « Prefetch DNS Requests » dans son tableau de bord WordPress :

4. Minimiser JS

Minimiser votre code, c’est supprimer tout encombrement inutile (nouvelles lignes, espaces, etc.) qui prend beaucoup de temps et empêche ou ralentit le chargement de votre page web. En éliminant ce « code mort » de votre script, vous permettez au thread principal de se concentrer sur les tâches importantes.

Dans la section diagnostic de Lighthouse : traitement des commandes « Réduire le temps d’exécution de JavaScript », « Réduire les tâches sur le thread principal » et « Minimiser JS ».

• Solutions manuelles :
• Faites une sauvegarde de votre site, ou évitez d’éditer vos fichiers JS directement sur un serveur de production.
• Utilisez un éditeur de texte comme Sublime Text ou Visual Studio Code. Il est déconseillé de modifier votre code à l’aide de Google Docs, par exemple, cela crée une mise en forme supplémentaire.
• Ouvrez le fichier contenant votre code et supprimez les commentaires, les espaces blancs, les nouvelles lignes et les retraits. N’oubliez pas de raccourcir autant que possible les noms d’ID, de classe ou de variable et d’optimiser votre instruction conditionnelle.
• Utilisez un plugin WordPress :
• Le Closure Compiler de Google aide à la compression JS.
• Le plugin Autoptimize contribue à minimiser JS.
• WP Rocket vous permet de minimiser vos fichiers JS en un clic.

5. Utiliser la compression GZIP

La compression GZIP permet de compresser votre code afin que les fichiers envoyés du serveur au navigateur du visiteur soient moins lourds (et votre site web plus rapide !). Vous pouvez visualiser tous vos HTML, CSS et JS compressés ensemble dans un fichier moins volumineux, réduire les TBT, et par conséquent augmenter les performances.

Dans la section diagnostic de Lighthouse : traitement de la commande « Activer la compression de texte ».

• Utilisez un plugin WordPress :
• Le plugin Activer la compression GZIP vous donne la possibilité d’activer ou désactiver la compression GZIP sur votre site WordPress.
• WP Rocket active automatiquement la compression GZIP.

6. Minimiser les fichiers CSS

Cela réduit la taille de vos fichiers en supprimant les commentaires, le code redondant et les espaces, qui ne sont pas nécessaires pour exécuter la page. Cela réduira la charge CSS et le temps d’analyse global.

Dans la section diagnostic de Lighthouse : traitement des commandes « Réduire la charge du thread principal » et « Réduire les CSS ».

• Solutions manuelles (pour plus de détails, veuillez vous référer à la section JS ci-dessus) :
• Faites une sauvegarde de votre site, ou n’éditez pas vos fichiers CSS directement dans un serveur de production.
• Utilisez un éditeur de texte comme Sublime Text ou Visual Studio Code.
• À l’aide d’un outil web :
• Allez sur minifycode.com et cliquez sur l’onglet CSS minifier.
• Collez le code CSS dans le champ de saisie et cliquez sur le bouton Minify CSS.

• Utilisez un plugin WordPress :
• Autoptimize
• WP Super Minifier
• CSS Nano
• Plugin de cache WP Rocket

7. Optimiser la livraison CSS

Réduire le travail du thread principal en retirant des événements tels que l’analyse CSS libère votre navigateur afin qu’il puisse gérer d’autres processus et tâches nécessaires au fonctionnement optimal de la page web. Par conséquent, il est essentiel d’optimiser la façon dont CSS est délivré.

Dans la section diagnostic de Lighthouse : traitement de la commande « Réduire le travail du thread principal ».

 

• Solutions manuelles :
• Combinez et compressez vos scripts CSS
• Priorisez les règles CSS pour le contenu situé au-dessus de la ligne de flottaison
• Évitez d’utiliser des balises Style dans le corps HTML
• Utilisez un plugin WordPress :
• Le plugin de cache WP Rocket vous aide à optimiser votre diffusion CSS en un clic.

8. Réduire le temps de réponse du serveur et le temps jusqu’au premier octet (TTFB)

Votre serveur doit être rapide et votre TTFB doit être optimisé pour améliorer le score TBT.

Dans la section diagnostic de Lighthouse : traitement de la commande « Réduire le temps de réponse du serveur initial ».

• Utilisez un plugin de cache avancé et un CDN :
• Les plugin de cache WP Rocket et RocketCDN vous aideront à réduire le score TBT.

Comment corriger le score TBT avec WP Rocket

Comme mentionné précédemment, l’exécution de JavaScript est le facteur qui affecte le plus la métrique TBT. En retardant et en différant JavaScript à l’aide de WP Rocket, vous donnerez un précieux coup de pouce à votre site WordPress.

Vous pouvez utiliser plusieurs fonctionnalités de WP Rocket pour réduire l’impact du TBT et améliorer son score. Ci-après une étude de cas.

Exécution de l’audit PageSpeed ​​Insights

Sur la base d’un audit réalisé sur le site web d’un traiteur français nommé « Le point Gourmand… » à l’aide de Google PageSpeed ​​Insights.

Voici les résultats observés

     Score avant activation de WP Rocket                                     Score après utilisation WP Rocket

Score Lighthouse avant activation de WP Rocket : 51/100

• En orange : TBT était de 480 ms et TTI de 7,0 s
• En rouge : l’indice de vitesse était de 6,0 s et le LCP de 7,1 s

Score Lighthouse après utilisation de WP Rocket : 95/100

• En orange : seul le LCP a besoin d’être corrigé, mais on peut remarquer qu’il s’est nettement amélioré.
• En vert : Speed ​​Index, FCP, TTI, CLS, et… TBT !

Les chiffres de la section Opportunités et Diagnostic étaient médiocres lors du premier audit réalisé sans le plugin de cache WP Rocket. Les problèmes détectés par Lighthouse avaient un impact sur le TBT et le score global.

Comme évoqué précédemment, le score TBT est principalement affecté par des problèmes tels que JS confus et inutilisé, un temps d’exécution JS élevé, un travail de thread principal élevé et un code tiers qui consomme beaucoup de ressources. Selon l’audit, le site web n’était pas en très bonne santé et de nombreux problèmes JS/thread principal ont été détectés :

Activation des fonctionnalités de WP Rocket

Lors de l’activation de WP Rocket, les options suivantes ont été activées dans la section Paramètres du site WordPress :

1. Optimisation des fichiers JS (Defer et Delay)
2. Optimisation des fichiers CSS
3. URL à pré-charger

Quelques URL ont été ajoutés au pré-chargement, et cela a encore amélioré le score :

4. Précharger les polices

Lighthouse a également détecté un problème de performances concernant les polices et les icônes utilisées sur le site web. Les fonctions de l’onglet « Précharger les polices » de WP Rocket ont permis d’en venir à bout :

• Développez la section « Preload Key Requests » dans PSI pour identifier les URL concernées par les problèmes.
• Copiez les URL fournies par Lighthouse.
• Collez-les dans la section « Précharger les polices » de votre tableau de bord WP Rocket

Atteindre l’excellence

Enfin, une liste d’« Audits réussis » a considérablement augmenté et le plugin de WP Rocket a permis de venir à bout de problèmes tels que « Minimiser JS », « Réduire les tâches du thread principal », « Supprimer JS inutilisés » ou « Éliminer les ressources bloquant le rendu ».

Le tableau ci-dessous présente les principales problématiques résolues grâce à WP Rocket :

Les recommandations Lighthouse ayant un impact sur le TBT	WP Rocket peut-il résoudre le problème ?
Problèmes liés à JS : éliminez les ressources bloquant le rendu et supprimez le JavaScript inutilisé	Oui – En quelques clics, vous différez et retardez JS et nettoyez le code.
Minimiser les CSS et optimiser la livraison CSS.	Oui – En minimisant le CSS et en utilisant l’option Optimiser la livraison CSS, vous respectez les recommandations PSI.
Minimiser l’utilisation de tiers et pré-connecter aux origines requises	Oui – Vous pouvez utiliser la fonction Prefetch DNS.
Réduire le temps d’exécution JS	Oui – En quelques clics, vous allez réduire, retarder et différer JavaScript et améliorer son temps d’exécution.
Alléger le travail du thread principal	Oui – En différant, retardant et minimisant JS et CSS, vous vous conformez à la recommandation PSI
Réduire le temps de réponse initial du serveur	Oui – En utilisant la mise en cache et un CDN, vous réduisez le temps dès le premier octet.

 

En conclusion

En espérant que ce guide  explicité par l’agence de référencement naturel eGate vous a aidé à comprendre comment optimiser votre score TBT pour votre site WordPress en utilisant quelques étapes concrètes.

Le temps de blocage total est une mesure de performance importante centrée sur l’utilisateur, car il compte pour 30 % de la performance de Lighthouse. Un site web lent peut faire fuir les clients potentiels, nuire à l’expérience utilisateur (UX) de votre site et avoir un impact sur votre référencement naturel.

Le moyen le plus simple et le plus pratique d’obtenir un excellent score TBT consiste à installer une solution comme WP Rocket, qui applique les meilleures pratiques pour accélérer un site web dès sa mise en place.

Besoin d’une agence seo paris pour cela ?

(source : WP Rocket)