Optimiser ses Core Web Vitals avec Lighthouse

Lighthouse est un outil automatisé et open source qui évalue la qualité des pages Web. On le trouve dans les Chrome DevTools, dans PageSpeed Insights, en intégration continue ou encore dans WebPageTest. Il permet de mesurer en laboratoire les Core Web Vitals et de repérer les éléments concrets qui pèsent sur l’expérience utilisateur, comme les nœuds qui provoquent des décalages de mise en page.

Pour le SEO, Lighthouse est précieux : il transforme des métriques abstraites en recommandations actionnables, audit par audit. Il s’inscrit dans la démarche plus large pour auditer ses Core Web Vitals avec les outils Google. Les versions récentes ajoutent des captures d’écran d’éléments, qui rendent l’inspection visuelle bien plus simple. Encore faut-il comprendre ce que chaque mesure couvre, et surtout ce qu’elle ne couvre pas, pour ne pas se tromper de priorité.

Lighthouse mesure de façon synthétique le Largest Contentful Paint (LCP), le Cumulative Layout Shift (CLS) et le Total Blocking Time (TBT), ce dernier servant de proxy de laboratoire pour la réactivité. La section Métriques du rapport en donne une vue récapitulative, utile pour repérer les aspects à traiter en priorité. D’autres métriques comme le First Contentful Paint (FCP) sont également disponibles.

Il est essentiel de comprendre la limite de ces mesures : Lighthouse évalue surtout le chargement initial dans un environnement simulé, en émulant un appareil lent. Les décalages de mise en page ou les tâches longues qui surviennent après le chargement n’y apparaissent pas. C’est pourquoi les données de terrain, issues du rapport d’expérience utilisateur Chrome ou du RUM, restent un complément indispensable : elles reflètent l’expérience réelle, là où le laboratoire offre le diagnostic.

Lighthouse propose des audits ciblés pour chaque dimension de l’expérience. Le tableau ci-dessous récapitule les plus utiles et ce qu’ils permettent de corriger.

Lorsque l’élément LCP est une image découverte tardivement par le navigateur, par exemple parce qu’un bundle JavaScript doit se charger avant qu’elle soit détectable, le préchargement accélère son affichage. Lighthouse signale aussi une erreur fréquente : une image LCP chargée par erreur en différé, ce qui retarde son apparition. Les images critiques au-dessus de la ligne de flottaison ne doivent jamais être en chargement différé. Pour traiter ce point de bout en bout, suivez notre guide pour optimiser le LCP.

Le préchargement fonctionne pour les images responsives comme pour les images définies en arrière-plan CSS. Il doit toutefois rester parcimonieux : la bande passante initiale est rare, et trop précharger prive d’autres ressources critiques (CSS, JavaScript, polices) de priorité. L’exemple ci-dessous précharge une image responsive avec la même logique de sélection que srcset et sizes.

Les Chrome DevTools permettent de bloquer des requêtes réseau pour observer l’impact de la suppression d’une ressource. C’est très utile pour mesurer le coût d’un script tiers ou d’un outil de suivi sur le Total Blocking Time. La démarche fonctionne aussi avec Lighthouse : on bloque la requête, on relance l’audit, et on compare les scores avant et après. Dans l’exemple de Google, retirer un polyfill inutile fait passer le score de 63 à 70 et le TBT de 400 à 300 millisecondes. Pour systématiser cette lecture, voyez comment trouver des opportunités avec Lighthouse.

Dans la même logique, les intégrations tierces coûteuses, comme une vidéo YouTube, peuvent être remplacées par une façade : un aperçu léger qui ne charge la version complète qu’à l’interaction de l’utilisateur. Lighthouse met en évidence le code tiers qui bloque le thread principal et recommande les ressources à différer ou à charger en façade.