Nouveautés de Lighthouse 6.0

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

Connor Clark

Nous lançons aujourd'hui Lighthouse 6.0 !

Lighthouse est un outil d'audit automatisé de site Web qui aide les développeurs à fournir des opportunités et des diagnostics pour améliorer l'expérience utilisateur sur leurs sites. Il est disponible dans les outils pour les développeurs Chrome, npm (en tant que module de nœud et CLI) ou en tant qu'extension de navigateur (dans Chrome et Firefox). Il est utilisé par de nombreux services Google, y compris web.dev/measure et PageSpeed Insights.

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

Pour tester la CLI Node Lighthouse, exécutez les commandes suivantes : bash npm install -g lighthouse lighthouse https://www.example.com --view

Cette version de Lighthouse est fournie avec un grand nombre de modifications répertoriées dans le journal des modifications 6.0. Nous allons aborder les points essentiels dans cet article.

• Nouvelles métriques
• Informations sur le score de performances
• Nouveaux audits
• CI Lighthouse
• Panneau des outils pour les développeurs Chrome renommé
• Émulation mobile
• Extension de navigateur
• Budgets
• Liens vers le site source
• À l'horizon
• Merci !

Nouvelles métriques

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

Largest Contentful Paint (LCP)

La métrique LCP (Largest Contentful Paint) est une mesure de l'expérience de chargement perçue. Il marque le moment où le contenu principal, ou "le plus volumineux", est chargé et est visible par l'utilisateur lors du chargement de la page. Le LCP est un complément important du FCP (First Contentful Paint) qui ne capture que le tout début de l'expérience de chargement. Le LCP indique aux développeurs la rapidité avec laquelle un utilisateur peut réellement 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 présentation détaillée du LCP de 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 excessifs.Un score CLS inférieur à 0,10 est considéré comme "Bon".

Dans un environnement d'atelier, le CLS est mesuré jusqu'à la fin du chargement de la page. Sur le terrain, vous pouvez mesurer le CLS jusqu'à la première interaction utilisateur ou inclure toutes les entrées utilisateur.

Pour en savoir plus, regardez cette présentation détaillée du CLS d'Annie Sullivan.

Temps de blocage total (TBT)

Le temps de blocage total (TBT) quantifie la réactivité à 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. La fonctionnalité "TBT" mesure le temps total entre la métrique First Contentful Paint (FCP) et le délai avant interactivité (TTI). Il s'agit d'une métrique associée à l'TTI, qui apporte plus de nuances à la quantification de l'activité du thread principal, qui bloque la capacité d'un utilisateur à interagir avec votre page.

En outre, la fonctionnalité "TBT" est en corrélation avec la métrique de champ First Input Delay (FID), qui est une métrique Core Web Vitals.

Informations sur le score de performance

Le score de performances dans Lighthouse est calculé à partir d'une combinaison pondérée de plusieurs métriques pour résumer la vitesse d'une page. Voici la formule du score de performance de 6.0.

Phase	Nom de la métrique	Pondération de la métrique
En avance (15%)	First Contentful Paint (FCP)	15 %
Moitié (40%)	Indice de vitesse (IS)	15 %
	Largest Contentful Paint (LCP)	25 %
Tard (15%)	Délai avant interactivité (TTI)	15 %
Thread principal (25%)	Temps de blocage total (TBT)	25 %
Prévisibilité (5%)	Cumulative Layout Shift (CLS)	5 %

Trois nouvelles métriques ont été ajoutées, mais 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 évidence l'interactivité du thread principal et la prévisibilité de la mise en page.

À titre de comparaison, voici l'évaluation de la version 5:

Phase	Nom de la métrique	Poids
En avance (23%)	First Contentful Paint (FCP)	23 %
Moyenne (34%)	Indice de vitesse (IS)	-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 changements de notation entre les versions 5 et 6 de Lighthouse:

• La pondération du TTI est passée de 33% à 15%. Cette décision était une réponse directe aux commentaires des utilisateurs concernant la variabilité de l'TTI, ainsi qu'à des incohérences dans l'optimisation des métriques, ce qui a entraîné une amélioration de l'expérience utilisateur. L'TTI reste un signal utile lorsqu'une page est entièrement interactive, mais avec la requête de test en complément, la variabilité est réduite. Avec cette modification du score, nous espérons que les développeurs seront plus efficacement encouragés à optimiser l'interactivité des utilisateurs.
• La pondération du FCP est passée de 23% à 15%. Ne mesurer que lorsque le premier pixel est peint (FCP) ne nous a pas donné une image complète. En l'associant à la mesure à laquelle les utilisateurs peuvent voir ce qui les intéresse le plus (LCP), vous pouvez mieux refléter l'expérience de chargement.
• Le FID potentiel maximal est obsolète. Elle n'est plus affichée dans le rapport, mais reste disponible au format JSON. Il est désormais recommandé d'examiner la valeur de conversion après affichage pour quantifier votre interactivité au lieu de la valeur mpFID.
• Abandon de First Meaningful Paint. Cette métrique était trop variant et n'avait pas de solution viable pour standardiser l'environnement, car l'implémentation est spécifique aux composants internes du rendu Chrome. Bien que certaines équipes estiment que le délai FMP sur leur site est intéressant, la métrique ne bénéficiera pas d'améliorations supplémentaires.
• Le premier CPU inactif a été abandonné, car il n'est pas assez différent du TTI. "TBT" et "TTI" sont désormais les métriques de référence en matière d'interactivité.
• La pondération du CLS est relativement faible, mais nous prévoyons de l'augmenter dans une prochaine version majeure.

Variations des scores

Comment ces modifications affectent-elles les scores des sites réels ? Nous avons publié une analyse des variations 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 des scores nettement plus élevés, environ 30% ne présentent pratiquement aucun changement et environ 50% enregistrent une diminution d'au moins cinq points.

Les variations du score peuvent être décomposées en trois éléments principaux:

• variations de poids du score
• Correction de bugs dans l'implémentation de métriques sous-jacentes
• modifications individuelles de la courbe de score

Les variations de la pondération du score et l'introduction de trois nouvelles métriques ont entraîné la plupart des changements du score global. Les nouvelles métriques que les développeurs n'ont pas encore optimisées ont une incidence significative dans le score de performances de la version 6. Alors que le score moyen des performances du corpus de tests de la version 5 était d'environ 50, les scores moyens des nouvelles métriques "Total Blocking Time" et "Largest Contentful Paint" étaient d'environ 30. Ensemble, ces deux métriques représentent 50% de la pondération du score de performances de la version 6 de Lighthouse. Naturellement, un grand pourcentage de sites a donc constaté une baisse.

Les corrections de bugs dans le calcul des métriques sous-jacentes peuvent entraîner des scores différents. Cela concerne relativement peu de sites, mais peut avoir un impact important dans certaines situations. Au total, environ 8% des sites ont enregistré une amélioration du score suite à des modifications apportées à l'implémentation des métriques, et environ 4% d'entre eux ont constaté une diminution du score en raison de modifications apportées à l'implémentation des métriques. Environ 88% des sites n'ont pas été affectés par ces corrections.

Bien que très légèrement, les modifications de la courbe des scores individuels ont également eu un impact très faible sur les variations du score global. Nous nous assurons régulièrement que la courbe de score est alignée sur les métriques observées dans l'ensemble de données HTTPArchive. En excluant les sites affectés par des modifications majeures de l'implémentation, de légers ajustements apportés à la courbe de score pour des métriques individuelles ont permis d'améliorer le score d'environ 3% des sites et de diminuer celui d'environ 4% des sites. Environ 93% des sites ne sont pas concernés par ce changement.

Calculatrice de scores

Nous avons publié un calculateur d'évaluation pour vous aider à analyser l'évaluation des performances. Le simulateur 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 fourni avec un lien vers le simulateur, dans lequel vos résultats sont renseignés.

Un grand merci à Ana Tudor pour sa mise à niveau !

Nouveaux audits

Code JavaScript inutilisé

Nous utilisons la couverture du code DevTools dans un nouvel audit: JavaScript non utilisé.

Cet audit n'est pas totalement: il a été ajouté mi-2017, mais en raison de l'impact sur les 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 être à même de les activer par défaut.

Audits d'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-masque-corps
• aria-cachée-focus
• aria-input-field-name
• aria-toggle-field-name
• form-field-multiple-labels
• heading-order
• id-dupliqué-actif
• id-aria-dupliquée

Icône Masqueable

Les icônes masquées sont un nouveau format d'icône qui permet d'améliorer l'apparence des icônes de votre PWA sur tous les types d'appareils. Pour optimiser l'apparence de votre PWA, nous avons lancé un nouvel audit qui vérifie si le fichier manifest.json est compatible avec ce nouveau format.

Déclaration du jeu de caractères

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é tard dans le document, les navigateurs emploient un certain nombre d'heuristiques pour déterminer l'encodage à utiliser. Si la réponse du navigateur est incorrecte et qu'un élément Meta charset tardif est détecté, l'analyseur élimine généralement tout le travail effectué jusqu'à présent et recommence à zéro, ce qui nuit à l'expérience de l'utilisateur. Ce nouvel audit vérifie que la page dispose d'un encodage de caractères valide et qu'elle est définie dès le début et à l'avance.

Lighthouse CI

Lors de CDS en novembre, nous avons annoncé l'intégration continue Lighthouse, la CLI et le serveur Open Source qui suivent les résultats Lighthouse pour chaque commit de votre pipeline d'intégration continue. Nous avons beaucoup parcouru depuis la version alpha. Lighthouse CI est désormais compatible avec de nombreux fournisseurs d'intégration continue, y compris Travis, Circle, GitLab et GitHub Actions. Grâce aux images Docker prêtes à être déployées, la configuration est un jeu d'enfant. La refonte complète du tableau de bord révèle à présent les tendances pour chaque catégorie et métrique de Lighthouse pour une analyse détaillée.

Commencez dès maintenant à utiliser Lighthouse CI sur votre projet en suivant notre guide de démarrage.

Changement de nom du panneau des outils pour les développeurs Chrome

Le panneau Audits a été renommé Lighthouse. Assez dit !

En fonction de la taille de la fenêtre des outils de développement, le panneau se trouve probablement derrière le bouton ». Vous pouvez faire glisser l’onglet pour changer l’ordre.

Pour afficher rapidement le panneau contenant le menu de commandes:

1. Appuyez sur Ctrl+Maj+J (ou Cmd+Option+J sur Mac) pour ouvrir les outils de développement.
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 adopte une approche axée sur la priorité à la mobilité. Les problèmes de performances sont plus apparents dans des conditions mobiles classiques, mais les développeurs n'effectuent souvent pas de tests dans ces conditions. C'est pourquoi la configuration par défaut de Lighthouse applique l'émulation mobile. L'émulation comprend les éléments suivants:

• Simulation de conditions de réseau et de processeur lents (via un moteur de simulation appelé Lantern)
• Émulation de l'écran de l'appareil (identique à celle des 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 de performances utilisent le Moto G4 à des fins de test. Lighthouse suit maintenant cette démarche et a remplacé son appareil de référence par le Moto G4. En pratique, ce changement n'est pas très perceptible, mais voici tous les changements 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 sera désormais Moto G (4).

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

Extension de navigateur

L'extension Chrome pour Lighthouse s'est révélée pratique pour exécuter Lighthouse en local. Malheureusement, la prise en charge était compliquée. Comme le panneau Lighthouse des outils pour les développeurs Chrome offre une meilleure expérience (le rapport s'intègre à d'autres panneaux), nous pourrions 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 cette fonctionnalité ne remplacera pas suffisamment certains de nos utilisateurs. Voici les principales différences:

• PageSpeed Insights ne peut pas auditer les sites Web non publics, car il est exécuté via un serveur distant et non sur votre instance Chrome locale. Si vous devez auditer un site Web non public, utilisez le panneau Lighthouse des outils de développement ou la CLI du nœud.
• 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. L'extension de navigateur sera mise à jour environ une à deux semaines après la sortie.
• 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 des outils de développement ou la CLI Node.

La bonne nouvelle, c'est que la simplification de l'histoire du produit nous a permis de nous concentrer sur d'autres problèmes techniques. Par conséquent, nous avons lancé l'extension Lighthouse pour Firefox.

Budgets

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

Lighthouse 6.0 est compatible avec les métriques de budgétisation, ce qui vous permet de définir des seuils pour des métriques spécifiques telles que le FCP. Pour l'instant, les budgets ne sont disponibles que dans la CLI Node et la CI Lighthouse.

Liens vers le site source

Certains des problèmes détectés par Lighthouse concernant une page peuvent être issus d'une ligne spécifique du code source, et le rapport indiquera précisément le fichier et la ligne concernés. Pour faciliter l'exploration dans les outils de développement, cliquez sur les emplacements spécifiés dans le rapport pour ouvrir les fichiers correspondants dans le panneau Sources.

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

À l'horizon

Lighthouse a commencé à tester la collecte de cartes sources pour alimenter de nouvelles fonctionnalités, par exemple:

• Détecter les modules en double dans les bundles JavaScript.
• Détecter un nombre excessif de polyfills ou de transformations dans le code envoyé aux navigateurs récents
• Augmentation de l'audit des scripts JavaScript inutilisés pour offrir une précision au niveau du module
• Visualisations de carte proportionnelle mettant en évidence les modules nécessitant une action
• Affichage du code source d'origine pour les éléments du rapport associés à un "emplacement source".

Audit des ressources JavaScript inutilisées qui utilise des mappages de sources 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 l'instant, vous pouvez afficher les audits expérimentaux de Lighthouse à l'aide de l'indicateur CLI suivant:

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

Merci !

Nous vous remercions d'utiliser Lighthouse et de nous faire part de vos commentaires. Vos commentaires nous aident à améliorer Lighthouse et nous espérons que la version 6.0 de Lighthouse vous permettra d'améliorer plus facilement les performances de vos sites Web.

Que pouvez-vous faire ?

• Ouvrez Chrome Canary et essayez le panneau Lighthouse.
• Utilisez la CLI du nœud: 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 des passionnés du Web et nous aimons collaborer avec la communauté des développeurs pour créer des outils permettant de l'améliorer. Lighthouse est un projet Open Source. Nous remercions tous les contributeurs qui ont contribué à toutes ces opérations, de la correction de fautes de frappe aux refactorisations de documentation en passant par les tout nouveaux audits. Vous souhaitez apporter votre contribution ? Accédez au dépôt GitHub Lighthouse.