UI-Google-lighthouse-v6

Comment le score PageSpeed Insights, qui repose sur Lighthouse, est-il calculé ? Quelles sont les métriques webperf qui entrent dans le calcul de la note, et avec quelle importance ? Quelle différence d'une version à l'autre du score Lighthouse ? Nous vous aidons à y voir clair et à comprendre l’impact sur votre score PageSpeed.

De nouvelles métriques webperf entre la v5 et la v6 de Lighthouse

Lighthouse établit un score de performance sur la base de différents indicateurs. 6 métriques webperf sont prises en compte, signalées par le picto Lighthouse dans le graphique ci-dessous :

lighthouse-google-v6-metrics

 

Pour rappel, voici ceux qui étaient utilisés pour la v5, dont les poids respectifs sont détaillés ici par Google :

Voici pour commencer ce qui change dans la v6 :

google-lighthouse-v5-vs-v6-web-performance

Quel est l'impact de la v6 sur le score PageSpeed Insights par rapport à la v5 ? Pour tester concrètement les effets des changements, Paul Irish propose ici un simulateur. Il permet de comparer facilement un score entre les différentes versions de Lighthouse. Le poids de chaque métrique y est précisé, comme on le voit dans la capture ci-après. Voici le poids attribué à chaque métrique dans la v6, et la comparaison avec celui attribué dans la v5 :

 

https://www.fasterize.com/wp-content/uploads/2020/03/lighthouse-v6-metrics-weight-paul-irish.png

 

Pourquoi ces changements dans le calcul du score PageSpeed Insights ?

Les indicateurs qui ont été abandonnés depuis la v5 présentaient des lacunes que la v6 vient compenser. Tour d’horizon des évolutions et des raisons qui les ont motivées (et pour suivre les prochaines évolutions, nous vous invitons à vous abonnez à notre newsletter mensuelle, nous gardons l’œil ouvert pour vous !)

Le Largest Contentful Paint remplace le First Meaningful Paint, qui était trop imprécis

Pourquoi avoir mis de côté le First Meaningful Paint ? Parce qu’il était loin d’être parfait en raison de son manque de fiabilité. Il est censé indiquer le moment où les contenus principaux sont chargés sur la page en se basant sur des données réelles (RUM), mais la marge d’erreur est malheureusement assez importante. C’est pourquoi il est remplacé par le Largest  Contentful Paint qui permet d’indiquer le moment où apparaît l’élément le plus important en termes de taille. C’est un point de repère dans le temps qui traduit mieux l’expérience utilisateur.

Le poids du Time To Interactive est divisé par 2 entre la version 5 et la version 6

Métrique sujette à discussions, le Time To Interactive (TTI) représentait 33 % du score v5, il passe à 15 % dans la v6. Mais alors que l’interactivité a de plus en plus d’importance dans l’évaluation de la webperf, pourquoi réduire le poids du TTI ? Tout simplement parce qu’il n’est pas parfaitement fiable, lui non plus. Nous allons voir qu'il est encore réduit dans la version 8.

Sa limite réside principalement dans le fait que le TTI est censé mesurer le temps de CPU, mais beaucoup de sites voient l’interactivité retardée à cause de Third Parties. Le poids du TTI dans le calcul du score Lighthouse était donc pénalisant, particulièrement pour ces sites.

Pour aller plus loin, les faiblesses du TTI sont d’ailleurs expliquées par Boris Schapira sur le blog de Dareboost. Cet indicateur devrait en réalité s’appeler “Time To Consistently Interactive”, puisque dans les faits, il n’indique pas “le moment où la page devient interactive”, mais celui où la page devient interactive de façon durable et sans latence. En quelques mots (l’article entier vous permettra vraiment d’en comprendre les subtilités) : 

“Le TTI est une mesure de l’interactivité qui ne repose pas sur les interactions réelles des utilisateurs. L’algorithme fait plutôt une approximation en considérant qu’une interaction satisfaisante ne peut se produire que dans des conditions spécifiques et s’intéresse à déterminer la survenue de ces conditions.”

Ainsi, ces limites ont mené à se tourner vers un autre indicateur qui fait son apparition dans la v6 du score Lighthouse : le Total Blocking Time, qui est un bon complément du TTI.

 

Total-Blocking-Time

Le Total Blocking Time est ici de 5s (4s + 1s)

 

Le Total Blocking Time remplace le First CPU Idle, qui était également trop pénalisant

Le First CPU Idle a lui aussi cédé sa place pour introduire le Total Blocking Time (TBT). Le TBT est une addition des temps de blocage de l'interface avant qu’elle ne devienne interactive de façon durable.

En effet, mesurer les durées de non-interactivité semble bien plus révélateur de l'expérience utilisateur, car cela rend mieux compte de la probabilité pour qu’il y ait un délai avant de pouvoir interagir (ce que Google a confirmé de manière statistique).

Le TBT évalue ainsi la somme de tous les moments où le Main Thread est bloqué par des Long Tasks (tâches dont l’exécution est supérieure à 50 ms), comme expliqué en détail par Google

 

total-blocking-time-calcul

Le TBT est calculé en additionnant toutes les durées en rouge

 

Pour synthétiser, les métriques webperf qui entrent dans le calcul du score se découpent dorénavant en 3 catégories : Affichage, Interactivité et Prédictibilité.

 

Ce nouveau mode de calcul nous semble permettre d’avancer dans le bon sens. En effet, il adresse mieux la notion d’interactivité avec des indicateurs de plus en plus proches de la perception des internautes.

Juin 2021 : Lighthouse annonce une v8

Dans cette v8, Lighthouse modifie une nouvelle fois le poids de chaque métrique dans le calcul du score :

Dans Lighthouse 8, les Core Web Vitals représentent 70 % du calcul du score de performance.
Poids des métriques webperf dans le calcul du score Lighthouse v8

Répartition du poids des métriques webperf dans le calcul de la v8 du score Lighthouse

Outre le poids supplémentaire accordé au Cumulative Layout Shift (x3), l'un des changements importants de cette v8 est la modification apportée à cette métrique. En effet, le CLS, qui fait partie des Core Web Vitals, est maintenant calculé sur une fenêtre de session maximale avec un écart de 1 seconde, plafonné à 5 secondes. L'objectif est de mieux refléter l'expérience utilisateur pour les pages de longue durée (Google explique les détails à propos de ce changement dans cet article).
Quel est l'impact ? Malgré cette évolution, 70 % des origines ne devraient pas observer de changement de CLS au 75e centile, et les 30 % restants peuvent observer une amélioration.
Il faut aussi noter que cet ajustement peut avoir plus d'effet sur les données Field que sur les données Lab.
En effet, Lighthouse v8 introduit une autre modification à la définition du CLS, prenant en compte le décalage de mise en page dans les iframes, et s'alignant ainsi sur la façon dont CrUX calcule le CLS.
Cela implique que les iframes (y compris celles que vous ne contrôlez peut-être pas) peuvent générer des décalages qui affectent finalement votre score CLS. Bien sûr, cet impact est pondéré par la partie visible de l'iframe dans la fenêtre principale.

Si vous vous demandez comment optimiser le CLS et le TBT, les 2 métriques dont le poids a augmenté dans la version 8 de Lighthouse, voici quelques conseils essentiels.

Comment améliorer le CLS, dont le poids augmente dans le calcul du score Lighthouse v8 ?

  • Précisez les dimensions des images, des publicités, et des iframes sur vos pages
  • Optimisez vos fonts et leur affichage pour éviter un FOIT / FOUT
  • Optimisez vos animations et vos contenus intégrés dynamiquement
  • Evitez les actions qui nécessitent une réponse du réseau avant de mettre à jour DOM

Vous trouverez des précisions sur les techniques d'optimisation du Cumulative Layout Shift dans cet article détaillé.

Comment améliorer le TBT, dont le poids augmente dans le calcul du score Lighthouse v8 ?

  • Divisez vos bundles JavaScript pour alléger leur poids
  • Limitez les Long Tasks que vous pouvez éventuellement confier à des Web Workers
  • Différez le code JavaScript qui n'est pas indispensable dès le début du chargement de la page
  • Optimisez les requêtes DOM et réduisez le poids du DOM

Bref, optimisez votre page pour qu'elle soit prête à répondre aux interactions ! Vous trouverez tous les détails pour améliorer le First Input Delay (dont le TBT est l'équivalent pour les données Lab) dans cet article.

 

Enfin, la baisse du poids du Time To Interactive laisse penser que cette métrique pourrait disparaître totalement du calcul du score Lighthouse à terme.

Maintenant que vous savez comment Google évalue vos performances,
vous souhaitez savoir comment améliorer durablement votre vitesse de chargement ?
Découvrez la méthode appliquée par les sites e-commerce les plus performants :

Tout savoir sur le Budget Performance


Hello SMX Paris !