Qu'est-ce que la surveillance des performances Lighthouse ?
Google Lighthouse est un outil open source qui audite une page web sur les performances, l'accessibilité, les bonnes pratiques et le SEO. Un audit isolé montre les performances d'une page aujourd'hui ; la surveillance des performances Lighthouse répète ces audits à intervalle régulier pour que vous puissiez suivre les tendances, repérer les régressions après une mise en production et prouver l'effet de vos optimisations. Ce guide explique ce que mesure Lighthouse, comment le score de performance est calculé, quels seuils Core Web Vitals s'appliquent aujourd'hui (y compris INP, qui a remplacé FID en 2024) et comment exploiter les résultats.
Ce que mesure Lighthouse
Chaque rapport Lighthouse note une page de 0 à 100 dans quatre catégories :
Performances
La rapidité avec laquelle la page se charge, devient utilisable et reste visuellement stable, d'après des métriques de laboratoire comme Largest Contentful Paint, Total Blocking Time et Cumulative Layout Shift.
Accessibilité
Si les personnes utilisant des technologies d'assistance peuvent se servir de la page : contraste des couleurs, texte alternatif, libellés de formulaires, ordre des titres et navigation au clavier.
Bonnes pratiques
Les standards web actuels comme HTTPS, l'absence d'erreurs dans la console du navigateur, un code tiers sûr et des images correctement dimensionnées.
SEO
Les exigences de base des moteurs de recherche : un titre et une meta description, des liens explorables, un hreflang valide et une page non bloquée à l'indexation.
Comment le score de performance Lighthouse est calculé
Depuis Lighthouse 10, le score de performance est une moyenne pondérée de cinq métriques de laboratoire. Total Blocking Time et les deux Core Web Vitals que Lighthouse peut mesurer pèsent le plus :
- Total Blocking Time (TBT)
- 30 %
- Largest Contentful Paint (LCP)
- 25 %
- Cumulative Layout Shift (CLS)
- 25 %
- First Contentful Paint (FCP)
- 10 %
- Speed Index
- 10 %
Un score de 90 à 100 est considéré comme bon, de 50 à 89 comme à améliorer et de 0 à 49 comme médiocre. Time to Interactive (TTI) ne fait plus partie du score.
Les scores varient d'une exécution à l'autre en raison des conditions réseau, de la charge du serveur et des extensions du navigateur. C'est pourquoi les tendances sur de nombreuses exécutions sont plus fiables qu'un audit isolé.
Core Web Vitals : LCP, INP et CLS
Les Core Web Vitals sont les trois métriques d'expérience utilisateur de Google pour le chargement, la réactivité et la stabilité visuelle. Interaction to Next Paint (INP) a officiellement remplacé First Input Delay (FID) comme métrique de réactivité le 12 mars 2024. Google recommande de mesurer chaque métrique au 75e percentile des chargements de page, séparément pour le mobile et le desktop.
Largest Contentful Paint (LCP)
Bon : 2,5 s ou moins · Médiocre : plus de 4 s
LCP mesure le temps nécessaire pour afficher la plus grande image ou le plus grand bloc de texte visible dans la fenêtre. C'est le meilleur indicateur du moment où les utilisateurs voient le contenu principal.
Pourquoi c'est important: Un LCP lent laisse les visiteurs devant une page incomplète. Les causes habituelles sont des réponses serveur lentes, des ressources bloquant le rendu et de grandes images d'en-tête.
Comment l'améliorer:
- Réduisez le temps de réponse du serveur (TTFB) grâce au cache et à un CDN
- Servez l'image LCP dans un format moderne (WebP ou AVIF) et à la bonne taille
- Ne chargez pas l'image LCP en différé et donnez-lui fetchpriority="high"
- Supprimez ou différez le CSS et le JavaScript qui bloquent le rendu
Interaction to Next Paint (INP)
Bon : 200 ms ou moins · Médiocre : plus de 500 ms
INP mesure la rapidité avec laquelle la page réagit aux clics, aux appuis et aux frappes au clavier pendant toute la visite, et retient l'une des interactions les plus lentes. FID ne mesurait que le délai avant le traitement de la première interaction.
Pourquoi c'est important: Un INP médiocre donne l'impression d'une page lente ou cassée, même si elle s'est chargée rapidement. La cause la plus fréquente : de longues tâches JavaScript qui bloquent le thread principal.
Comment l'améliorer:
- Découpez les tâches longues et rendez la main au thread principal
- Réduisez et différez les scripts tiers
- Gardez les gestionnaires d'événements légers et déplacez les traitements lourds hors du thread principal
- Évitez les mises à jour du DOM lourdes et complexes après chaque interaction
Cumulative Layout Shift (CLS)
Bon : 0,1 ou moins · Médiocre : plus de 0,25
CLS mesure l'ampleur des déplacements inattendus du contenu visible pendant que la page est ouverte. Un décalage se produit lorsqu'un élément change de position entre deux images sans action de l'utilisateur.
Pourquoi c'est important: Les décalages de mise en page font perdre le fil aux utilisateurs ou les font toucher le mauvais bouton. Ils sont généralement dus à des images sans dimensions, à des publicités ou contenus intégrés chargés tardivement et aux polices web.
Comment l'améliorer:
- Définissez la largeur et la hauteur (ou aspect-ratio) des images, vidéos et iframes
- Réservez de l'espace pour les publicités, les contenus intégrés et le contenu dynamique
- N'insérez pas de contenu au-dessus du contenu existant sauf à la demande de l'utilisateur
- Utilisez font-display et préchargez les polices clés pour limiter les décalages de texte
Mesurer INP avec Lighthouse
Un audit Lighthouse standard charge la page sans interagir avec elle ; il ne peut donc pas mesurer INP. Utilisez Total Blocking Time comme indicateur de laboratoire : un TBT élevé signifie généralement un INP médiocre pour les vrais utilisateurs. Pour connaître les valeurs réelles d'INP, consultez les données de terrain du Chrome UX Report dans PageSpeed Insights ou le rapport Core Web Vitals de Google Search Console.
Données de laboratoire et données de terrain
Lighthouse produit des données de laboratoire : un test contrôlé sur un appareil et un réseau simulés. Les données de terrain proviennent de vrais utilisateurs de Chrome. Vous avez besoin des deux.
Données de laboratoire (Lighthouse)
Reproductibles et disponibles immédiatement, même pour les pages à faible trafic. Idéales pour repérer les régressions avant et après une mise en production et pour déboguer des problèmes précis.
Données de terrain (Chrome UX Report)
Elles reflètent de vrais appareils, réseaux et interactions, et c'est sur elles que Google s'appuie pour les Core Web Vitals dans la recherche. Elles sont agrégées sur les 28 derniers jours : les changements n'apparaissent donc que lentement.
Performances mobile et desktop
Les résultats sur mobile et sur desktop diffèrent souvent fortement, et Google évalue les Core Web Vitals séparément pour chacun. Testez les deux.
Mobile
L'audit mobile de Lighthouse simule un smartphone de milieu de gamme avec un processeur bridé et un réseau plus lent. Les scores mobiles sont généralement plus bas et plus proches de ce que vivent de nombreux visiteurs réels.
Desktop
L'audit desktop utilise une connexion simulée plus rapide, sans bridage du processeur mobile. Un bon score desktop ne signifie pas que l'expérience mobile est bonne elle aussi.
Comment améliorer votre score de performance Lighthouse
La plupart des gains viennent d'une poignée de techniques. Commencez par le domaine que votre rapport signale le plus :
Chemin de rendu critique
Affichez plus vite le premier et le plus grand contenu (FCP, LCP).
Techniques:- Intégrez le CSS critique en ligne et différez le reste
- Préchargez l'image LCP et les polices clés
- Supprimez le JavaScript qui bloque le rendu
- Améliorez le temps de réponse du serveur (TTFB)
Images et médias
Les images sont souvent les ressources les plus lourdes d'une page (LCP, CLS).
Techniques:- Utilisez WebP ou AVIF avec des solutions de repli
- Servez des images responsives avec srcset et sizes
- Ne chargez en différé que les images situées sous la ligne de flottaison
- Indiquez toujours les dimensions des images
JavaScript
Moins de travail sur le thread principal, c'est une meilleure réactivité (TBT, INP).
Techniques:- Découpez les bundles et chargez le code à la demande
- Supprimez le code inutilisé grâce au tree shaking
- Découpez les tâches longues
- Limitez et différez les scripts tiers
Réseau et cache
Livrez chaque ressource plus vite (toutes les métriques).
Techniques:- Utilisez un CDN proche de vos utilisateurs
- Servez vos contenus en HTTP/2 ou HTTP/3
- Définissez des durées de cache longues pour les ressources statiques
- Réduisez les requêtes DNS et réutilisez les connexions
Problèmes de performance courants et solutions
Les problèmes de performance suivent souvent des schémas connus. En voici trois que vous reconnaîtrez, avec les métriques concernées et par où commencer.
La boutique en ligne ralentit pendant les soldes
Les pages produit s'alourdissent et le serveur ralentit juste au moment où le trafic culmine.
- LCP lent à cause d'images produit volumineuses et non optimisées
- Décalages de mise en page dus à des bannières et avis chargés tardivement
- TBT élevé à cause des scripts marketing et de suivi
Les acheteurs attendent plus longtemps et davantage abandonnent avant le paiement
- Redimensionnez et compressez les images produit et servez-les en WebP ou AVIF
- Réservez de l'espace pour les bannières et les widgets dynamiques
- Auditez les gestionnaires de balises et différez les scripts non essentiels
- Mettez les pages en cache en périphérie avec un CDN
Site d'actualité face à un pic de trafic
Une information de dernière minute fait exploser le trafic bien au-delà de la normale.
- FCP et LCP lents, car le serveur d'origine est saturé
- Décalages de mise en page dus aux publicités et aux médias intégrés
- Mauvaise réactivité à cause de scripts publicitaires lourds
Les lecteurs partent avant que l'article ne s'affiche
- Servez des versions en cache ou statiques des pages d'articles
- Réservez des emplacements fixes pour les publicités et contenus intégrés
- Chargez les scripts tiers après le contenu principal
- Augmentez la capacité des serveurs avant les pics attendus
L'application web ralentit à chaque version
Les nouvelles fonctionnalités ajoutent peu à peu du JavaScript jusqu'à ce que l'application paraisse lente.
- Des bundles JavaScript de plus en plus gros
- Des tâches longues qui augmentent le TBT et dégradent l'INP
- Davantage de dépendances tierces
Les utilisateurs remarquent des lenteurs dans leurs tâches quotidiennes
- Découpez le code par route et chargez les fonctionnalités à la demande
- Fixez un budget de performance et vérifiez-le à chaque version
- Supprimez les dépendances inutilisées
- Suivez les scores Lighthouse en continu pour repérer tôt les régressions
Surveillance des performances Lighthouse avec nanokoi.io
nanokoi.io inclut dans toutes ses offres la surveillance des performances Google Lighthouse et le suivi des Core Web Vitals, en plus de la surveillance de sites web pour l'uptime, les certificats SSL et le DNS.
Audits Lighthouse automatisés
Au lieu de lancer Lighthouse à la main, laissez nanokoi.io auditer vos URL surveillées : vous disposez toujours de scores à jour pour les performances, l'accessibilité, les bonnes pratiques et le SEO.
Suivi des Core Web Vitals
Suivez l'évolution des scores et des Core Web Vitals pour savoir si une mise en production a amélioré ou dégradé la situation. Les données de surveillance peuvent être exportées en CSV, JSON ou XML pour vos propres analyses.
Rapports d'optimisation générés par IA
Les rapports d'optimisation générés par IA transforment les résultats Lighthouse en une liste de corrections classées par priorité. L'offre Professional ajoute des analyses de performance basées sur l'IA : consultez les tarifs pour voir le contenu de chaque offre.
Pour commencer
La surveillance des performances Lighthouse se met en place en quelques minutes. Vous débutez dans la surveillance ? Notre guide de la surveillance de sites web présente les bases.
- 1Ajoutez votre site: Créez un compte gratuit et ajoutez les URL à surveiller : l'offre Free en couvre jusqu'à 5.
- 2Examinez votre point de départ: Consultez les premiers scores Lighthouse et Core Web Vitals de chaque page et notez la métrique la plus faible.
- 3Corrigez d'abord le plus gros problème: Suivez le rapport d'optimisation généré par IA, en commençant par la métrique la plus éloignée de « bon ».
- 4Suivez la tendance: Comparez les scores après chaque mise en production pour confirmer les améliorations et repérer tôt les régressions.
FAQ sur la surveillance des performances Lighthouse
Qu'est-ce qu'un bon score de performance Lighthouse ?
Un score de 90 ou plus est considéré comme bon, de 50 à 89 comme à améliorer et en dessous de 50 comme médiocre. Voyez le score comme un repère : ce sont les métriques individuelles, notamment LCP, TBT et CLS, qui indiquent quoi corriger.
Lighthouse mesure-t-il encore FID ?
Non. FID a été retiré des Core Web Vitals en mars 2024 et remplacé par INP. Lighthouse ne peut pas mesurer INP lors d'un audit de chargement standard ; il affiche donc Total Blocking Time comme indicateur de laboratoire.
Pourquoi mes scores Lighthouse changent-ils d'une exécution à l'autre ?
Les conditions réseau, la charge du serveur, la puissance processeur disponible et les extensions du navigateur influencent les résultats de laboratoire. Une surveillance dans la durée lisse ce bruit et montre la vraie tendance.
Les scores Lighthouse influencent-ils le classement Google ?
Pas directement. Les systèmes de classement de Google utilisent les Core Web Vitals issus des données de terrain d'utilisateurs réels dans le cadre de l'expérience sur la page, et non le score Lighthouse lui-même. Lighthouse vous aide à trouver et corriger les problèmes qui dégradent ces métriques.
Lancez la surveillance de vos performances Lighthouse
Suivez les scores Lighthouse et les Core Web Vitals de vos pages clés et recevez des rapports d'optimisation générés par IA. L'offre Free couvre jusqu'à 5 URL.
Commencer la surveillance gratuitementAucune carte bancaire requise