Lighthouse : Outil d’audit de la performance

Ecrit par Mathieu CHAPON
le 03 / 12 / 2019

Il y a du mouvement dans le petit monde des webperf. Pas de changements majeurs, mais suffisamment pour que les SEO s’en soucient et y regardent de plus près. Lors du Chrome Dev Summit, nous avons eu l’occasion d’en apprendre plus sur les mises à jour à venir de Lighthouse et ses nouveaux indicateurs ainsi que sur la volonté toujours plus forte de Google de rendre le web plus rapide pour les utilisateurs.

Des nouveaux messages sur la vitesse des sites

Cette nouveauté ne vient pas réellement du Chrome Dev Summit, mais son annonce s’est faite en parallèle. Sur le blog de Chromium Google insiste sur le fait qu’ils veulent aider les utilisateurs à mieux appréhender la vitesse d’un site, qu’il soit lent ou rapide. L’idée étant que l’utilisateur soit prévenu le plus tôt possible qu’il s’apprête à charger une page plutôt lente ou plutôt rapide.
Pour cela Google fera plusieurs tests pour savoir quel type d’alerte sera le plus efficace. Pour le moment, voici un exemple qui nous est donné pour mieux comprendre ce qu’ils ont en tête :

Google se servira des données historiques pour déterminer si un site est lent ou rapide. À terme, l’idée serait d’aller plus loin et de ne plus se fier uniquement aux données historiques (les mêmes que dans Google Page Speed Insights) mais d’adapter l’alerte en fonction de l’appareil et de la connexion de l’utilisateur.
Aucune communication pour le moment sur la date de lancement ni sur les performances minimales à respecter pour ne pas être considéré comme un site lent. Google nous dit néanmoins qu’ils estiment ne pas être trop sévères et ne rien demander d’insurmontable aux développeurs.
Il va donc falloir travailler vos webperf et cela tombe bien puisqu’avec le Chrome Dev Summit, de nouveaux indicateurs très intéressants ont été dévoilés.

Lighthouse et indicateurs de performance

Avant toute chose, l’équipe de Google nous rappelle un fondamental de la webperformance, à savoir la distinction entre deux types d’indicateurs : les indicateurs de champs et les indicateurs de laboratoire. Les premiers ont l’énorme avantage de refléter le plus possible la réalité de ce que vivent les internautes et le second permet de faire des tests poussés à un instant T et de découvrir d’éventuels problèmes.
Les données de champs étant sans doute les plus importantes, Google tente de les améliorer constamment pour mieux comprendre comment sont perçus les sites web par leurs internautes. C’est donc ainsi qu’ils ont décidé de mettre en place 3 nouveaux indicateurs qui permettront de mieux mesurer lorsqu’une page est jugée utilisable : Largest Contentful Paint, Total Blocking Time et le Cumulative Layout Shift.
Avant de rentrer dans le détail de chaque indicateur, il faut savoir que deux d’entre eux vont venir remplacer, en termes d’importance, le FMP (first meaningful Paint) et le FCI (first CPU idle) dans les calculs de score de la page.

Largest Contentful Paint

Le LCP mesure le temps que met à s’afficher l’élément le plus large de la page (plus précisément du viewport de l’utilisateur). Cela permet théoriquement de mieux mesurer le temps que va mettre l’utilisateur à voir l’élément le plus important de la page. 
Pour le moment, ce calcul est limité à quelques éléments tels que :

• Les images.
• Les vidéos.
• Un background avec une image.
• Des blocs HTML comme des <p> ou des <article>, etc.

D’autres éléments seront sans doute ajoutés au fur et à mesure, mais pour le moment les équipes de Google souhaitent garder cette mesure la plus simple possible.
Nous ne rentrerons pas ici dans les considérations techniques sur comment définir l’élément le plus large d’une page ou encore à quel moment exactement est enregistré le chargement. Ce qu’il faut surtout retenir c’est que le calcul se fait lorsque l’élément le plus large est entièrement visible pour l’utilisateur.
Voici quelques exemples donnés par Google pour mieux comprendre ce qu’est le LCP :


Sur le premier exemple, nous pouvons déjà nous poser la question de la pertinence de cet indicateur. 
Est-ce bien l’image l’élément le plus important de la page ou le titre avec le texte ? La question se pose et il faut vous la poser également en fonction de vos pages. 
Pour un site e-commerce, sur une fiche produit, il y a en effet fort à parier que ce soit l’image l’élément le plus large et le plus important de la page, et dans ce cas en effet cela a du sens de se concentrer sur l’optimisation de son affichage. En revanche, sur d’autres types de pages, cet indicateur n’aura peut-être pas beaucoup de sens et il ne faudra pas lui apporter autant d’importance.
Ce sera donc à vous d’arbitrer sur sa pertinence et le besoin de l’optimiser.
Mais alors, pourquoi donner autant d’importance à un indicateur qui semble aussi arbitraire ? Le LCP vient « remplacer » un autre indicateur qui est le First Meaningful Paint qui avait trop de biais pour être fiable. Pour commencer, le FMP était trop dépendant du FCP (à savoir les premiers éléments qui s’affichent sur votre page) et le score descendait drastiquement si le FCP et le FMP étaient trop éloignés, ce qui n’avait pas toujours de sens. De plus cet indicateur était trop sensible aux moindres changements de chargement dans la page. Enfin, le plus gênant restait le manque d’information sur ce que signifiait vraiment le « premier contenu significatif de la page ». 
Donc même si le LCP a des défauts, et sera sans doute amélioré avec le temps, il a tout de même l’énorme avantage d’être clair et transparent pour les webmasters.
Source : https://web.dev/lcp/

Cumulative Layout Shift

Voici un indicateur fort intéressant d’un point de vue utilisateur. N’avez-vous jamais eu la mauvaise surprise de vouloir cliquer ou « taper » sur un élément d’une page et que, sans prévenir, cet élément bouge et que vous vous retrouviez à cliquer sur autre chose ?

C’est précisément ce que mesure cet indicateur.
Ces changements sont souvent dus au chargement asynchrone de ressources ou à des fichiers qui mettent trop longtemps à charger leurs animations ce qui peut être pénible et frustrant pour l’internaute.
Le CLS est calculé via l’API Layout Instability, dont le principe est relativement simple. Elle calcule les changements de place fonction de la position de l’élément lors du début du chargement de la page. Si un élément a une hauteur de X et un décalage à gauche de Y au début du chargement et se retrouve ensuite en hauteur W et en décalage gauche de Z alors il est considéré comme instable. 

Comment c’est calculé ?

Le CLS est calculé via 2 éléments :

• L’impact fraction. Cela calcule à quel point un élément est instable dans le viewport entre 2 frames (images). Entre 2 images, cela va prendre en compte l’impact de l’élément instable sur la totalité du viewport actuel. 

Utilisons l’exemple donné par Google pour simplifier les choses.

Sur la première image (gauche) le bloc prend 50% du viewport. Sur la frame suivante (l’image de droite) le bloc est descendu sur le viewport et si on additionne son ancienne position et la nouvelle, cela prend 75% du viewport. L’instabilité de ce bloc a donc impacté 75% de l’écran et son indice d’impact fraction sera alors de 0.75.

• La distance fraction. Cet indice est plus simple à comprendre puisqu’il mesure la distance parcourue par le bloc instable dans le viewport. Dans l’exemple ci-dessus, le bloc a bougé de 25% verticalement. Son indice de distance fraction sera donc de 0.25.

Ce nouvel indicateur n’est pas évident à appréhender, prenons donc un cas concret toujours donné par Google.

Ici le bloc gris ne sera pas considéré comme instable puisqu’il ne bouge pas et ne prend pas plus de place entre 2 frames. En revanche le bloc vert, lui, sera considéré comme instable puisqu’avec l’arrivée du CTA « Click Me ! » il se retrouve plus bas dans la page.
Si vous avez bien suivi, l’impact fraction sera de 50% puisque l’élément instable ne prend pas plus de place que sur la première image. Nous avons donc un score de 0.5.
En revanche la distance fraction sera de 14% puisque le bloc vert à changé de hauteur entre les 2 images. Nous avons donc un score de 0.14.
La layout shift score sera donc de : 0.5 x 0.14 = 0.07.
Idéalement il faudrait qu’une page est un CLS équivalent à 0 mais Google est bien conscient que ce n’est pas toujours possible. Un CLS sera donc considéré comme bon s’il ne dépasse pas les 5.

Total blocking Time

Le TBT permet de calculer le temps entre le FCP et le TTI où le « thread » a été bloqué assez longtemps pour potentiellement empêcher toute interaction avec la page. 
« Bloqué » ici signifie que le thread ne peut pas interrompre la tâche qui est en cours et le « assez longtemps » signifie qu’il est ainsi pendant au moins 50ms.
Le total blocking time est donc la somme de tous ces moments. 
Prenons un thread classique d’un navigateur qui charge une page :

Nous pouvons voir 5 tâches prenant chacune plusieurs millisecondes. 3 d’entres elles sont considérées comme de longues tâches puisqu’elles prennent plus de 50 millisecondes. 

Les éléments en rouge seront donc considérés comme du « temps en trop » et seront calculés dans le TBT. Ce qui fera que sur les 560ms au total, 345ms seront considérées comme du TBT.
Il s’agit d’un bon indicateur en complément du TTI (time to interactive) qui aujourd’hui prend tout de même 33% de la note globale de lighthouse.
Cet indicateur permettra de mieux comprendre quel est le temps perdu et où il est perdu dans nos différentes tâches pour également mieux comprendre pourquoi notre TTI est mauvais. Pour rappel, le TTI est calculé à partir du moment où le thread principal est libre pendant au moins 5 secondes (et peut donc accepter les inputs utilisateurs).

Un lighthouse plus complet en 2020

Pour terminer ce point sur la webperformance, Google nous donne 3 autres « nouveautés » sur lighthouse.
La première étant la mise à jour du calcul des scores dès Janvier 2020 avec l’arrivée des nouveaux indicateurs.

La seconde étant l’arrivée des stack packs et des plugins. Les stacks packs seront des nouveautés natives à Lighthouse qui permettront de détecter automatiquement sur quel CMS vous êtes et vous donneront des recommandations spécifiques à ce CMS. Pour le moment WordPress est déjà disponible et d’autres arrivent tels que React, Magento ou AMP.
Les plugins quant à eux seront développés par la communauté. Leur utilisation est donc plus ou moins sans limite !
Enfin la troisième et dernière nouveauté concerne l’utilisation de Lighthouse sur des environnements de préproduction ou de développement. Lighthouse CI
permettra d’automatiser des tests sur n’importe quel environnement, de les enregistrer, les partager avec son équipe, etc. Très utile donc pour vérifier en amont et tout au long du projet que des efforts sont bien faits du côté des webperformances.
Précisons pour terminer que l’essentiel des éléments de cet article provient du site https://web.dev/ et que nous avons simplement choisi de les simplifier et de ne vous donner que l’essentiel. Libre à vous cependant d’aller explorer tout ceci, de faire vos propres tests et de mettre en place le tracking de ces indicateurs sur vos pages !