Comment lire un rapport Lighthouse sans paniquer

La première règle : votre score n’est pas votre site

Ouvrez un rapport Lighthouse pour la première fois et vous vous retrouvez devant un mur de chiffres, de blocs codés par couleur et d’avertissements sur des éléments dont vous n’avez jamais entendu parler. La réaction naturelle est de paniquer. Le score est rouge. Dix-sept audits ont échoué. Le site est forcément cassé ?

Probablement pas. Lighthouse est un outil de diagnostic, pas un bulletin. Le score est un banc d’essai synthétique exécuté dans des conditions de laboratoire — souvent sur une connexion bridée, simulant un téléphone de milieu de gamme de 2017. Il vous indique comment votre site se comporte dans ce scénario précis, pas comment de vraies personnes en font l’expérience dans la nature.

C’est important, car la plupart des équipes se focalisent sur le score et passent à côté du contexte. Un score de 65 peut être tout à fait acceptable pour une application web complexe avec des données en temps réel. Un score de 95 peut tout de même offrir une mauvaise expérience si les mauvaises choses sont optimisées. Le score est un point de départ pour enquêter, pas un indicateur de réussite.

Ce qu’il faut lire d’abord : Core Web Vitals

Ignorez le score de performance global. Faites défiler jusqu’à la section Metrics et regardez trois chiffres : Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) et Interaction to Next Paint (INP). Ce sont les Core Web Vitals, et ce sont les seules métriques de performance que Google utilise comme signal de classement.

• LCP mesure le temps nécessaire au rendu du plus grand élément visible. Cible : moins de 2,5 secondes. Si vous dépassez 4 secondes, les utilisateurs attendent trop longtemps avant de voir du contenu significatif.
• CLS mesure la stabilité visuelle — à quel point la page se déplace pendant son chargement. Cible : moins de 0,1. Si vous dépassez 0,25, les utilisateurs cliquent accidentellement au mauvais endroit parce que les boutons ont bougé.
• INP mesure la réactivité — la rapidité avec laquelle la page réagit aux clics, aux touchers et aux frappes clavier. Cible : moins de 200 ms. Si vous dépassez 500 ms, le site semble lent.

Ces trois métriques sont corrélées à la frustration réelle des utilisateurs. Corrigez-les avant de vous soucier du reste.

Opportunities vs Diagnostics : connaître la différence

Lighthouse répartit ses constats en deux catégories : Opportunities et Diagnostics. Les Opportunities sont classées selon les gains de temps estimés. Les Diagnostics fournissent un contexte supplémentaire — des éléments qui peuvent poser problème, ou non.

Commencez par les Opportunities. Si Lighthouse indique que « Éliminer les ressources qui bloquent le rendu » pourrait faire gagner 1,2 seconde, c’est un gain concret. S’il indique que « Réduire le JavaScript inutilisé » pourrait faire gagner 0,1 seconde, cela ne vaut probablement pas la refonte.

Les Diagnostics sont plus délicats. « Éviter une taille de DOM excessive » semble inquiétant, mais si votre CLS est bon et que votre INP est rapide, un DOM volumineux ne nuit peut-être à personne. Les Diagnostics sont des indices, pas des obligations. Examinez ceux qui correspondent à vos métriques réelles.

Les audits que vous pouvez généralement ignorer

Certains avertissements Lighthouse sont résiduels ou trop agressifs. Voici ceux qui provoquent le plus de panique inutile :

• « N’utilise pas d’écouteurs passifs pour améliorer les performances de défilement » — C’est une micro-optimisation qui change rarement la donne. À moins d’avoir des preuves d’un défilement saccadé, passez votre chemin.
• « Les éléments image n’ont pas de largeur ni de hauteur explicites » — C’est important pour le CLS, mais seulement si les images provoquent des décalages de mise en page. Si votre CLS est déjà bon, ne refactorisez pas uniquement pour satisfaire l’audit.
• « Servir les images dans des formats nouvelle génération » — Oui, WebP et AVIF sont plus légers. Mais si vos images sont déjà optimisées et que votre LCP est rapide, c’est un plus, pas une crise.
• « Éviter les charges réseau énormes » — Lighthouse signale tout ce qui dépasse 1,6 Mo. Mais une page de 2 Mo qui se charge vite vaut mieux qu’une page de 500 Ko qui bloque le rendu. Concentrez-vous sur la façon dont les octets sont livrés, pas seulement sur le total.

Que faire quand tout est rouge

Si votre score Lighthouse est inférieur à 50 et que la plupart des audits échouent, vous êtes probablement face à l’une de ces trois causes profondes :

1. Des polices non optimisées. Les polices web restent le gain de performance le plus facile sur la plupart des sites. Vérifiez si vous chargez six graisses de police alors que vous n’en utilisez que deux, ou si vous livrez des fichiers WOFF au lieu de WOFF2.
2. Du CSS et du JavaScript qui bloquent le rendu. Si votre First Contentful Paint (FCP) dépasse 3 secondes, quelque chose empêche le navigateur de peindre. Cherchez de gros fichiers CSS ou des scripts synchrones dans le <head>.
3. Des images surdimensionnées. Si votre élément LCP est une image et qu’elle pèse 4 Mo, voilà votre problème. Compressez-la, chargez paresseusement les images sous la ligne de flottaison et utilisez la syntaxe d’images responsives.

Corrigez l’un de ces points et relancez Lighthouse. Vous verrez souvent un bond de 20 à 30 points. Attaquez ensuite le suivant.

Données de laboratoire vs données de terrain : le retour à la réalité

Lighthouse s’exécute en laboratoire. Il simule une connexion lente et un appareil lent, mais il ne peut pas simuler le comportement réel des utilisateurs — comment les gens font défiler la page, ce sur quoi ils cliquent, s’ils sont sur un Wi-Fi instable.

Pour un retour à la réalité, comparez vos résultats Lighthouse aux données de terrain du Chrome User Experience Report (CrUX). CrUX montre comment de vrais utilisateurs de Chrome vivent votre site au cours des 28 derniers jours. Si Lighthouse indique que votre LCP est de 4 secondes, mais que CrUX indique 2 secondes, faites confiance à CrUX. Si les deux sont mauvais, vous avez un vrai problème.

Vous pouvez trouver les données CrUX dans PageSpeed Insights (la version web de Lighthouse) ou dans Google Search Console sous « Core Web Vitals ». S’il y a un écart, cherchez pourquoi. Peut-être que vos vrais utilisateurs sont sur des réseaux plus rapides. Peut-être que Lighthouse teste une version de développement non optimisée.

Quand relancer Lighthouse

Lighthouse est bruité. Lancez-le trois fois de suite et vous obtiendrez trois scores différents, même sur la même page. C’est parce que la performance est variable — les processus en arrière-plan, la gigue réseau et les heuristiques du navigateur influencent tous le résultat.

Pour obtenir une base de référence stable, lancez Lighthouse en mode navigation privée avec toutes les extensions désactivées, ou utilisez la CLI avec l’option --preset=desktop pour des résultats plus cohérents. Lancez-le trois fois et faites la moyenne des scores. Si vous observez de fortes variations (plus de 10 points), autre chose ne va pas — peut-être que le serveur est lent, ou que la page charge des ressources différentes à chaque fois.

Relancez Lighthouse après chaque changement important. Vous déployez une nouvelle stratégie de polices ? Vérifiez le LCP. Vous chargez les images paresseusement ? Vérifiez le CLS. Vous ajoutez un script tiers ? Vérifiez l’INP. La performance n’est pas une correction ponctuelle ; c’est un budget que vous défendez.

Les outils qui vous aident à agir sur les constats de Lighthouse

Lighthouse vous dit ce qui est lent. Il ne vous dit pas toujours comment le corriger. Pour cela, il vous faut des outils supplémentaires :

• WebPageTest vous donne une vue en pellicule du chargement de la page, image par image. Indispensable pour diagnostiquer les problèmes de LCP et de CLS.
• Chrome DevTools Performance panel vous montre exactement quel JavaScript bloque le thread principal. Utilisez-le pour trouver la source d’un mauvais score INP.
• Les outils de compression d’images vous permettent d’optimiser les images directement dans le navigateur, ce qui est plus rapide et plus privé que de les téléverser vers un service tiers. Le traitement des images côté client est un gain pour la confidentialité, car vos images ne quittent jamais votre machine.

Lighthouse est le point de départ. Ces outils vous aident à terminer le travail.

Points clés à retenir

• Votre score Lighthouse est un banc d’essai de laboratoire, pas une mesure de l’expérience utilisateur réelle. Comparez-le aux données de terrain de CrUX avant de paniquer.
• Concentrez-vous d’abord sur les Core Web Vitals (LCP, CLS, INP). Ce sont les métriques corrélées à la frustration des utilisateurs et à l’impact SEO.
• Priorisez les Opportunities selon les gains de temps estimés. Ignorez les Diagnostics qui ne correspondent pas à vos vrais problèmes de performance.
• Certains audits — comme les écouteurs passifs ou les formats d’image nouvelle génération — sont des micro-optimisations. Corrigez d’abord les gros problèmes.
• Lancez Lighthouse trois fois et faites la moyenne des résultats. La performance est variable, et une seule exécution peut être trompeuse.

FAQ

Q : Pourquoi mon score Lighthouse change-t-il chaque fois que je le lance ?
R : Lighthouse mesure la performance dans des conditions variables — la vitesse du réseau, la charge CPU et les heuristiques du navigateur influencent toutes le résultat. Lancez-le trois fois en mode navigation privée et faites la moyenne des scores pour obtenir une base de référence plus stable.

Q : Dois-je optimiser d’abord pour mobile ou pour ordinateur de bureau ?
R : Mobile. Lighthouse utilise par défaut une simulation mobile, car la majeure partie du trafic web est mobile et les appareils mobiles sont plus lents. Si votre score mobile est bon, votre score desktop sera généralement correct.

Q : Mon score Lighthouse est de 95, mais mon site semble toujours lent. Qu’est-ce qui ne va pas ?
R : Lighthouse mesure le chargement de la page, pas l’interactivité après le chargement. Vérifiez votre score INP et utilisez Chrome DevTools Performance panel pour profiler ce qui se passe lorsque les utilisateurs cliquent ou font défiler la page. Vous pourriez avoir un problème JavaScript que Lighthouse ne détecte pas.

Q : Ai-je besoin d’un score parfait de 100 ?
R : Non. Un score de 90+ est excellent. Chercher à atteindre 100 revient souvent à optimiser des choses qui ne comptent pas pour les utilisateurs. Concentrez-vous sur les vraies métriques — LCP, CLS, INP — et ignorez le score.

Q : Puis-je faire confiance à Lighthouse si j’utilise beaucoup de scripts tiers ?
R : Lighthouse signalera les scripts tiers comme un problème, mais il ne peut pas toujours distinguer ceux qui sont nécessaires de ceux qui ne le sont pas. Utilisez les audits « Éviter les charges réseau énormes » et « Réduire le temps d’exécution JavaScript » pour identifier les pires contrevenants, puis décidez s’ils valent la peine d’être conservés.

Sources

• « Lighthouse performance scoring » — Google Developers
• « Core Web Vitals » — web.dev
• « Chrome User Experience Report » — Google Developers
• « WebPageTest Documentation » — WebPageTest.org