Audit Lighthouse : la méthode complète qu'on applique en agence

01Le score Lighthouse n'est qu'une vue partielle

Avant d'attaquer, un point clé : Lighthouse mesure en conditions LAB (Chromium headless, throttling simulé, machine de référence). Les vraies données qui comptent pour Google SEO viennent du FIELD : Chrome User Experience Report (CrUX), accessible via Search Console > Web Vitals ou PageSpeed Insights. Lighthouse est un excellent outil de diagnostic, mais un score Lighthouse à 100 sur un site lent en réalité ne sert à rien — et un score lab à 70 mais avec CrUX au vert suffit largement. Toujours valider lab + field.

02Site à 30-50 : urgence performance

Le plus probable sur ce score : images non optimisées (JPG/PNG énormes, pas de WebP), JavaScript énorme (souvent 1-3 MB de scripts tiers), render-blocking CSS, hébergement lent. Trois quick wins qui remontent souvent le score à 70+ en quelques jours : 1) Convertir TOUTES les images en WebP/AVIF avec next/image ou ShortPixel sur WordPress. 2) Code splitting agressif (dynamic imports sur les composants lourds, lazy loading des images below-fold). 3) Minification + Brotli + cache long sur le CDN. Bonus : virer les scripts tiers non critiques (analytics auxiliaires, A/B tests dormants, anciens widgets). Sur les sites WordPress, c'est souvent virer 5-10 plugins inutiles qui apporte le plus.

03Site à 50-75 : nettoyage des dépendances

On entre dans le détail. Auditer le bundle JavaScript avec @next/bundle-analyzer pour Next.js ou webpack-bundle-analyzer ailleurs : identifier les dépendances surdimensionnées (Moment.js → date-fns ou dayjs, Lodash entier → import par fonction, Charts.js complet → import dynamique), libs anciennes qui pourraient être natives (Polyfills inutiles en 2026). Traiter le CLS (Cumulative Layout Shift) : réserver l'espace pour les images (width/height obligatoires sur next/image), pour les fonts (font-display: swap + preload), pour les bannières publicitaires (taille fixe en CSS). À ce stade, on optimise aussi les requêtes réseau : préchargement des ressources critiques (rel=preload sur fonts, images LCP, scripts critiques).

// Analyse du bundle Next.js
// next.config.ts
import bundleAnalyzer from '@next/bundle-analyzer'

const withBundleAnalyzer = bundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
})

export default withBundleAnalyzer({
  // votre config Next existante
})

// Usage : ANALYZE=true npm run build
// Ouvre 2 onglets : client + server bundles
// Cliquez sur les gros blocs pour identifier les "fat" dépendances

04Site à 75-90 : optimisation fine

Préload des polices critiques avec rel=preload + crossorigin, priorité des images above-the-fold (priority sur next/image, fetchpriority="high" sur les LCP candidates), lazy loading agressif sur le below-fold, font-display: swap obligatoire, optimisation des Core Web Vitals (LCP, INP, CLS) au cas par cas. À ce stade, on monitorse aussi les scripts tiers : Google Analytics 4 charge mieux que Universal Analytics, mais reste lourd. Plausible Analytics est plus léger (~3 KB vs ~50 KB pour GA4). Pour les chat widgets (Crisp, Intercom), différer le chargement avec setTimeout 3-5s post-load. C'est là qu'on gagne 5-10 points sans renoncer aux features.

05Site à 90+ : maintenance et CI

Le score est bon. L'enjeu devient de ne pas régresser à la prochaine feature développée. Mettre en place : 1) Lighthouse CI en GitHub Actions, qui s'exécute sur chaque pull request et bloque le merge si un score baisse. 2) Vercel Speed Insights ou Sentry Performance pour le monitoring continu (vraies données utilisateurs, pas lab). 3) Audit trimestriel manuel pour vérifier que les chiffres CrUX restent au vert dans Search Console. 4) Process de revue avant chaque déploiement majeur : passer en revue les nouvelles dépendances ajoutées (npm ls --depth=0 + bundle analyzer). C'est de la gestion de patrimoine technique.

# .github/workflows/lighthouse.yml
name: Lighthouse CI
on: pull_request
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22, cache: npm }
      - run: npm ci && npm run build && npm start &
      - run: npx lhci autorun
        env: { LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_TOKEN }} }

06Au-delà du Performance score : Accessibility, Best Practices, SEO

Le score Performance est le plus surveillé, mais les 3 autres scores Lighthouse comptent aussi. Accessibility : viser 95+ — contrast ratio AA, alt sur toutes les images, labels sur tous les inputs, hierarchy hX correcte. Best Practices : 90+ — HTTPS obligatoire, pas d'erreurs console en prod, images en bonnes dimensions natives. SEO : 95-100 facile à atteindre — meta description présente, robots.txt OK, structured data valide, mobile-friendly. Sur les nouveaux sites Krealabs, on vise systématiquement 95+ sur les 4 scores en condition lab, et CrUX au vert sur 90+% des pages.

07Outils complémentaires pour aller plus loin

Lighthouse n'est pas le seul outil de mesure. WebPageTest (webpagetest.org) donne un waterfall ultra-détaillé : on voit chaque requête réseau, son timing, sa priorité. Idéal pour identifier les ressources bloquantes critiques. Chrome DevTools > Performance : profiling JS détaillé pour identifier les long tasks (>50ms) qui plombent l'INP. Chrome DevTools > Coverage : montre le % de CSS/JS non utilisés (à supprimer). Vercel Speed Insights : vraies données utilisateurs sur les sites déployés sur Vercel. Sentry Performance : RUM (Real User Monitoring) cross-stack. Pour les audits sérieux chez Krealabs, on combine ces 4-5 outils, pas seulement Lighthouse.

08Pièges classiques d'audit Lighthouse

1) Auditer en mobile sur sa machine de dev pleine puissance : utiliser le throttling mobile + slow 4G en simulation, sinon scores trompeurs. 2) Auditer la home seulement : auditer aussi les pages internes (catégorie, fiche produit, blog), souvent moins optimisées. 3) Optimiser pour le score lab sans valider en field : on a vu des sites passer de 60 à 95 en lab mais sans amélioration réelle pour les utilisateurs (faux gains). 4) Ne pas re-tester après chaque optimisation : tester APRÈS chaque changement, mesurer l'impact, ne pas tout faire en aveugle. 5) Ignorer les warnings non-bloquants Lighthouse : ils signalent souvent des problèmes futurs.