Nouveautés de Lighthouse 6.0

Nouvelles métriques, mise à jour du score de performances, nouveaux audits et plus encore.

Connor Clark

Nous publions aujourd'hui Lighthouse 6.0.

Lighthouse est un outil d'audit automatisé de sites Web qui aide les développeurs à identifier des opportunités et des diagnostics pour améliorer l'expérience utilisateur de leurs sites. Il est disponible dans les outils pour les développeurs Chrome, npm (en tant que module Node et CLI) ou en tant qu'extension de navigateur (dans Chrome et Firefox). Il alimente de nombreux services Google, y compris PageSpeed Insights.

Lighthouse 6.0 est disponible immédiatement sur npm et dans Chrome Canary. Les autres services Google qui utilisent Lighthouse recevront la mise à jour d'ici la fin du mois. Il sera disponible dans Chrome 84 (mi-juillet) pour la version stable de Chrome.

Pour essayer la CLI Node Lighthouse, utilisez les commandes suivantes : bash npm install -g lighthouse lighthouse https://www.example.com --view

Cette version de Lighthouse comprend un grand nombre de modifications qui sont listées dans le journal des modifications de la version 6.0. Nous allons passer en revue les points forts dans cet article.

• Nouvelles métriques
• Mise à jour du score de performances
• Nouveaux audits
• Intégration continue Lighthouse
• Nom du panneau des outils pour les développeurs Chrome modifié
• Émulation mobile
• Extension de navigateur
• Budgets
• Liens vers des emplacements sources
• À l'horizon
• Merci !

Nouvelles métriques

Lighthouse 6.0 introduit trois nouvelles métriques dans le rapport. Deux de ces nouvelles métriques (Largest Contentful Paint (LCP) et Cumulative Layout Shift (CLS)) sont des implémentations expérimentales des Core Web Vitals.

Largest Contentful Paint (LCP)

La métrique LCP (Largest Contentful Paint) mesure l'expérience de chargement perçue. Il marque le point pendant le chargement de la page où le contenu principal (ou le plus volumineux) a été chargé et est visible par l'utilisateur. Le LCP est un complément important du First Contentful Paint (FCP), qui ne capture que le tout début de l'expérience de chargement. Le LCP fournit aux développeurs un signal sur la rapidité avec laquelle un utilisateur peut voir le contenu d'une page. Un score LCP inférieur à 2,5 secondes est considéré comme "bon".

Pour en savoir plus, regardez cette analyse approfondie du LCP par Paul Irish.

Cumulative Layout Shift (CLS)

Le CLS (Cumulative Layout Shift) mesure la stabilité visuelle. Elle quantifie le décalage visuel du contenu d'une page. Un score CLS faible indique aux développeurs que leurs utilisateurs ne subissent pas de décalages de contenu indus.Un score CLS inférieur à 0,10 est considéré comme "bon".

Dans un environnement de test, le CLS est mesuré jusqu'à la fin du chargement de la page. En revanche, dans le champ, vous pouvez mesurer le CLS jusqu'à la première interaction de l'utilisateur ou en incluant toutes les entrées utilisateur.

Pour en savoir plus, regardez cette présentation approfondie sur le CLS par Annie Sullivan.

Total Blocking Time (TBT)

Le temps de blocage total (TBT) quantifie la réactivité de la charge en mesurant la durée totale pendant laquelle le thread principal a été bloqué suffisamment longtemps pour empêcher la réactivité aux entrées. Le TBT mesure la durée totale entre First Contentful Paint (FCP) et Time to Interactive (TTI). Il s'agit d'une métrique complémentaire du TTI qui apporte plus de nuances à la quantification de l'activité du thread principal qui empêche un utilisateur d'interagir avec votre page.

De plus, la métrique TBT est bien corrélée à la métrique sur le terrain First Input Delay (FID), qui est une métrique Core Web Vitals.

Mise à jour du score de performances

Le score de performances dans Lighthouse est calculé à partir d'un mélange pondéré de plusieurs métriques pour résumer la vitesse d'une page. Vous trouverez ci-dessous la formule du score de performances 6.0.

Phase	Nom de la métrique	Pondération de la métrique
En avance (15%)	First Contentful Paint (FCP)	15 %
Moyen (40%)	Indice de vitesse (SI)	15 %
	Largest Contentful Paint (LCP)	25 %
En retard (15%)	Délai avant interactivité (TTI)	15 %
Thread principal (25%)	Total Blocking Time (TBT)	25 %
Prévisibilité (5%)	Cumulative Layout Shift (CLS)	5 %

Trois nouvelles métriques ont été ajoutées, tandis que trois anciennes ont été supprimées : "First Meaningful Paint", "First CPU Idle" et "Max Potential FID". Les pondérations des métriques restantes ont été modifiées pour mettre en avant l'interactivité du thread principal et la prévisibilité de la mise en page.

À titre de comparaison, voici le score de la version 5:

Phase	Nom de la métrique	Poids
En avance (23%)	First Contentful Paint (FCP)	23 %
Moyen (34%)	Indice de vitesse (SI)	27 %
	First Meaningful Paint (FMP)	7 %
Terminé (46%)	Délai avant interactivité (TTI)	33 %
	Premier processeur inactif (FCI)	13 %
Thread principal	FID potentiel maximal	0 %

Voici quelques points forts des modifications apportées au système de notation entre les versions 5 et 6 de Lighthouse:

• Le poids de l'indice TTI est passé de 33% à 15 %. Cette modification a été apportée en réponse directe aux commentaires des utilisateurs concernant la variabilité du TTI, ainsi qu'aux incohérences dans les optimisations de métriques qui ont amélioré l'expérience utilisateur. Le TTI reste un signal utile pour savoir quand une page est entièrement interactive. Toutefois, avec le TBT en complément, la variabilité est réduite. Avec ce changement de notation, nous espérons que les développeurs seront plus encouragés à optimiser leur application pour l'interactivité utilisateur.
• Le poids du FCP est passé de 23% à 15%. Mesurer uniquement lorsque le premier pixel est peint (FCP) ne nous a pas donné une image complète. En le combinant à la mesure du moment où les utilisateurs peuvent voir ce qui les intéresse le plus (LCP), vous obtiendrez une meilleure représentation de l'expérience de chargement.
• FID potentiel maximal est obsolète. Il n'est plus affiché dans le rapport, mais il est toujours disponible dans le fichier JSON. Nous vous recommandons désormais d'utiliser le TBT pour quantifier votre interactivité plutôt que l'mpFID.
• First Meaningful Paint a été abandonné. Cette métrique était trop variable et ne présentait aucun chemin viable vers la standardisation, car l'implémentation est spécifique aux éléments internes du rendu Chrome. Bien que certaines équipes trouvent que le délai de FMP est intéressant sur leur site, la métrique ne sera pas améliorée.
• La statistique "Premier processeur inactif" a été abandonnée, car elle n'est pas suffisamment distincte de la TTI. Le TBT et le TTI sont désormais les métriques de référence pour l'interactivité.
• Le poids de la CLS est relativement faible, mais nous prévoyons de l'augmenter dans une prochaine version majeure.

Évolution des scores

Quel est l'impact de ces modifications sur les scores des sites réels ? Nous avons publié une analyse des modifications de score à l'aide de deux ensembles de données: un ensemble général de sites et un ensemble de sites statiques créés avec Eleventy. En résumé, environ 20% des sites enregistrent une augmentation notable de leur score, environ 30% ne voient presque aucun changement et environ 50% enregistrent une baisse d'au moins cinq points.

Les modifications de score peuvent se diviser en trois composants principaux:

• pondérer les variations de poids
• correction de bugs dans les implémentations de métriques sous-jacentes
• Modifications de la courbe de score individuelle

Les modifications de pondération du score et l'introduction de trois nouvelles métriques ont entraîné la majorité des modifications du score global. Les nouvelles métriques que les développeurs n'ont pas encore optimisées ont un poids important dans le score de performances de la version 6. Alors que le score de performances moyen du corpus de test dans la version 5 était d'environ 50, les scores moyens des nouvelles métriques "Total Blocking Time" (Temps de blocage total) et "Largest Contentful Paint" (Plus grande peinture avec contenu) étaient d'environ 30. Ensemble, ces deux métriques représentent 50% du poids du score de performances de la version 6 de Lighthouse. Il est donc naturel qu'un grand pourcentage de sites aient vu leur score diminuer.

Les corrections de bugs apportées au calcul des métriques sous-jacentes peuvent entraîner des scores différents. Cela ne concerne que relativement peu de sites, mais peut avoir un impact important dans certaines situations. Dans l'ensemble, environ 8% des sites ont vu leur score augmenter en raison de modifications apportées à l'implémentation des métriques, et environ 4% ont vu leur score diminuer en raison de ces modifications. Environ 88% des sites n'ont pas été concernés par ces corrections.

Les modifications apportées aux courbes de score individuelles ont également eu un impact sur les variations globales des scores, mais très légèrement. Nous nous assurons régulièrement que la courbe de score correspond aux métriques observées dans le données de la collection HTTPArchive. En excluant les sites concernés par des modifications d'implémentation majeures, les ajustements mineurs apportés à la courbe de notation pour les métriques individuelles ont amélioré les scores d'environ 3% des sites et diminué ceux d'environ 4% des sites. Environ 93% des sites n'ont pas été concernés par ce changement.

Calculateur de score

Nous avons publié un calculateur de score pour vous aider à découvrir le calcul des performances. La calculatrice vous permet également de comparer les scores des versions 5 et 6 de Lighthouse. Lorsque vous exécutez un audit avec Lighthouse 6.0, le rapport est accompagné d'un lien vers la calculatrice avec vos résultats renseignés.

Un grand merci à Ana Tudor pour la mise à niveau de l'indicateur.

Nouveaux audits

JavaScript inutilisé

Nous utilisons la couverture de code des outils de développement dans un nouvel audit : le code JavaScript inutilisé.

Cet audit n'est pas entièrement nouveau: il a été ajouté mi-2017, mais en raison des coûts de performances, il a été désactivé par défaut pour que Lighthouse reste aussi rapide que possible. La collecte de ces données de couverture est désormais beaucoup plus efficace. Nous pouvons donc l'activer par défaut.

Audits de l'accessibilité

Lighthouse utilise la merveilleuse bibliothèque axe-core pour alimenter la catégorie d'accessibilité. Dans Lighthouse 6.0, nous avons ajouté les audits suivants:

• aria-hidden-body
• aria-hidden-focus
• aria-input-field-name
• aria-toggle-field-name
• form-field-multiple-labels
• heading-order
• duplicate-id-active
• duplicate-id-aria

Icône masquable

Les icônes masquables sont un nouveau format d'icône qui permet de mettre en valeur les icônes de votre PWA sur tous les types d'appareils. Pour que votre PWA soit aussi attrayante que possible, nous avons lancé un nouvel audit pour vérifier si votre fichier manifest.json est compatible avec ce nouveau format.

Déclaration de charset

L'élément meta charset déclare l'encodage de caractères à utiliser pour interpréter un document HTML. Si cet élément est manquant ou s'il est déclaré tardivement dans le document, les navigateurs utilisent un certain nombre d'heuristiques pour deviner quel encodage doit être utilisé. Si un navigateur effectue une mauvaise supposition et qu'un élément de méta-encodage est détecté trop tard, l'analyseur jette généralement tout le travail effectué jusqu'à présent et recommence, ce qui entraîne une mauvaise expérience pour l'utilisateur. Ce nouvel audit vérifie que la page dispose d'une encodage de caractères valide et qu'elle est définie dès le départ.

Intégration continue Lighthouse

Lors de la Conférence sur le développement de Google de novembre dernier, nous avons annoncé Lighthouse CI, la CLI et le serveur Node Open Source qui suivent les résultats de Lighthouse sur chaque commit de votre pipeline d'intégration continue. Nous avons parcouru un long chemin depuis la version alpha. Lighthouse CI est désormais compatible avec de nombreux fournisseurs de CI, y compris Travis, Circle, GitLab et GitHub Actions. Les images Docker prêtes à l'emploi facilitent la configuration, et une refonte complète du tableau de bord révèle désormais les tendances pour chaque catégorie et métrique de Lighthouse afin d'effectuer une analyse détaillée.

Commencez à utiliser l'intégration continue Lighthouse sur votre projet dès aujourd'hui en suivant notre guide de démarrage.

Renommé le panneau des outils pour les développeurs Chrome

Nous avons renommé le panneau Audits en Lighthouse. Assez parlé !

Selon la taille de la fenêtre des outils pour les développeurs, le panneau se trouve probablement derrière le bouton ». Vous pouvez faire glisser l'onglet pour modifier l'ordre.

Pour afficher rapidement le panneau avec le menu de commande:

1. Appuyez sur Ctrl+Maj+J (ou Cmd+Option+J sur Mac) pour ouvrir DevTools.
2. Appuyez sur Control+Shift+P (ou Command+Shift+P sur Mac) pour ouvrir le menu Command (Commande).
3. Commencez à saisir "Lighthouse".
4. Appuyez sur la touche Enter.

Émulation mobile

Lighthouse suit une approche mobile first. Les problèmes de performances sont plus apparents dans des conditions mobiles typiques, mais les développeurs ne les testent souvent pas dans ces conditions. C'est pourquoi la configuration par défaut de Lighthouse applique l'émulation mobile. L'émulation se compose des éléments suivants:

• Conditions de réseau et de processeur lentes simulées (via un moteur de simulation appelé Lantern).
• Émulation de l'écran de l'appareil (identique à celle disponible dans les outils pour les développeurs Chrome).

Depuis le début, Lighthouse utilise le Nexus 5X comme appareil de référence. Ces dernières années, la plupart des ingénieurs en performances ont utilisé le Moto G4 à des fins de test. Lighthouse suit le même chemin et a remplacé son appareil de référence par le Moto G4. En pratique, ce changement n'est pas très visible, mais voici toutes les modifications détectables par une page Web:

• La taille de l'écran passe de 412 x 660 px à 360 x 640 px.
• La chaîne user-agent est légèrement modifiée. La partie de l'appareil qui était auparavant Nexus 5 Build/MRA58N est désormais Moto G (4).

Depuis Chrome 81, le Moto G4 est également disponible dans la liste d'émulation d'appareils des outils pour les développeurs Chrome.

Extension de navigateur

L'extension Chrome pour Lighthouse était un moyen pratique d'exécuter Lighthouse localement. Malheureusement, il a été difficile de vous aider. Étant donné que le panneau Lighthouse des outils de développement Chrome offre une meilleure expérience (le rapport s'intègre à d'autres panneaux), nous avons estimé que nous pouvions réduire nos coûts d'ingénierie en simplifiant l'extension Chrome.

Au lieu d'exécuter Lighthouse localement, l'extension utilise désormais l'API PageSpeed Insights. Nous sommes conscients que ce ne sera pas un remplacement suffisant pour certains de nos utilisateurs. Voici les principales différences:

• PageSpeed Insights ne peut pas auditer les sites Web non publics, car il s'exécute via un serveur distant et non via votre instance Chrome locale. Si vous devez auditer un site Web non public, utilisez le panneau Lighthouse des outils pour les développeurs ou la CLI Node.
• Il n'est pas garanti que PageSpeed Insights utilise la dernière version de Lighthouse. Si vous souhaitez utiliser la dernière version, utilisez la CLI Node. La mise à jour sera appliquée à l'extension du navigateur environ une à deux semaines après sa publication.
• PageSpeed Insights est une API Google. Son utilisation implique l'acceptation des conditions d'utilisation de l'API Google. Si vous ne souhaitez pas ou ne pouvez pas accepter les conditions d'utilisation, utilisez le panneau Lighthouse de DevTools ou la CLI Node.

La bonne nouvelle est que la simplification de l'histoire du produit nous a permis de nous concentrer sur d'autres problèmes d'ingénierie. Nous avons donc lancé l'extension Lighthouse pour Firefox.

Budgets

Lighthouse 5.0 a introduit les budgets de performances, qui permettent d'ajouter des seuils pour la quantité de chaque type de ressource (comme les scripts, les images ou les fichiers CSS) qu'une page peut diffuser.

Lighthouse 6.0 est désormais compatible avec les métriques de budgétisation. Vous pouvez donc définir des seuils pour des métriques spécifiques telles que le FCP. Pour le moment, les budgets ne sont disponibles que pour la CLI Node et la CI Lighthouse.

Liens vers l'emplacement de la source

Certains des problèmes détectés par Lighthouse sur une page peuvent être retracés jusqu'à une ligne de code source spécifique. Le rapport indique alors le fichier et la ligne exacts concernés. Pour faciliter l'exploration dans DevTools, cliquez sur les emplacements spécifiés dans le rapport pour ouvrir les fichiers concernés dans le panneau Sources.

Les outils de développement révèlent la ligne de code exacte à l'origine du problème.

À l'horizon

Lighthouse a commencé à collecter des cartes sources pour alimenter de nouvelles fonctionnalités, par exemple:

• Détection des modules en double dans les groupes JavaScript.
• Détection d'un nombre excessif de polyfills ou de transformations dans le code envoyé aux navigateurs modernes.
• Amélioration de l'audit JavaScript inutilisé pour fournir une granularité au niveau du module.
• Visualisations de carte proportionnelle mettant en évidence les modules qui nécessitent une action.
• Affichage du code source d'origine des éléments de rapport avec un "emplacement source".

L'audit JavaScript inutilisé utilise des mappages source pour afficher le code inutilisé dans des modules groupés spécifiques.

Ces fonctionnalités seront activées par défaut dans une prochaine version de Lighthouse. Pour le moment, vous pouvez afficher les audits expérimentaux de Lighthouse avec l'indicateur CLI suivant:

lighthouse https://web.dev --view --preset experimental

Merci !

Merci d'avoir utilisé Lighthouse et de nous avoir fait part de vos commentaires. Vos commentaires nous aident à améliorer Lighthouse. Nous espérons que Lighthouse 6.0 vous aidera à améliorer les performances de vos sites Web.

Que pouvez-vous faire ?

• Ouvrez Chrome Canary et essayez le panneau Lighthouse.
• Utilisez la CLI Node: npm install -g lighthouse && lighthouse https://yoursite.com --view.
• Exécutez Lighthouse CI avec votre projet.
• Consultez la documentation sur l'audit Lighthouse.
• Amusez-vous à améliorer le Web !

Nous sommes passionnés par le Web et nous aimons collaborer avec la communauté des développeurs pour créer des outils qui contribuent à l'améliorer. Lighthouse est un projet Open Source, et nous remercions tous les contributeurs qui nous aident, que ce soit pour corriger des fautes de frappe, refactoriser la documentation ou effectuer de nouveaux audits. Vous souhaitez contribuer ? Consultez le dépôt GitHub de Lighthouse.