Lighthouse 8.4 est disponible immédiatement sur la ligne de commande et dans Chrome Canary. Elle intégrera la version stable de Chrome dans Chrome 95 et sera disponible dans PageSpeed Insights dans un délai d'une semaine.
Pour essayer la CLI du nœud Lighthouse, utilisez les commandes suivantes:
npm install -g lighthouse
lighthouse https://www.example.com --view
Consultez la liste complète des modifications dans le journal des modifications 8.4.
Nouveaux audits
Ne pas charger les images Largest Contentful Paint de manière différée
Le chargement différé des images peut constituer un moyen efficace de différer le chargement des images hors écran, afin qu'elles n'interfèrent pas avec le chargement du contenu situé au-dessus de la ligne de flottaison.
Toutefois, si l'élément LCP d'une page est une image, son chargement différé peut avoir un effet négatif important sur le LCP. Le navigateur peut placer l'image dans la file d'attente et récupérer d'abord d'autres ressources, au lieu de donner la priorité à l'image pour qu'elle soit immédiatement téléchargée. Une étude récente sur le chargement différé dans WordPress a révélé que le LCP peut s'améliorer de 15% pour certains sites si les images de la fenêtre d'affichage initiale ne sont pas chargées en différé.
Lighthouse va maintenant détecter si l'élément LCP était une image à chargement différé et vous recommander de supprimer l'attribut loading de cette image.
Pour en savoir plus, consultez la proposition initiale et la demande d'extraction pour la mise en œuvre.
Définir une fenêtre d'affichage pour mobile afin d'améliorer le délai de première entrée
L'audit viewport fait partie de la catégorie des bonnes pratiques depuis des années, mais le point 8.4 accueille également ces conseils dans la catégorie "Performances".
De nombreux navigateurs mobiles acceptent la fonctionnalité "Appuyer deux fois pour zoomer" pour permettre aux utilisateurs d'agrandir facilement du contenu non conçu pour un écran mobile, c'est-à-dire sans <meta name="viewport"> explicite pour mobile. En pratique, cela signifie que le navigateur doit attendre jusqu'à 300 ms après l'appui de l'utilisateur pour voir si un deuxième appui va suivre. Pendant ce temps, la page ne peut pas répondre à l'appui initial. Cela se traduit par un FID défaillant de plusieurs centaines de millisecondes.
Une étude récente portant sur les données des archives HTTP a révélé que plus de la moitié des sites dont le score était supérieur ou égal à 90 dans Lighthouse, mais dont au moins un test Core Web Vitals échouait, ne disposaient pas d'une fenêtre d'affichage pour mobile et échouaient avec le FID. Par conséquent, la section sur les performances de Lighthouse recommande à présent d'ajouter une fenêtre d'affichage semblable à celle-ci si aucune fenêtre d'affichage n'est détectée:
<meta name="viewport" content="width=device-width">
Pour en savoir plus, consultez Problèmes liés à la proposition et Demande d'extraction pour la mise en œuvre.
Contacter l'équipe Lighthouse
Pour discuter des nouvelles fonctionnalités, des modifications apportées à la version 8.4 ou de tout autre sujet lié à Lighthouse:
- Signalez un problème ou envoyez vos commentaires via le dépôt GitHub Lighthouse.
- Contactez l'équipe Lighthouse sur Twitter (@____lighthouse).