Qu'est-ce que le TLN ?
La métrique de temps de blocage total mesure le temps total après First Contentful Paint (FCP) pendant lequel le thread principal a été bloqué suffisamment longtemps pour empêcher la réactivité aux entrées.
Par défaut, Lighthouse arrête la surveillance du suivi avancé des conversions après le délai d'interaction (TTI), tout comme d'autres outils de l'atelier qui mesurent le chargement des pages. Consultez Quel est le rapport entre le TBT et le TTI ?
Le thread principal est considéré comme "bloqué" chaque fois qu'une tâche Long Task est exécutée sur le thread principal pendant plus de 50 millisecondes. Nous disons que le thread principal est "bloqué", car le navigateur ne peut pas interrompre une tâche en cours. Par conséquent, si un utilisateur interagit avec la page au milieu d'une tâche longue, le navigateur doit attendre la fin de la tâche avant de pouvoir répondre.
Si la tâche est suffisamment longue (supérieure à 50 millisecondes), il est probable que l'utilisateur remarque ce retard et perçoive la page comme lente ou non fonctionnelle.
Le temps de blocage d'une tâche longue donnée est sa durée supérieure à 50 millisecondes. Le temps de blocage total d'une page correspond à la somme du temps de blocage de chaque tâche longue qui se produit après le FCP pour la période mesurée (généralement le TTI pour les outils de chargement de page ou la durée de trace totale pour les autres outils).
Prenons l'exemple du diagramme suivant du thread principal du navigateur lors du chargement de la page :
La chronologie représentée dans l'image précédente comporte cinq tâches, dont trois sont des tâches longues, car leur durée dépasse 50 millisecondes. Le schéma suivant montre le temps de blocage pour chacune des longues tâches:
Ainsi, bien que le temps total passé à exécuter des tâches sur le thread principal soit de 560 millisecondes, seuls 345 millisecondes de ce temps sont considérés comme du temps de blocage.
| Durée de la tâche (millisecondes) | Temps de blocage des tâches (millisecondes) | |
|---|---|---|
| Tâche 1 | 250 | 200 |
| Tâche 2 | 90 | 40 |
| Tâche 3 | 35 | 0 |
| Tâche 4 | 30 | 0 |
| Tâche 5 | 155 | 105 |
| Durée totale de blocage | 345 millisecondes | |
Quel est le lien entre le TBT et l'INP ?
Le décompte est antérieur à l'INP et est utile comme indicateur des problèmes INP, en particulier dans l'environnement de laboratoire où il est plus difficile de mesurer l'INP. Cependant, l'outil de navigation détaillée peut signaler les problèmes potentiels s'il n'y a pas de problème pour les utilisateurs, s'ils n'interagissent pas à ce moment-là. Il peut également passer à côté des problèmes causés par les interactions lorsqu'ils sont mesurés dans l'environnement de laboratoire. Nous vous recommandons de mesurer l'INP sur le terrain pour évaluer les problèmes de réactivité réels ressentis par les utilisateurs. La métrique "TBT" peut être une métrique de proxy raisonnable pour l'INP dans le cadre de l'atelier, mais elle ne remplace pas INP en soi.
Quel est le lien entre le TTI et le TTI ?
Le TTC est mesuré sur une période donnée. Pour certains outils d'analyse qui mesurent traditionnellement le chargement des pages, y compris Lighthouse, le TBT a été mesuré jusqu'au TTI, car il permet de quantifier le degré de non-interactivité d'une page avant qu'elle ne devienne réellement interactive. Toutefois, le taux de change peut également continuer à être mesuré après le chargement de la page, et ainsi de suite au-delà du TTI, par exemple en mode période Lighthouse.
TTI considère qu'une page est "interactive de manière fiable" si le thread principal n'a pas été occupé par des tâches longues pendant au moins cinq secondes. Cela signifie que trois tâches de 51 ms réparties sur 10 secondes peuvent repousser le TTI jusqu'à une seule tâche de 10 secondes, mais ces deux scénarios peuvent sembler très différents pour un utilisateur qui tente d'interagir avec la page.
Dans le premier cas, trois tâches de 51 ms auraient un temps de latence de 3 millisecondes. Alors qu'une tâche unique de 10 secondes aurait un temps de latence de 9 950 millisecondes. Dans le second cas, plus la valeur de MT est élevée, plus l'expérience est nuisible.
Cet exemple montre pourquoi le TTI est souvent une meilleure métrique que le TTI, car il est moins sujet aux anomalies. C'est même le cas lorsque le TTI est utilisé comme point de terminaison pour le TBT.
Mesurer le TEC
Le TBT est une métrique qui doit être mesurée en laboratoire. La meilleure façon de mesurer le TA est d'exécuter un audit de performances Lighthouse sur votre site. Pour en savoir plus, consultez la documentation Lighthouse sur le TBT.
Il est possible d'évaluer le taux de conversion sur le terrain, mais nous vous déconseillons de le faire, car l'interaction des utilisateurs peut avoir une incidence sur le volume de données de conversion personnalisé de votre page, ce qui peut entraîner de nombreux écarts dans vos rapports. Nous vous conseillons plutôt d'utiliser la nouvelle API Long Animations Frame dans le champ si vous souhaitez aller au-delà d'une seule interaction INP.
Outils de l'atelier
Quel est un bon score TBT ?
Afin d'offrir une expérience utilisateur de qualité, les sites doivent s'efforcer de limiter le temps total de blocage à moins de 200 millisecondes lorsqu'ils sont testés sur du matériel mobile standard.
Pour en savoir plus sur l'impact du TBT de votre page sur votre score de performances Lighthouse, consultez Comment Lighthouse détermine votre score TBT.
Améliorer le TBT
En général, nous recommandons d'optimiser INP plutôt que le TBT, car il est recommandé d'utiliser l'INP comme métrique proxy pour l'INP dans l'atelier (où l'INP ne peut généralement pas être mesurée avec précision). Par conséquent, pour améliorer le ciblage par types d'appareil, consultez nos conseils pour optimiser INP.
Si vous vous intéressez spécifiquement à cet outil, vous pouvez effectuer un audit de performances Lighthouse et prêter attention aux opportunités spécifiques suggérées par l'audit.
En général, l'amélioration du suivi avancé des conversions pour un site implique de réduire le nombre de scripts bloquants, c'est-à-dire de les optimiser pour réduire le blocage ou de réduire le nombre global de scripts. Consultez les guides de performances suivants :