Guides

Qu'est-ce que le Total Blocking Time (TBT) ? La métrique la plus lourde du score Lighthouse

vuetelemetry
Guides
7 min de lecture

Le TBT pèse 30 % du score de performance Lighthouse, plus que toute autre métrique, et ce n'est pas un Core Web Vital. Ce qu'il compte, pourquoi seule la part d'une tâche au-delà de 50 ms est mesurée, et pourquoi découper son JavaScript vaut mieux que le réduire.

Le Total Blocking Time est la métrique qui pèse le plus dans le score de performance Lighthouse, 30 %, devant le LCP et le CLS à 25 % chacun. Ce n'est pourtant pas un Core Web Vital, et tenir ces deux faits ensemble est précisément la raison de bien le comprendre.

Ce qu'il mesure n'est pas la durée de chargement de votre page. Il mesure combien de temps le navigateur a été trop occupé pour vous répondre.

Ce que le TBT compte réellement

Des voitures arrêtées pare-chocs contre pare-chocs, feux stop allumés. Un véhicule qui n'avance pas bloque tout ce qui le suit, exactement ce qu'une seule tâche longue fait au fil d'exécution principal.

Pendant le chargement, le navigateur exécute votre JavaScript sur le fil principal, celui-là même qui traite les clics et les frappes au clavier. Tant qu'un travail s'y déroule, rien d'autre ne peut arriver. Une tâche qui occupe le fil principal plus de 50 millisecondes s'appelle une tâche longue, et c'est l'unité à partir de laquelle le TBT est construit.

Voici la partie qui surprend. Le TBT ne compte pas la tâche entière, seulement la part au-delà du seuil de 50 ms. Une tâche de 70 ms apporte 20 ms. Une tâche de 45 ms n'apporte rien du tout. Le TBT est la somme de ces parts bloquantes pour chaque tâche longue située entre le First Contentful Paint et le moment où la page devient interactive.

La limite de 50 ms n'est pas arbitraire. C'est à peu près le point où une personne remarque que l'interface n'a pas répondu tout de suite : la métrique compte donc le temps pendant lequel la page a été visiblement inerte, pas le temps qu'elle a passé à travailler.

Pourquoi il pèse 30 % sans être un Core Web Vital

Lighthouse classe le TBT en trois paliers, mesurés sur son appareil mobile simulé : bon à 200 ms ou moins, à améliorer entre 200 et 600 ms, mauvais au-delà de 600 ms. Ces chiffres supposent un téléphone de milieu de gamme, délibérément plus lent que la machine depuis laquelle vous testez.

Bon - 200 ms ou moins
À améliorer - entre 200 et 600 ms
Mauvais - au-delà de 600 ms

Le TBT est une métrique de laboratoire. Elle est mesurée dans une exécution contrôlée, avec un profil d'appareil fixe et sans utilisateur réel, et c'est exactement pourquoi ce n'est pas un Core Web Vital : les Core Web Vitals sont des métriques de terrain collectées sur de vraies visites. Son équivalent de terrain est l'Interaction to Next Paint, et les deux sont liées sans être la même chose.

Le TBT regarde le fil principal bloqué pendant le chargement. L'INP regarde ce qui s'est réellement passé quand une personne a interagi, à n'importe quel moment de la visite. Une page peut afficher un TBT correct et un INP mauvais parce que le travail coûteux arrive plus tard, à l'ouverture d'un menu ou à l'application d'un filtre.

Ce qui le dégrade

Les causes sont presque toujours du JavaScript, et généralement sous l'une de trois formes. Un gros bundle doit être analysé, compilé puis exécuté avant que quoi que ce soit d'autre ne tourne, et ce travail atterrit sur le fil principal d'un seul bloc.

L'hydratation du framework est la deuxième source courante. Le HTML rendu côté serveur arrive vite, puis le framework parcourt l'arbre de composants pour y rattacher le comportement, et sur une grande page ce parcours forme une seule tâche longue au moment précis où l'utilisateur est le plus susceptible d'essayer de cliquer.

Les scripts tiers sont la troisième, et la moins maîtrisée. Gestionnaires de balises, analytique, widgets de chat et bandeaux de consentement exécutent chacun leur propre travail sur votre fil principal, selon un calendrier que vous ne fixez pas, et leur coût n'apparaît presque jamais dans le budget de bundle de qui que ce soit.

Découper vaut mieux que réduire

Le réflexe est de réduire la taille du bundle. Cela aide, mais ce n'est pas le même levier, et c'est la chose la plus utile à savoir sur le TBT. La métrique compte le temps au-delà de 50 ms par tâche : la même quantité de travail découpée en plusieurs tâches courtes obtient donc un bien meilleur score qu'une seule longue, à octets strictement identiques.

C'est pourquoi rendre la main compte. Découper une boucle lourde pour que le navigateur puisse traiter les entrées entre deux morceaux, déplacer un calcul dans un Web Worker où il ne touche pas du tout au fil principal, et différer les tiers jusqu'à ce que la page soit utilisable réduisent tous le TBT sans retirer une seule ligne de logique.

- vuetelemetry

Le laboratoire et le terrain ne mesurent pas la même chose

Une réserve honnête avant d'optimiser pour le chiffre. Une exécution de laboratoire utilise un seul profil d'appareil et ne clique jamais sur rien : le TBT peut donc paraître bon pendant que de vrais utilisateurs sur du matériel moins cher attendent encore. Traitez-le comme un diagnostic qui vous dit où le fil principal est occupé, et allez voir les données de terrain pour ce que les gens ont réellement vécu.

Lues ensemble, les deux répondent à des questions différentes. Le TBT vous dit que la page a été bloquée pendant le chargement, et grossièrement de combien. L'INP vous dit si cela a compté pour quelqu'un.

FAQ

Qu'est-ce qu'un bon Total Blocking Time ?

200 ms ou moins dans une exécution Lighthouse, qui utilise un appareil mobile de milieu de gamme simulé. Entre 200 et 600 ms, c'est à améliorer, et au-delà de 600 ms, c'est mauvais. Comme l'exécution est bridée, un chiffre mesuré sur votre propre portable sans bridage n'est pas comparable et paraîtra en général bien meilleur que la réalité.

Le Total Blocking Time est-il un Core Web Vital ?

Non. Les Core Web Vitals sont le Largest Contentful Paint, l'Interaction to Next Paint et le Cumulative Layout Shift, et ils sont collectés sur de vraies visites. Le TBT est une métrique de laboratoire mesurée dans une exécution contrôlée, ce qui explique qu'il puisse peser 30 % du score de performance Lighthouse tout en restant hors de l'ensemble qui touche au classement.

Quelle est la différence entre TBT et INP ?

Le TBT mesure le blocage du fil principal pendant le chargement, en laboratoire, sans aucun utilisateur qui interagit. L'INP mesure le temps qu'ont mis de vraies interactions à produire une réponse visible, à n'importe quel moment de la visite. Les deux sont corrélés, puisqu'un fil principal occupé nuit aux deux, mais une page peut bien s'en sortir en TBT et mal en INP quand le travail coûteux arrive après le chargement.

Pourquoi une tâche de 45 ms ne compte-t-elle pour rien ?

Parce que le TBT ne compte que la part d'une tâche au-delà de 50 ms. Une tâche de 45 ms n'est pas une tâche longue et apporte zéro ; une tâche de 70 ms apporte 20 ms. Le seuil correspond à peu près au moment où une personne commence à remarquer que l'interface n'a pas répondu : la métrique mesure donc l'inertie perceptible plutôt que le travail total.

Comment réduire le Total Blocking Time ?

Découpez le travail avant d'essayer de le supprimer. La même quantité de JavaScript répartie en tâches courtes obtient un bien meilleur score qu'une seule tâche longue : rendez donc la main au navigateur entre deux morceaux, déplacez les calculs dans un Web Worker et différez les scripts tiers jusqu'à ce que la page soit utilisable. Réduisez ensuite ce que vous livrez : découpage du code, suppression des dépendances inutilisées et allègement du coût d'hydratation sur les grandes pages.