Google Lighthouse : tout ce que vous devez savoir pour auditer votre site web

Qu'est-ce que Google Lighthouse et à quoi ça sert vraiment ?

Google Lighthouse est un outil d'audit open-source développé par Google, intégré nativement dans Chrome DevTools depuis 2017. Son principe : charger une page dans un contexte contrôlé, mesurer une série d'indicateurs techniques, et produire un rapport structuré avec des scores et des recommandations actionnables.

Lighthouse audite jusqu'à cinq catégories : Performance, Accessibilité, SEO, Best Practices, et PWA (cette dernière ayant été supprimée dans Lighthouse 12 en mai 2024). Chacune produit un score de 0 à 100.

Ce que Lighthouse ne fait pas : mesurer l'expérience de vos vrais utilisateurs. Tout rapport Lighthouse est du lab data : des données synthétiques produites dans des conditions standardisées, sur une machine virtuelle avec un appareil émulé et une connexion simulée. C'est la limite fondamentale à intérioriser avant tout le reste.

Lab data vs field data : la distinction qui change tout

Lighthouse = diagnostic en conditions standardisées. CrUX = réalité de votre audience.

PageSpeed Insights combine les deux : la partie haute de la page affiche les données terrain CrUX (si disponibles, ce qui requiert un minimum de trafic sur l'origine) ; la partie basse contient le rapport Lighthouse lab. Confondre ces deux sections est responsable de la majorité des malentendus sur les scores de performance.

Comment lancer un audit Lighthouse

Trois méthodes, selon le contexte et le niveau de reproductibilité requis.

Chrome DevTools

1. Ouvrir la page cible dans Chrome
2. F12 → onglet Lighthouse
3. Sélectionner les catégories et le profil (Mobile ou Desktop)
4. Cliquer sur Analyser la charge de la page

Pour un run reproductible : ouvrir une fenêtre de navigation privée et désactiver toutes les extensions Chrome. Un bloqueur de publicités ou un gestionnaire de mots de passe peut modifier le comportement de la page et fausser les résultats.

PageSpeed Insights

PageSpeed Insights ne nécessite aucune installation. Entrer une URL, obtenir en 30 secondes un rapport Lighthouse lab + les données CrUX terrain. C'est la méthode la plus rapide pour une première lecture, et la seule qui expose les deux sources côte à côte.

CLI Node.js

Pour les audits en CI/CD ou les pages derrière authentification :

npm install -g lighthouse

# Audit standard, profil mobile, rapport HTML
lighthouse https://example.com \
  --output html \
  --output-path ./rapport.html \
  --throttling-method=simulate \
  --emulated-form-factor=mobile

# Pages authentifiées (exemple avec cookie de session)
lighthouse https://example.com/dashboard \
  --extra-headers '{"Cookie": "session=abc123"}' \
  --output json

L'option --budget-path permet de faire échouer un build CI si un seuil de performance est dépassé, utile pour prévenir les régressions à chaque déploiement.

La variabilité : pourquoi deux runs successifs divergent

Relancer le même audit deux fois de suite peut donner des scores Performance qui diffèrent de 10 à 15 points. Trois causes :

• Jitter CPU : la machine virtuelle partage des ressources avec d'autres processus au moment du run
• État de la connexion : même en throttling simulé, les ressources traversent votre réseau local jusqu'au serveur
• Mise en cache réseau : un premier run peut initier des connexions CDN que le second run trouve déjà établies

Règle pratique : ne jamais tirer de conclusion sur un run unique. Faire au moins 3 runs consécutifs et prendre la médiane.

Décrypter les 5 catégories de score

Chaque audit Lighthouse produit jusqu'à cinq scores distincts. Seul le score Performance est un composite numérique. Les quatre autres agrègent des audits binaires (pass/fail) pondérés.

Le score Performance en détail

Le score n'est pas une moyenne simple. Chaque métrique est pondérée, puis transformée via une courbe logarithmique pour compresser les extrêmes. Les pondérations actuelles (Lighthouse 12) :

LCP + TBT = 55 % du score. Améliorer ces deux métriques produit le déplacement le plus important. INP n'entre pas dans le calcul du score lab : c'est un Core Web Vital terrain uniquement qui nécessite des interactions réelles pour être mesuré.

Les zones de couleur suivent trois seuils : vert (90–100), orange (50–89), rouge (0–49).

Accessibilité : l'audit automatisé ne voit pas tout

Un score Accessibilité de 100 ne signifie pas que votre site est accessible. Les outils automatisés détectent environ 30 à 40 % des problèmes WCAG. Le reste (ordre de focus logique, textes alternatifs sémantiquement vides, navigation au clavier dans les composants complexes) exige un test manuel avec lecteur d'écran.

SEO : un point d'entrée, pas un audit

Le score SEO de Lighthouse couvre les fondamentaux : balises <title> et meta description présentes, attributs alt sur les images, liens crawlables, robots.txt valide. Il ne dit rien sur la qualité du contenu, le profil de liens, les Core Web Vitals terrain, ou la structure du crawl. C'est un signal utile pour détecter des erreurs grossières, rien de plus.

Les métriques performance qui comptent : LCP, INP, CLS, TBT, FCP, Speed Index

⏱️ ↓

0 ms

TTFB

🖼️ ↓

0 s

LCP

📐 ↓

0

CLS

🎯 ↑

0 /100

Score

Cinq métriques composent le score Performance. Deux sont des Core Web Vitals officiels (LCP, CLS), utilisés par Google comme signaux de ranking.

Pour les définitions complètes, mécanismes de mesure et stratégies de correction, voir la page Core Web Vitals mesurés par Lighthouse.

LCP : Temps jusqu'à l'affichage de l'élément le plus grand visible dans le viewport : image hero, bloc de texte, vidéo avec poster. C'est la métrique la plus impactée par la qualité du CDN, l'optimisation des images, et les ressources render-blocking.

INP : Réactivité aux interactions utilisateur (clics, frappes clavier). Remplace FID comme Core Web Vital depuis mars 2024. Mesurable uniquement en terrain. En lab, Lighthouse utilise TBT comme approximation.

CLS : Stabilité visuelle : cumule les déplacements de mise en page inattendus. Causé par des images sans dimensions déclarées, des polices web sans font-display, des injections DOM tardives (bannières cookies, widgets tiers).

TBT : Temps total pendant lequel le thread principal est bloqué plus de 50 ms entre FCP et TTI. Proxy imparfait de l'INP : une page avec TBT bas peut quand même avoir un INP élevé si des interactions déclenchent du JavaScript lourd post-chargement.

Limites de Lighthouse : ce que le score ne dit pas

C'est la section que la plupart des guides ignorent. La comprendre est ce qui sépare un usage amateur de Lighthouse d'un usage professionnel.

Le profil de throttling ne correspond pas à votre audience

Par défaut, Lighthouse mobile simule un Moto G4 avec un CPU 4× plus lent que la machine hôte, et une connexion Slow 4G (1,6 Mbps, 150 ms de latence). Ce profil représente le bas du parc mondial, il a été conçu pour pousser les développeurs à optimiser pour tout le monde.

Mais si votre audience réelle est équipée d'appareils récents et de connexions rapides, ce profil est systématiquement pessimiste. Votre score sera mécaniquement plus bas que l'expérience réelle de vos utilisateurs. Vous risquez de prioriser des optimisations qui n'améliorent pas leur vécu.

Les runs sont toujours à cache froid

Lighthouse charge la page sans cache navigateur. Vos vrais visiteurs reviennent avec un cache partiellement chaud, des connexions CDN déjà établies, et des ressources en mémoire. Le premier chargement mesuré par Lighthouse est le pire cas. Ce mode de chargement est légitime comme signal de régression, mais trompeur comme mesure de l'expérience moyenne : dans la réalité, les utilisateurs ne parcourent pas qu'une seule page sur votre site.

Score rouge en lab, Core Web Vitals verts en terrain

L'écart peut être spectaculaire.

◆Retour terrain·8 ans · 35+ clients

Mon retour terrain : Score Lighthouse < 50, Core Web Vitals validés sur CHANEL.

J'ai accompagné CHANEL pendant quatre ans sur leur performance web. Le score Lighthouse mobile de chanel.com s'affichait en rouge : FCP à 5,9 s, LCP à 14,6 s, Speed Index à 7,2 s dans les conditions PSI. Un rapport que n'importe quel client non averti lirait comme "site lent, à corriger d'urgence". La réalité terrain était inverse : LCP à 1,7 s, INP à 177 ms, CLS à 0 dans les données CrUX. Core Web Vitals validés globalement, parmi les meilleurs scores du secteur luxe en web performance. L'explication : PSI émule un vieux Moto G4 sur Slow 4G, un profil sans rapport avec l'audience réelle de CHANEL, équipée d'appareils premium et de connexions rapides. Sur ces vrais devices, le CDN edge sert les assets en quelques millisecondes, et les optimisations déployées pendant ces quatre ans (déploiement d'images en formats modernes, optimisations INP, ...) se traduisent là où ça compte. La leçon : le profil de throttling de Lighthouse est calibré pour le bas du spectre mondial. Si votre audience est sur des appareils premium, votre score lab sera toujours plus bas que votre réalité terrain. Toujours croiser avec CrUX avant de tirer une conclusion.

Le cas TTI : quand Lighthouse retire une métrique parce qu'elle ne marche pas

Jusqu'à Lighthouse 9, le score Performance incluait le Time To Interactive (TTI), une métrique censée mesurer "quand la page devient interactive". Elle était pondérée à 10 % du score. Elle a été retirée dans Lighthouse 10 (février 2023) et remplacée par TBT. La raison ? TTI était fondamentalement instable et mal corrélée avec l'expérience utilisateur réelle.

Le problème de fond : TTI attend une fenêtre de 5 secondes sans aucune Long Task (tâche JS dépassant 50 ms) et avec au maximum 2 ressources téléchargées en parallèle. En pratique, une seule tâche de 51 ms remettait le compteur à zéro, un effet de seuil brutal qui rendait la métrique très sensible aux variations mineures du JavaScript tiers. Sur des sites réels avec des analytics, des widgets ou des A/B tests, TTI oscillait largement entre deux runs consécutifs.

Comme le résumait Boris Schapira dans son analyse de la métrique : TTI ne mesure pas "le temps avant que la page devienne interactive", c'est une assurance qu'à partir d'un certain point, il n'y a plus de jank. Nuance importante, et contre-intuitive pour quiconque lit "Time To Interactive" au premier degré.

C'est un exemple concret du fait que les métriques de Lighthouse évoluent au fil du temps, et que celles d'aujourd'hui ne sont pas définitives. TBT, qui a remplacé TTI, est lui-même un proxy imparfait de l'INP terrain : il mesure la pression sur le thread principal au chargement, pas la réactivité aux interactions réelles.

Ce que Lighthouse ne capture pas du tout

• INP réel : les interactions nécessitent un utilisateur réel. TBT ne prédit pas l'INP de façon fiable dès que des handlers JS lourds se déclenchent post-chargement.
• Performance géographique : un run depuis votre machine locale. WebPageTest permet de tester depuis Paris, Mumbai, São Paulo. Sur des sites sans CDN correctement configuré, les écarts dépassent régulièrement 3 s sur le LCP.
• Performance multi-pages : Lighthouse audite une URL à la fois. La navigation interne (transitions SPA, prefetch, Service Worker) n'est pas capturée.
• L'état réel de la page : A/B tests actifs, personnalisation, panier rempli, notifications push, rien de cela n'est reproduit dans un run synthétique.

Quand utiliser quoi

Pour choisir entre PSI et WebPageTest selon les cas d'usage, voir le comparatif WebPageTest vs PageSpeed Insights. Pour aller plus loin avec un audit de performance professionnel, Lighthouse est notre point de départ : jamais notre seul outil.

FAQ

Sources

• Lighthouse — dépôt GitHub officiel
• Documentation Lighthouse — Chrome Developers
• PageSpeed Insights
• Web.dev — Core Web Vitals et métriques web
• Chrome UX Report (CrUX) — documentation
• Measuring Interactivity with TTI — Boris Schapira