Nouveautés de Lighthouse 6.0

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

Connor Clark

Nous lançons aujourd'hui Lighthouse 6.0.

Lighthouse est un outil automatisé d'audit de site Web qui fournit aux développeurs 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 Node et CLI) ou en tant qu'extension de navigateur (dans Chrome et Firefox). De nombreux produits Google tels que web.dev/measure et PageSpeed Insights.

Lighthouse 6.0 est disponible immédiatement sur npm et dans Chrome Canary : D'autres services Google qui utilisent Lighthouse vous recevez la mise à jour avant la fin du mois. Elle sera disponible dans la version stable de Chrome dans Chrome 84 (mi-juillet).

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

Cette version de Lighthouse apporte un grand nombre de modifications répertoriées dans le journal des modifications de la version 6.0. Nous aborderons les points forts de cet article.

• Nouvelles métriques
• Informations sur le score de performance
• Nouveaux audits
• Lighthouse CI
• Changement de nom du panneau "Outils pour les développeurs Chrome"
• Émulation mobile
• Extension de navigateur
• Budgets
• Liens d'adresses sources
• À venir
• Merci !

Nouvelles statistiques

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

Largest Contentful Paint (LCP)

Le LCP (Largest Contentful Paint) mesure le chargement perçu expérience. Il marque le point lors du chargement de la page, c'est-à-dire lorsque le contenu principal (ou "plus volumineux") a été chargé et est visible par l'utilisateur. Le LCP complète efficacement le FCP (First Contentful Paint), qui ne capture le tout début du chargement. Le LCP indique aux développeurs comment rapidement un utilisateur peut voir le contenu d'une page. Un score LCP inférieur à 2,5 secondes est est considérée comme "satisfaisante".

Pour en savoir plus, regardez cette vidéo détaillée sur le LCP de Paul Irish.

Cumulative Layout Shift (CLS)

Le CLS (Cumulative Layout Shift) est une mesure de la stabilité visuelle. Il quantifie l'évolution visuelle du contenu d'une page. Un faible score CLS est le signe aux développeurs que leurs utilisateurs ne subissent pas de modifications excessives du contenu ; un score CLS inférieur à 0,10 est est considérée comme "satisfaisante".

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

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

Durée totale de blocage (TBT, Total Blocking Time)

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

De plus, la métrique "TBT" se rapproche de la métrique de champ First Input Delay (FID), qui est une métrique Core Web Vitals.

Mise à jour du score de performance

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

Phase	Nom de la métrique	Pondération de la métrique
En avance (15%)	First Contentful Paint (FCP)	15 %
Moyenne (40%)	Indice de vitesse (IS)	15 %
	Largest Contentful Paint (LCP)	25 %
En retard (15%)	Délai d'interaction (TTI)	15 %
Thread principal (25%)	Durée totale de blocage	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, Premier CPU inactif et FID potentiel maximal. La pondération des métriques restantes a été remplacée par mettent l'accent sur 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 %
Moyenne (34%)	Indice de vitesse (IS)	27 %
	First Meaningful Paint (FMP)	7 %
Terminés (46%)	Délai avant interactivité (TTI)	33 %
	Premier processeur inactif (FCI)	13 %
Thread principal	FID potentiel maximal	0 %

Voici quelques points importants des changements de scores entre les versions 5 et 6 de Lighthouse:

• Le poids de TTTI est passé de 33% à 15 %. en réponse directe à l’utilisateur des commentaires sur la variabilité de l'indice TTI, ainsi que des incohérences dans les optimisations des métriques entraînant des d'amélioration de l'expérience utilisateur. Le TTI reste un signal utile lorsqu'une page est interactif, mais avec la TA complément : la variabilité est réduite. Avec ce changement de score, nous espérons que les développeurs sont encouragés à optimiser plus efficacement l'interactivité des utilisateurs.
• Le poids du FCP est passé de 23% à 15%. Les mesures ne sont prises que lorsque le premier pixel peint (FCP) ne nous donnait pas une image complète. en les associant à des mesures permettant de déterminer quand les utilisateurs pour voir ce qui les intéresse le plus (LCP) reflète mieux l'expérience de chargement.
• Le FID potentiel maximal a été abandonné. Elle n'apparaît plus dans le rapport, mais est toujours disponible dans le fichier JSON. Nous vous recommandons maintenant d'examiner le TLN pour quantifier votre interactivité. au lieu de mpFID.
• First Meaningful Paint a été abandonné. Cette métrique était trop variable et n'était pas viable à la normalisation, car l'implémentation est spécifique aux composants internes du rendu Chrome. Alors que certaines équipes estiment que le calendrier FMP est intéressant sur leur site, la métrique ne recevra pas d'autres améliorations.
• Le paramètre "First CPU Idle" a été abandonné, car il n'est pas suffisamment différent du TTI. TC et TTI sont les métriques incontournables 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.

Évolution des scores

Comment ces changements affectent-ils les scores des sites réels ? Nous avons publié un Analyse du score change à l'aide de deux ensembles de données: un ensemble général des sites et un ensemble de sites statiques conçu avec Eleventy. En résumé, environ 20% des sites enregistrent une augmentation environ 30% n'ont quasiment aucun changement et environ 50% d'entre eux constatent une baisse d'au moins cinq points.

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

• variations de la pondération du score
• Correction de bugs liés aux implémentations de métriques sous-jacentes
• modifications de la courbe de score individuelle

Les changements de pondération du score et l'introduction de trois nouvelles métriques ont généré la majorité du score global des modifications. Les nouvelles métriques que les développeurs n'ont pas encore optimisées ont un poids important dans la version 6 le score de performance. Alors que le score moyen du corpus de test dans 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 dans le score de performances de Lighthouse version 6. Naturellement, un grand pourcentage de sites ont constaté une baisse.

Les corrections de bugs apportées au calcul de la métrique sous-jacente peuvent entraîner des scores différents. Cela concerne relativement peu de sites, mais ils peuvent avoir un impact important dans certaines situations. Globalement, environ 8% des sites ont enregistré une amélioration du taux suite à des changements d'implémentation des métriques et ont obtenu un score pour environ 4% des sites. en raison de modifications apportées à l'implémentation des métriques. Environ 88% des sites n'ont pas été affectés par ces correctifs.

Les modifications apportées à la courbe des scores individuels ont également eu un impact très faible sur l'évolution du score global. Mer vérifiez régulièrement que la courbe de score s'aligne sur les métriques observées dans le tableau de bord HTTPArchive ensemble de données. Exclusion des sites concernés par d'importantes modifications de mise en œuvre (mineurs) les ajustements apportés à la courbe du score pour des métriques individuelles ont amélioré les scores d'environ 3% des sites et a diminué le score d'environ 4% des sites. Environ 93% des sites n'ont pas été affectés par ce changement.

Calculateur de notation

Nous avons publié un calculateur de scores pour vous aider vous découvrirez l'évaluation des performances. Le simulateur vous permet également de comparer la version 5 de Lighthouse et la version 5 6. Lorsque vous exécutez un audit avec Lighthouse 6.0, le rapport contient un lien vers le calculateur avec vos résultats.

<ph type="x-smartling-placeholder">

</ph>

Un grand merci à Ana Tudor pour la mise à niveau de la jauge !

Nouveaux audits

JavaScript inutilisé

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

Cet audit n'est pas entièrement nouveau: il a été ajouté dans mi-2017, mais en raison de l'impact sur les performances, il a été désactivé par défaut pour que Lighthouse possible. La collecte de ces données de couverture est beaucoup plus efficace. par défaut.

Audits de l'accessibilité

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

• aria-hidden-body
• aria-mise au point-caché
• aria-input-field-name
• aria-toggle-field-name
• form-field-multiple-labels
• en-tête-ordre
• Duplicate-id-active (ID en double actif)
• Duplicate-id-aria

Icône Masquable

Le nouveau format d'icônes masquables permet de créer des icônes pour votre PWA. s’affiche parfaitement sur tous les types d’appareils. Pour optimiser l'apparence de votre PWA, nous avons lancé un nouvel audit pour vérifier si votre fichier manifest.json est compatible avec ce nouveau format.

Déclaration de jeu de caractères

L'élément meta charset déclare l'encodage des 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 deviner quel codage utiliser. Si un le navigateur ne parvient pas à deviner, et un élément meta charset est détecté, l'analyseur génère généralement tout le travail effectué jusqu'à présent et recommence à zéro, ce qui conduit à une mauvaise expérience pour l'utilisateur. Cette nouvelle l'audit vérifie que le codage des caractères de la page est valide et que celui-ci est défini au début et à l'avance.

Lighthouse CI

À CDS en novembre dernier nous avons annoncé le lancement de Lighthouse CI, la solution Open Source Node CLI et serveur permettant de suivre les résultats Lighthouse sur chaque commit de votre intégration continue et nous avons beaucoup progressé depuis la version alpha. La CI Lighthouse est désormais compatible pour de nombreux fournisseurs d'outils d'intégration continue, tels que Travis, Circle, GitLab et GitHub Actions. Prêt pour le déploiement docker images font de la configuration C'est très simple. Le nouveau tableau de bord complet révèle désormais les tendances pour chaque catégorie et chaque métrique. dans Lighthouse pour une analyse détaillée.

Commencez à utiliser Lighthouse CI dans votre projet dès aujourd'hui en suivant notre guide de démarrage.

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

Nous avons renommé le panneau Audits en panneau Lighthouse. J'en ai dit assez !

Selon 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 à l'aide de la commande Command menu :

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 ouvrez le menu Commande.
3. Commencez à saisir "Lighthouse".
4. Appuyez sur la touche Enter.

Émulation mobile

Lighthouse adopte une approche de priorité à la mobilité. Les problèmes de performances sont plus fréquents les environnements mobiles, mais les développeurs ne réalisent souvent pas de tests dans ces conditions. C'est la raison pour laquelle dans Lighthouse applique l'émulation mobile. L'émulation comprend les éléments suivants:

• Simulation de la lenteur du réseau et de la lenteur du processeur (via un moteur de simulation appelé Lantern, par exemple).
• Émulation de l'écran de l'appareil (identique aux 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 les ingénieurs de performance utilisent le Moto G4 à des fins de test. Lighthouse suit la même approche 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 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 précédemment Nexus 5 Build/MRA58N sera 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

La Extension Chrome pour Lighthouse est un moyen pratique d'exécuter Lighthouse localement. Malheureusement, l'assistance était compliquée. Nous avons eu l'impression que le panneau Lighthouse des outils pour les développeurs Chrome était plus agréable à utiliser (le rapport s'intègre à d'autres panneaux), nous pourrions réduire nos frais d'ingénierie en simplifiant le .

Au lieu d'exécuter Lighthouse en local, l'extension utilise désormais l'outil PageSpeed Insights API. Nous sommes conscients que cela va ne suffiront pas à remplacer certains de nos utilisateurs. Voici les principales différences:

• PageSpeed Insights n'est pas en mesure d'auditer les sites Web non publics, car il est exécuté à distance et non à votre instance Chrome locale. Si vous devez auditer un site Web non public, utilisez le panneau Lighthouse (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 le lancement.
• PageSpeed Insights est une API Google. Son utilisation implique l'acceptation des conditions d'utilisation des API Google de service. Si vous ne souhaitez pas ou ne pouvez pas accepter les conditions d'utilisation, utilisez le panneau Lighthouse (Outils de développement) ou la CLI du nœud.

La bonne nouvelle, c'est que simplifier l'histoire du produit nous a permis de nous concentrer sur d'autres des problèmes. C'est pourquoi nous avons lancé Lighthouse pour Firefox .

Budgets

Des budgets de performances ont été introduits dans Lighthouse 5.0, compatible avec l'ajout de seuils la quantité de chaque type de ressource (scripts, images ou fichiers CSS, par exemple) qu'une page peut diffuser.

Lighthouse 6.0 ajoute Prise en charge des métriques de budgétisation, Vous pouvez donc désormais définir des seuils pour des métriques spécifiques telles que le FCP. Pour le moment, les budgets ne sont disponibles à la CLI du nœud et à la CI Lighthouse.

Liens d'emplacement source

Certains des problèmes détectés par Lighthouse concernant une page peuvent être remontés à une ligne spécifique de le code source, et le rapport indiquera le fichier et la ligne exacts pertinents. Pour que cela soit facile à 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.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">.

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

À l'horizon

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

• Détection des 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 JavaScript non utilisé pour fournir une précision au niveau du module.
• Des visualisations de carte proportionnelle mettant en évidence les modules qui nécessitent une action.
• Afficher le code source d'origine pour les éléments de rapport associés à un "emplacement source".

<ph type="x-smartling-placeholder">

</ph>

Audit JavaScript inutilisé à l'aide de mappages 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 voir Les audits expérimental de Lighthouse avec l'indicateur CLI suivant:

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

Merci !

Nous vous remercions d'utiliser 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 sites Web.

Que pouvez-vous faire ?

• Ouvrez Chrome Canary et testez 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 bien !

Nous sommes passionnés par le Web et nous aimons collaborer avec la communauté des développeurs pour concevoir des outils contribuent à améliorer le Web. Lighthouse est un projet Open Source, des contributeurs qui s'occupent de tout, qu'il s'agisse de corriger des fautes de frappe, de refactoriser la documentation ou encore les audits. Vous souhaitez apporter votre contribution ? Accédez au dépôt GitHub Lighthouse.