Le Total Blocking Time ou TBT est un indicateur précieux et encore sous-exploité. Jusque là, les webperformeurs – dont je fais partie – ont mené leurs efforts sur les temps de chargements puis sur les temps d’interactivité. Mais le contexte a changé. Et derrière ces 3 lettres, TBT, pourrait se cacher un formidable démonstrateur des soucis de conception de certains sites dits “modernes”…
NB : ami lecteur, si tu n’es pas un amateur d’acronyme anglophone passe ton chemin…
Le TBT absent des Web Core Vitals et pourtant…
Google a clairement annoncé la couleur : les Web Core Vitals auront, à partir de 2021, un impact sur le positionnement des sites dans les résultats de son moteur de recherche. Pour rappel, les Web Core Vitals sont composés de 3 indicateurs :
- LCP : Largest Contentful Paint
ou la plus grande “peinture contenante”, mesure la vitesse de livraison (chargement + affichage) du plus grand élément de contenu utile à l’écran. - CLS : Cumulative Layout Shift
mesure les décalages de mise en page successifs, soit la mesure de la stabilité visuelle. - FID : First Input Delay
mesure l’interactivité, le temps de réaction de la page. C’est-à-dire, à partir de combien de temps, l’utilisateur peut interagir avec la page.
Mais il y a pas le TBT là dedans ?
Oui tout à fait, il en est absent ! Alors pourquoi j’en fais un article ? Prenons en compte les 3 indicateurs individuellement…
Pour obtenir un bon temps sur le LCP, il suffira d’identifier votre plus grande zone de contenu utile (généralement une image) et de prioriser son chargement. Pour le coup, c’est assez simple il faut s’assurer que le reste se chargera et/ou s’exécutera plus tard,
- soit avec un attribut loading à la valeur “lazy”
- soit en utilisant un preload ou encore du push HTTP/2 sur le contenu identifié comme LCP (notamment les fonts).
Pour le CLS, là encore il y a peu de mystère. Pour éviter ces décalages de mise en page, il suffit de réserver l’espace aux éléments qui doivent s’afficher à l’intérieur. Il s’agit, ni plus ni moins, d’une bonne pratique en intégration Web.
La difficulté du FID
C’est pour le FID que cela se corse. Déjà, il vous faut savoir que les mesures retenues par Google sont des mesures RUM (Real User Monitoring), plus précisément celles du CrUx (Chrome User experience). De plus, il vous sera très difficile d’avoir une mesure synthétique de cet indicateur. En tout les cas, la mesure à partir d’un test WebPageTest ou Dareboost sera difficilement approchante de celle utilisée par Google. Pourquoi ? Car le RUM prend en compte les données réelles de vos utilisateurs. Ces dernières ont potentiellement un panel de devices extrêmement différents avec des performances différentes… D’où les écarts de mesure.
Pour améliorer son FID, on pourrait être tenté de se rabattre sur le maxFID (le délai maximal d’un FID) ou le TTI (Time To Interactive). Ces deux indicateurs souffrent du même mal : ils sont approximatifs, instables et non standardisés. Et ce n’est pas moi qui le dit :
- sur la doc de Dareboost le MaxFID : “Le Max Potential FID est disponible en tant qu’indicateur en bêta sur Dareboost, car nous faisons une approximation pour certaines pages Web.”
- “Le TTI de Google n’est pas le même que celui des autres” d’après cet excellent article de Boris Schapira.
- Le TTI peut parfois être trompeur : par exemple, deux pages peuvent avoir le même TTI. Mais si l’une divise le travail en tâches plus petites tandis que l’autre monopolise le thread principal avec une tâche très longue, l’expérience utilisateur sera pire dans le second cas.
L’inconvénient est que vous effectuez des mesures synthétiques en phase de développement pour mesurer le gain obtenu par vos optimisations. Mais en production, les données RUM mesure un gain sans aucune mesure avec les mesures précédentes ! Bref, c’est souvent la déception…
Le TBT à la rescousse !
Définition du Total Blocking Time
Dans la plupart des cas, tout le travail de rendu d’un site Web, d’exécution de JavaScript et de réponse aux entrées de l’utilisateur se déroule sur le thread principal (le fil d’exécution principal).
- Si un utilisateur appuie sur un bouton alors que le thread principal est au milieu d’une autre tâche, la réponse est retardée jusqu’à ce que le thread principal soit libre.
- Si ce délai est petit, par exemple inférieur à 50 millisecondes, l’utilisateur ne le remarquera même pas.
- A contrario, si le thread principal est bloqué plus longtemps que cela, l’utilisateur peut rencontrer des retards et une absence de réponse de la page.
Ainsi, le Total Blocking Time (TBT) mesure le temps total occupé par des « Long Tasks » (Tâches longues) durant l’activité principale du thread JavaScript. Une Long Task est un traitement qui dure plus de 50ms et qui monopolise le navigateur web. Pendant le traitement de cette “long Task”, la page web est incapable de répondre à une interaction utilisateur.
NB : le calcul du TBT est effectué entre le FCP (First Contentful Paint) et le TTI.
Intérêt du Total Blocking Time
Dès lors, le TBT nous permet d’identifier les causes d’un délai d’interactivité trop long. Premièrement, il est plus précis que le TTI comme dans l’exemple cité précédemment.
Ici on a le même TTI pour un TBT complètement différent. Dans le premier cas l’expérience utilisateur est certainement plus agréable que dans le second.
Deuxièmement, le calcul du TBT est un algorithme fiable, stable et standardisé. Ainsi, pour vos phases de développement avec des tests synthétiques utilisez le TBT plutôt que le FID (de toute façon vous ne pourrez le mesurer qu’en production), le TTI ou le MaxFID.
D’ailleurs, nous ne sommes pas les seuls à penser ainsi. Si vous observez un rapport WebPageTest, ils ont surtitré 3 indicateurs comme étant Web Vitals : LCP, CLS et …. TBT ! Et non pas le FID pour la simple raison que le FID est un indicateur RUM comme dit précédemment.
D’un point de vue méthode, testez le TBT avec un profil d’appareil plutôt moyenne, voir bas de gamme. Vous noterez que sur WebPageTest, le device par défaut est un Motorola de 4ème génération et sur Dareboost un Galaxy S6.
La recommandation de Google au travers de son outil Lighthouse est d’avoir un TBT inférieur à 300ms.
Comment améliorer le TBT ?
Plusieurs principes de base à respecter pour essayer d’être sous les 300ms pour le Total Blocking Time :
- Divisez votre code JavaScript et chargez en lazy-load ceux qui ne sont pas critiques pour le chargement initial. Bref ne chargez que ce qui est utile quand c’est utile !
- Dans la mesure du possible, divisez le code en fonctions qui font moins de travail et s’exécutent plus rapidement.
- Réduisez les requêtes DOM excessives et même réduisez votre DOM dans la mesure du possible.
- Déchargez les tâches longues en calcul vers des services Worker ou des Web Workers.
Pourquoi est-ce un indicateur d’avenir ?
Déjà parce qu’il va vous permettre d’améliorer votre FID à terme et donc les fameuses Web Vitals qui rentrent en compte en 2021 pour ce qui est des résultats de recherche dans Google.
Ensuite, parce que les sites web sont de plus en plus gourmands en JavaScript, notamment avec l’engouement pour les frameworks JS comme React ou Vue.JS. Et pourtant c’est pas faute de répéter notre leitmotiv “No Fucking JS Spirit”. Or, si vous incluez de plus en plus de JS, votre salut passera par un suivi du TBT pendant le développement.
Photo par Esther Jiao via Unsplash