14 actions pour améliorer le score de performance de Lighthouse

L’avantage de l’extension Lightouse est de bénéficier de la toute dernière version et aussi la possibilité d’exporter le rapport dans plusieurs formats (HTML, JSON, PDF..etc)

Fig. 3. Possibilités d’export de rapport Lighthouse.

Il est possible d’importer un ancien rapport au niveau de la console Devtools ou bien via ce viewer en ligne : https://googlechrome.github.io/lighthouse/viewer/.

1. En ligne de commande ou avec le module Node.js pour une utilisation avancée (pour automatiser, intégration continue, développement).
2. Avec des services tiers proposant des analyses avec Lighthouse comme :
   1. https://developers.google.com/web/tools/lighthouse/run
   2. https://www.webpagetest.org/
   3. https://calibreapp.com/
   4. https://www.dareboost.com
   5. https://treo.sh/

Les métriques de performance Lighthouse (V3) :

Rappelons que les métriques de performances de Lighthouse sont des métriques centrées sur la perception de la performance par l’utilisateur. Toutefois, elles restent considérées comme des approximations. La figure 4 montre un aperçu d’un rapport de performance Lighthouse. Nous allons essayer de détailler chacune des métriques fournies :

Fig. 4. Rapport d’un audit de performance avec Lighthouse.

1. FMP : First meaningful Paint ou le temps nécessaire pour commencer le rendu utile de la page. C’est-à-dire le premier contenu intéressant de la page en excluant les zones appartenantes au template (navigation, header, sidebar). Elle dépend du type de la page par exemple sur un article de blog, le contenu principal est le titre de l’article et le chapeau (avec texte affiché = police chargée) ou bien l’image. Sur une PDP (product detail page) e-commerce, c’est logiquement la photo du produit, son nom et le prix.  Le FMP est la métrique principale qui donne une idée sur la performance perçue par l’utilisateur. Le FMP est pondéré à 1 dans le calcul du score.
2. FCP (First Contentful Paint) désigne le temps écoulé pour afficher la première partie de contenu dans la page à l’utilisateur. Cela peut être basé sur l’affichage d’une image, d’un texte mais souvent c’est l’apparition du menu de la navigation qui est l’événement marquant. Cette métrique donne une approximation sur la rapidité du début de rendu d’une page. Le FCP est une approximation du FMP c'est pourquoi les deux valeurs sont souvent proches dans les audits. Toutefois, le FCP peut parfois être basé sur l'affichage d'un élément secondaire (non meaningful) de la page comme la navigation ou des éléments du design (template).
3. Speed Index : Donne une idée sur la temps nécessaire pour que la page s’affiche à l’utilisateur.
4. First CPU Idle : Le temps à partir duquel le processus principal chargeant la page est devenu relativement allégé. A partir de ce temps là, on considère la page capable de gérer la saisie utilisateur.
5. Estimated Input Latency : Une estimation du délai perçu quand un utilisateur effectue une saisie dans un champs pendant les premières 5 secondes de chargement. Au-delà des 50ms, l’utilisateur pourrait ressentir un effet de lag;
6. Time to Interactive : Marque le moment à partir duquel la page est considérée comme complètement interactive (saisie, scroll, clic).

Le score de performance

Le score global de performance est la somme des scores de chacun des tests exécutés avec des pondérations différentes selon l’importance du critère. Cet aspect est important dans la priorisation des actions à mettre en place sur un site web.

Le score de performance est un nombre entre 0 et 100 basé sur une distribution de loi log-normale sur les données de performance des sites issues de HTTPArchive. Pas d’inquiétude, on va s’arrêter là. Ce n’est pas un article sur les probabilités et les statistiques mais c’est important de le savoir 🙂

Un score de 0 signifie que vous avez éventuellement le site le plus médiocre au monde 🙂 ou bien la présence d’une erreur. Si vous avez un score de performance de 100, bravo vous êtes le champion du monde ! Votre site (page) est plus rapide que 98% des pages dans le web (98eme centile). Si vous avez un score de 50, votre site est plus rapide que 75% des autres (75 centile). Etc.

Les pondération des différents tests peuvent changer d’une version à une autre. Par exemple la figure 5 montre ce qui a changé entre la V2 et la V3 :

Fig. 5. Les changement de pondération entre la V2 et la V3.

 Pour mieux comprendre le scoring de Lighthouse :

1. Le guide de scoring de la V3 est disponible ici : https://developers.google.com/web/tools/lighthouse/v3/scoring
2. Voir également ce document de simulation du score : https://docs.google.com/spreadsheets/d/1Cxzhy5ecqJCucdf1M0iOzM8mIxNc7mmx107o5nj38Eo/edit#gid=0 : il permet d’estimer le gain d’une action. On peut par exemple répondre à des questions de type : Si je réduis mon FMP (First Meaningful Paint) de 800ms combien de points je gagnerais en score ? Faites une copie du document pour jouer avec.
   Voici un exemple de simulation avec les métriques suivantes (Figure 6) :
   1. FCP : 4.5s
   2. FMP : 9.5s
   3. First CPU idle : 13s
   4. Interactive : 13s
   5. Speed index : 11s

Fig. 6. Simulation de score de performance Lighthouse.

Le score calculé donne 15 / 100. On peut maintenant simuler l’impact sur le score si jamais on gagne 4 secondes sur speed index :

Fig. 7. Simulation de score de performance Lighthouse.

La variabilité du score de performance Lighthouse:

Il est important de noter que le score de Lighthouse est une estimation corrélée et peut varier. Cette variabilité peut être liée à :

1. La connexion Internet et la latence, la localisation ;
2. L’utilisation du CPU ;
3. Les extensions Chrome installées ;
4. La parallélisation de plusieurs instances Lighthouse ;
5. La présence d'un antivirus en arrière-plan ;
6. Le profil Chrome et les données d’utilisation (cookies, localstorage..etc) ;
7. La variabilité du serveur d’hébergement (en dehors de Lighthouse).

Vous l’avez compris, l’idéal est d’avoir un environnement dédié à la mesure de performance pour réduire ces écarts de score. L’équipe qui travaille sur Lighthouse essaie de réduire cette variabilité. Ils ont développé un nouveau moteur intitulé “Lantern” qui applique un throttling au niveau local pour réduire les différences de score entre plusieurs audits. Pour plus de détails et un comparatif de variabilité des différentes méthodes (extension, Webpagetest, Devtools..), vous pouvez lire ce document : https://docs.google.com/document/d/1ktXDwJkF_7w0MPLSKFZqmKdMs5TLZqc7em45XkOObAg/edit

Comment améliorer son score de performance Lighthouse:

Pour améliorer son score de performance Lighthouse, il faut faire baisser les métriques détaillées précédemment. Le rapport contient également deux rubriques (opportunities et diagnostics) qui donnent des préconisations pour améliorer la performance et donc agir directement ou indirectement sur les métriques. Les figures 9 et 10 montrent respectivement ces deux rubriques d’une analyse du site bbc.com qui a un score très bas (15 / 100) et les métriques illustrées par la figure 8.

Fig. 8. Rapport de performance Lighthouse du site bbc.com.

Fig. 9. Rubrique “Diagnostics” pour le site bbc.com.

Fig. 10. Rubrique “Opportunities” pour le site bbc.com.

Checklist d’amélioration de performance :

A vrai dire, pour quelqu’un de novice, les préconisations données par Lighthouse ne sont pas évidentes à comprendre car établies par des développeurs. Nous vous avons donc préparé une checklist (plus facile à comprendre) des préconisations à forte valeur ajoutée permettant d'améliorer son score Lighthouse :

1. Réduire le nombre de ressources critiques ;
2. Réduire la taille des ressources (nettoyer du code mort non utilisé, splitter) ;
3. Optimiser le temps d’exécution JavaScript ;
4. Mieux ordonner le chargement des ressources grâce aux ressources hints (preload, defer, async) ;
5. Activer la compression des ressources et la minification du code ;
6. Optimiser les images (compression JPEG à 85%) ;
7. Différer le chargement des images (et médias) au-dessous de la ligne de flottaison ;
8. Réduire le nombre des calculs CSS à faire ;
9. Déléguer des traitements coûteux aux web workers ;
10. Éviter les redirections inutiles ;
11. Avoir une structure DOM simple qui ne dépasse pas 1500 noeuds ;
12. Mettre en place un système de cache pour les ressources statiques ;
13. Optimiser les requêtes sur les bases de données, refactoriser le code source ;
14. Rajouter du CPU et de la RAM à votre serveur.

A ce point de l'article, vous vous posez peut-être la question suivante : Mais quelles sont les ressources critiques ?
Les ressources critiques d’une page peuvent être :

1. Le CSS nécessaire pour afficher ce qui est above the fold (au-dessus de la ligne de flottaison, visible sans scroller) ;
2. L’image principale ;
3. Les fonts (police) ;
4. Les données à afficher above the fold.

Pour plus de détails sur l’approche d’optimisation ainsi que les bonnes pratiques de performance n'hésitez pas à consulter notre article paru dans la lettre Réacteur d’avril 2018 : https://www.reacteur.com/abonnes/archives/2018-04/performances-04-2018.php.

Le mot de la fin :

Dans cet article, nous avons fait une découverte de l’outil Lighthouse de Google et de son fameux audit de performance. Le mot d’ordre est avant tout d’optimiser les 6 métriques importantes qui sont sous le radar de cet outil pour gagner en score et passer au vert. La mesure de performance ne doit pas être un événement ponctuel, il faut la mesurer en continu dans le temps. La performance est avant tout une preuve d’empathie envers les utilisateurs de nos applications. Quelques millisecondes de plus, et l’expérience se dégrade avec des impacts négatifs sur la fidélité, la conversion, le rebond et forcément sur le SEO. Ne l'oubliez jamais !