Audit de performance frontend avec Lighthouse

Lighthouse est l'outil d'audit open source de Google qui note automatiquement une page web sur la performance, l'accessibilité, les bonnes pratiques et le SEO. Pourtant, la plupart des gens jettent un œil à ce score rond de performance et paniquent. Le score n'est qu'un résumé de la véritable histoire. Dans cet article, je vous montre comment lire réellement le rapport, quelles métriques façonnent vraiment l'expérience utilisateur, et comment corriger les goulots d'étranglement que vous identifiez, étape par étape.

Comment exécuter un rapport Lighthouse

Il existe plusieurs façons d'accéder à Lighthouse ; le bon réflexe est de choisir celle qui correspond à votre cas d'usage :

• Chrome DevTools > onglet Lighthouse : rapide, visuel et exécuté en local. Le hic, c'est que le CPU et le réseau de votre machine influencent le résultat.
• PageSpeed Insights (pagespeed.web.dev) : utilise le même moteur mais tourne sur les serveurs de Google et affiche aussi les données des vrais utilisateurs (CrUX / Field Data).
• CLI : idéal pour l'automatisation. La commande npx lighthouse https://aslain.dev --view génère le rapport et l'ouvre dans le navigateur.

Un point essentiel : mesurez toujours en fenêtre de navigation privée, extensions désactivées. Les bloqueurs de pub et autres modules injectent du code dans la page et faussent le score. Ne vous fiez pas non plus à une seule mesure ; la performance est variable, lancez-la 3 à 5 fois et regardez la médiane.

Données de laboratoire ou données de terrain ?

Lighthouse propose deux types de données, et les confondre est l'erreur la plus courante. Les données de laboratoire (DevTools/Lighthouse) mesurent un seul chargement dans un environnement contrôlé et simulé ; c'est reproductible mais artificiel. Les données de terrain (Core Web Vitals) sont des mesures anonymisées collectées depuis Chrome auprès des utilisateurs qui ont réellement visité votre site au cours des 28 derniers jours. C'est ce que Google prend en compte pour le classement. Donc même si votre score de labo est de 100, de mauvaises données de terrain signifient que le vrai problème n'est pas résolu.

Quelles métriques comptent : LCP, CLS et TBT

Le score de performance est une moyenne pondérée ; ces métriques contribuent le plus :

• LCP (Largest Contentful Paint) : le temps de rendu du plus grand élément visible (souvent l'image hero ou le titre). Objectif : moins de 2,5 s.
• CLS (Cumulative Layout Shift) : le déplacement inattendu d'éléments pendant le chargement. Objectif : moins de 0,1.
• TBT (Total Blocking Time) : le temps durant lequel le thread principal est bloqué par le JavaScript et indisponible à l'interaction. Son équivalent terrain est l'INP. Objectif : moins de 200 ms.
• FCP et Speed Index : la vitesse du premier contenu et du remplissage visuel.

Lisez la couleur à côté de chaque métrique (vert/orange/rouge) avec les sections « Opportunities » et « Diagnostics ». Ce sont ces éléments, et non le score lui-même, qui vous disent quoi faire.

Corriger le goulot LCP

Le LCP provient généralement d'une grande image ou d'une police web chargée trop tard. Étapes pratiques :

• Convertissez l'image hero dans un format moderne (WebP/AVIF) et servez-la à la bonne taille. N'envoyez pas une image de 3000px de large dans un emplacement de 800px.
• Donnez un indice au navigateur pour qu'il découvre tôt l'image critique :

<link rel="preload" as="image"
      href="/img/hero.avif"
      fetchpriority="high">

Pour les polices, utilisez font-display: swap afin que le texte ne reste pas invisible pendant le téléchargement. Le temps de réponse serveur (TTFB) affecte aussi directement le LCP ; mettez en cache les requêtes lourdes et utilisez un CDN si possible. Ces quelques points ont en général un fort impact, mais l'ordre varie selon le site — ouvrez l'élément LCP que le rapport pointe et trouvez la vraie cause.

Réduire le CLS et le TBT

Pour le CLS, la règle d'or : réservez l'espace de chaque élément dès le départ. Ajoutez les attributs width et height aux images (le navigateur calcule le ratio et réserve la place), donnez une hauteur fixe aux emplacements pub/embed, et évitez les bannières tardives qui poussent le contenu vers le bas. Pour limiter le décalage dû aux polices web, size-adjust et une police de repli ajustée aident.

Le TBT est presque toujours une surcharge de JavaScript. À faire :

• Éliminez le JS inutilisé ; prenez au sérieux l'avertissement « Reduce unused JavaScript ».
• Chargez les scripts tiers (analytics, chat, pub) avec async ou defer, et différez-les après l'interaction quand c'est possible.
• Découpez les gros bundles avec le code splitting ; n'envoyez que le code nécessaire à chaque page.

<script src="/js/app.js" defer></script>
<script src="https://analytics.example.com/s.js" async></script>

Transformer l'audit en habitude

La performance n'est pas une tâche ponctuelle ; chaque déploiement peut introduire une nouvelle image ou un script qui provoque une régression. Ajoutez donc Lighthouse à votre pipeline CI. Avec Lighthouse CI, vous pouvez définir des budgets sur chaque pull request et casser le build si le score chute. Ainsi, « pourquoi le site est-il devenu plus lent ? » trouve sa réponse lors de la revue de code, avant qu'un utilisateur ne se plaigne. Plutôt que de courir après le score, courez après l'utilisateur : testez sur de vrais appareils, dans de vraies conditions réseau.

Questions fréquentes

Pourquoi mon score Lighthouse change-t-il à chaque fois ?

Parce que la mesure de laboratoire est affectée par la charge CPU du moment, les conditions réseau et les processus en arrière-plan. C'est pourquoi prendre 3 à 5 mesures en navigation privée et utiliser la médiane est bien plus sain que de se fier à un seul score.

Dois-je absolument atteindre 100 ?

Non. 100 est un bel objectif, mais ce qui compte vraiment, c'est de passer les seuils des Core Web Vitals (LCP < 2,5 s, CLS < 0,1, INP < 200 ms) dans les données de terrain. Un site à 92 avec de « bonnes » données de terrain vaut mieux qu'un site à 99 avec de mauvaises données de terrain.

Pourquoi les scores mobile et bureau sont-ils si différents ?

Lighthouse simule un appareil lent et un réseau bridé dans le test mobile. Comme la plupart de vos utilisateurs viennent du mobile, il faut améliorer le score mobile en priorité.

Envie de prendre la performance de votre site au sérieux ? Nous pouvons lire votre rapport Lighthouse ensemble et corriger durablement les goulots LCP, CLS et TBT. Contactez-moi et lançons l'analyse de vitesse de votre site.