Audit Lighthouse : analyser et corriger les problèmes de performance

Qu’est-ce que Lighthouse et pourquoi l’utiliser ?

Lighthouse est un outil open source développé par Google. Il simule le chargement d’une page dans un environnement contrôlé (données de laboratoire) et produit un rapport détaillé couvrant cinq catégories : performance, accessibilité, bonnes pratiques, SEO et Progressive Web App. Contrairement à PageSpeed Insights, qui combine données terrain (CrUX) et données labo, Lighthouse ne travaille qu’avec des données de laboratoire.

Après douze ans de développement web freelance, je considère Lighthouse comme le point de départ de toute optimisation sérieuse. Pas parce que le score est une fin en soi, mais parce que le rapport pointe directement vers les corrections prioritaires. Un client m’a récemment envoyé un site e-commerce avec un score de 28 en performance. En deux jours d’optimisation guidée par Lighthouse, nous sommes passés à 84. Le rapport avait identifié trois images non compressées de 4 Mo chacune et un bundle JavaScript de 1,2 Mo chargé de manière synchrone.

L’outil est gratuit, accessible à tous, et ne nécessite aucune installation supplémentaire si vous utilisez Chrome. C’est la première étape que je recommande à chaque client avant de parler de stratégie SEO ou de refonte.

Comment lancer un audit Lighthouse : trois méthodes

Il existe trois façons d’exécuter un audit. Chacune a ses avantages selon votre contexte.

Méthode 1 : Chrome DevTools (la plus courante)

Ouvrez Chrome, accédez à la page cible, puis appuyez sur F12 (ou Ctrl+Shift+I). Cliquez sur l’onglet Lighthouse dans le panneau DevTools. Sélectionnez les catégories à auditer, choisissez « Mobile » ou « Desktop », puis cliquez sur « Analyser le chargement de la page ». Le rapport s’affiche en 15 à 45 secondes selon la complexité du site.

Méthode 2 : PageSpeed Insights (données terrain + labo)

Rendez-vous sur pagespeed.web.dev, collez l’URL et lancez l’analyse. L’avantage : vous obtenez à la fois le rapport Lighthouse (données labo) et les données CrUX (données terrain issues d’utilisateurs réels Chrome). C’est la méthode que je privilégie pour auditer les Core Web Vitals en conditions réelles.

Méthode 3 : Lighthouse CLI (automatisation)

Pour les développeurs, la ligne de commande offre le plus de contrôle. Installez le package npm (npm install -g lighthouse), puis exécutez lighthouse https://votre-site.fr --output html --output-path rapport.html. Cette méthode est idéale pour intégrer les audits dans un pipeline CI/CD ou pour auditer plusieurs pages automatiquement.

Méthode	Données	Avantage principal	Inconvénient
Chrome DevTools	Labo uniquement	Immédiat, sans installation	Sensible aux extensions Chrome actives
PageSpeed Insights	Labo + terrain (CrUX)	Données réelles + rapport Lighthouse	Requiert du trafic CrUX suffisant
Lighthouse CLI	Labo uniquement	Automatisable, reproductible	Nécessite Node.js
WebPageTest	Labo (Lighthouse intégré)	Tests multi-localisations	Interface plus complexe

Les cinq métriques de performance et leurs poids

Depuis Lighthouse 10, le score de performance repose sur cinq métriques pondérées. Comprendre le poids de chacune est essentiel pour prioriser vos corrections. Inutile de passer trois jours sur le Speed Index (10 %) si votre Total Blocking Time (30 %) est catastrophique.

Métrique	Abréviation	Poids	Seuil « bon »	Seuil « mauvais »	Ce qu’elle mesure
Total Blocking Time	TBT	30 %	< 200 ms	> 600 ms	Temps total pendant lequel le thread principal est bloqué par du JavaScript
Largest Contentful Paint	LCP	25 %	< 2,5 s	> 4 s	Temps d’affichage du plus grand élément visible (image, bloc de texte)
Cumulative Layout Shift	CLS	25 %	< 0,1	> 0,25	Stabilité visuelle : décalages inattendus des éléments de la page
First Contentful Paint	FCP	10 %	< 1,8 s	> 3 s	Premier rendu visible (texte, image, SVG)
Speed Index	SI	10 %	< 3,4 s	> 5,8 s	Vitesse à laquelle le contenu visible se remplit progressivement

Le score global utilise une distribution log-normale : le 25e percentile des données HTTP Archive correspond à un score de 50, et le 8e percentile à un score de 90 (vert). Atteindre un score parfait de 100 est extrêmement difficile et n’est pas un objectif réaliste pour la plupart des sites.

Un point que beaucoup de développeurs ignorent : le TBT est le proxy labo du INP (Interaction to Next Paint), la métrique Core Web Vitals qui mesure la réactivité. Optimiser le TBT améliore directement l’expérience utilisateur en production.

Comment interpréter le rapport Lighthouse

Le rapport Lighthouse se divise en trois sections principales après le résumé des scores.

Opportunities (Opportunités)

Cette section liste les optimisations concrètes avec une estimation du gain potentiel en secondes. Chaque recommandation est classée par impact décroissant. Exemples typiques :

• Serve images in next-gen formats : passer au WebP ou AVIF au lieu du JPEG/PNG
• Eliminate render-blocking resources : différer le CSS et le JavaScript non critiques
• Properly size images : redimensionner les images à la taille d’affichage réelle
• Reduce unused JavaScript : supprimer le code mort ou le charger en lazy

Diagnostics

Des informations complémentaires qui n’affectent pas directement le score mais signalent des problèmes potentiels : taille du DOM, nombre de requêtes, utilisation du cache navigateur, temps de réponse serveur (TTFB).

Passed Audits (Audits réussis)

La liste des tests réussis. Utile pour vérifier que vos optimisations précédentes sont toujours en place.

Les sept erreurs de performance les plus fréquentes

Après des centaines d’audits Lighthouse réalisés pour mes clients, voici les problèmes que je retrouve le plus souvent, classés par fréquence.

1. Images non optimisées (présentes dans 80 % des audits)

C’est le problème numéro un. Des images JPEG de 3 à 5 Mo servies sans compression, sans redimensionnement, sans format moderne. La correction est simple : convertir en WebP, redimensionner à la taille d’affichage, activer le lazy loading. Sur WordPress, un plugin comme EWWW ou ShortPixel automatise le processus. Pour aller plus loin, consultez mon guide sur l’optimisation des images web.

2. JavaScript render-blocking (70 % des audits)

Des scripts chargés dans le <head> sans attribut defer ou async bloquent le rendu de la page. Chaque script synchrone retarde le FCP et augmente le TBT. La solution : ajouter defer à tous les scripts non critiques, et déplacer le JavaScript en bas de page quand c’est possible. Pour le CSS critique, extraire les styles above-the-fold et différer le reste.

3. Absence de mise en cache navigateur (65 % des audits)

Sans en-têtes Cache-Control correctement configurés, chaque visite recharge tous les assets. Configurez un max-age d’au moins un an pour les fichiers statiques (CSS, JS, images) avec un hash de version dans le nom de fichier. Sur Nginx, c’est une directive expires dans le bloc location.

4. CSS non critique chargé de manière synchrone (55 % des audits)

Charger l’intégralité de votre fichier CSS avant le premier rendu retarde le FCP. La technique : extraire le CSS critique (above-the-fold) en inline dans le <head>, puis charger le reste en asynchrone via rel="preload" et onload. Des outils comme Critical ou Critters automatisent cette extraction.

5. Polices web non optimisées (50 % des audits)

Les Google Fonts chargées sans font-display: swap provoquent un flash de texte invisible (FOIT). Ajoutez &display=swap à l’URL des Google Fonts, utilisez preconnect vers les domaines fonts.googleapis.com et fonts.gstatic.com, et limitez-vous à deux familles de polices maximum.

6. DOM trop volumineux (40 % des audits)

Un DOM dépassant 1 500 nœuds ralentit les recalculs de style et le layout. Les constructeurs de pages (Elementor, Divi) sont souvent responsables avec leurs dizaines de <div> imbriquées. Sur mes projets, j’utilise GeneratePress avec du HTML propre : le DOM dépasse rarement 800 nœuds.

7. TTFB élevé (35 % des audits)

Un Time To First Byte supérieur à 600 ms indique un problème côté serveur : hébergement mutualisé saturé, absence de cache serveur, requêtes SQL lentes. La solution passe par un hébergeur performant, un cache FastCGI (Nginx) ou un cache objet (Redis), et l’optimisation des requêtes de base de données.

Plan d’action : corriger les problèmes étape par étape

Voici la méthode que j’applique systématiquement après un audit Lighthouse. L’ordre est important : on commence par les corrections à fort impact et faible effort.

Étape 1 : les images (gain immédiat, effort minimal)

Convertissez toutes les images en WebP ou AVIF. Redimensionnez-les à la taille d’affichage réelle (pas une image 4000px affichée en 800px). Ajoutez loading="lazy" à toutes les images sauf la première visible (LCP). Ajoutez les attributs width et height pour éviter les décalages de mise en page (CLS). Vous pouvez utiliser notre compresseur d’images en ligne pour un traitement rapide.

Étape 2 : le JavaScript (gain moyen à fort)

Auditez vos scripts avec l’onglet Coverage de Chrome DevTools. Identifiez le code non utilisé et supprimez-le. Ajoutez defer aux scripts restants. Si vous utilisez des bibliothèques tierces (analytics, chat, réseaux sociaux), chargez-les après le DOMContentLoaded. Pensez à minifier votre CSS pour réduire le poids total.

Étape 3 : le cache et la compression

Activez la compression Gzip ou Brotli sur votre serveur. Configurez les en-têtes Cache-Control avec des durées longues pour les assets statiques. Vérifiez que votre serveur envoie bien les en-têtes ETag pour la validation conditionnelle.

Étape 4 : le CSS critique

Extrayez le CSS above-the-fold et injectez-le en inline. Chargez le reste en asynchrone. Si vous utilisez un framework CSS (Tailwind, Bootstrap), purgez les classes inutilisées avec PurgeCSS ou la configuration native de Tailwind.

Étape 5 : les polices et le serveur

Optimisez le chargement des polices (preconnect, swap). Si le TTFB reste élevé après les optimisations front-end, passez à un meilleur hébergement ou ajoutez un cache serveur.

Pourquoi vos scores Lighthouse varient d’un test à l’autre

C’est la question que me posent le plus souvent mes clients : « J’avais 92 hier, aujourd’hui j’ai 78, qu’est-ce qui s’est passé ? » La réponse est simple : Lighthouse utilise des données de laboratoire, et l’environnement de test n’est jamais parfaitement identique.

Plusieurs facteurs expliquent cette variabilité :

• Extensions Chrome actives : un bloqueur de pub ou un gestionnaire de mots de passe peut injecter du JavaScript et fausser les résultats. Lancez toujours vos audits en mode incognito.
• Charge réseau locale : un téléchargement en arrière-plan ou un réseau Wi-Fi instable affecte les temps de chargement mesurés.
• Charge serveur variable : si votre hébergement est mutualisé, la charge des autres sites sur le même serveur impacte votre TTFB.
• Simulation de throttling : Lighthouse simule un réseau 4G et un CPU ralenti. Cette simulation introduit une variance naturelle.

Ma recommandation : lancez trois à cinq audits consécutifs et prenez la médiane. C’est la méthode la plus fiable. Avec le CLI, vous pouvez automatiser cette série et obtenir des résultats reproductibles.

Lighthouse face aux alternatives : quel outil choisir ?

Lighthouse n’est pas le seul outil d’audit de performance. Voici comment il se positionne face aux principales alternatives.

Outil	Type de données	Gratuit	Automatisable	Point fort	Limite
Lighthouse	Labo	Oui	Oui (CLI)	Intégré à Chrome, rapport complet	Données labo uniquement
PageSpeed Insights	Labo + terrain	Oui	Oui (API)	Données CrUX réelles	Nécessite du trafic Chrome
WebPageTest	Labo	Oui (limité)	Oui (API)	Multi-localisations, filmstrip	Interface complexe
GTmetrix	Labo	Oui (limité)	Oui (API payante)	Historique des tests	Serveurs uniquement en Amérique du Nord (gratuit)
Chrome UX Report	Terrain	Oui	Oui (BigQuery)	Données réelles à grande échelle	Pas de recommandations

Mon approche : j’utilise Lighthouse via DevTools pour le développement quotidien, PageSpeed Insights pour les rapports clients (les données terrain sont plus parlantes), et WebPageTest pour les diagnostics avancés quand je dois analyser un waterfall en détail. Pour un diagnostic rapide, PageSpeed Insights reste le meilleur compromis.

Automatiser vos audits Lighthouse en CI/CD

Lancer un audit manuellement est utile pour le diagnostic initial. Mais pour maintenir la performance dans le temps, l’automatisation est indispensable. Voici comment intégrer Lighthouse dans votre workflow de développement.

Avec GitHub Actions

L’action treosh/lighthouse-ci-action permet d’exécuter Lighthouse sur chaque pull request. Définissez des seuils minimaux (par exemple, score performance > 85) et bloquez le merge si le score est insuffisant. C’est la méthode la plus efficace pour empêcher les régressions de performance.

Avec Lighthouse CI (LHCI)

Google propose Lighthouse CI, un outil dédié à l’intégration continue. Il permet de stocker l’historique des scores, de comparer les résultats entre branches, et de définir des budgets de performance (assertions). Configuration minimale :

{
  "ci": {
    "collect": {
      "url": ["https://votre-site.fr/"],
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.85}],
        "categories:accessibility": ["warn", {"minScore": 0.90}]
      }
    }
  }
}

Monitoring continu

Pour un suivi sans infrastructure, des services comme web.dev/measure ou DebugBear offrent un monitoring automatique avec alertes par email. C’est particulièrement utile pour détecter les régressions après une mise à jour WordPress, un changement de thème ou l’ajout d’un nouveau plugin.

L’automatisation des audits fait partie d’une stratégie globale d’optimisation de la performance web. Sans surveillance continue, les gains obtenus aujourd’hui disparaissent en quelques semaines sous le poids des nouvelles fonctionnalités et mises à jour.

Checklist d’audit Lighthouse : 15 points à vérifier

Voici la checklist que j’utilise pour chaque audit client. Elle couvre les points les plus impactants, classés par priorité.

Conclusion : le score n’est pas une fin, c’est un indicateur

Lighthouse est un outil remarquable, mais il ne faut pas en faire une obsession du score parfait. Un score de 90+ est excellent. Un score de 75 avec une bonne expérience utilisateur réelle vaut mieux qu’un 98 obtenu en supprimant toutes les fonctionnalités utiles du site.

Ce qui compte vraiment, c’est la tendance : vos scores s’améliorent-ils au fil du temps ? Les régressions sont-elles détectées rapidement ? L’automatisation en CI/CD est la meilleure réponse à cette question. Intégrez Lighthouse dans votre workflow, fixez des seuils minimaux, et concentrez votre énergie sur les métriques à fort poids (TBT 30 %, LCP 25 %, CLS 25 %).

Pour aller plus loin, combinez Lighthouse avec les Core Web Vitals (données terrain) et un monitoring continu. C’est la combinaison que j’utilise sur tous mes projets clients, et c’est celle qui produit les meilleurs résultats durables.