Lighthouse : auditer la performance, l'accessibilité et les bonnes pratiques web

Livrer une application web sans mesurer sa qualité, c’est naviguer à l’aveugle. Lighthouse est l’outil d’audit open-source de Google qui évalue n’importe quelle page web sur quatre catégories : performance, accessibilité, bonnes pratiques et conformité progressive web app. Il tourne dans Chrome DevTools, en CLI Node, ou dans un pipeline CI, et renvoie un rapport détaillé avec exactement quoi corriger et pourquoi.

Comment Lighthouse évalue les applications web

Lighthouse charge la page dans un environnement contrôlé, simule un appareil mobile milieu de gamme sur une connexion bridée, et lance des dizaines d’audits. Le score de performance est une moyenne pondérée de six métriques où LCP et TBT ont le plus de poids. Une seule ressource bloquant le rendu ou une image non optimisée peut faire chuter le score de 20 points.

npx lighthouse https://example.com \
  --output=json \
  --output-path=./report.json \
  --chrome-flags="--headless"

La sortie JSON est lisible par les machines, ce qui rend trivial le parsing dans des scripts ou le stockage pour comparaison historique entre déploiements.

Corriger les avertissements les plus courants

Certains problèmes apparaissent sur presque tous les projets React et Next.js. Les scripts tiers sont les pires coupables pour le blocage du rendu. Utiliser next/script avec afterInteractive garantit que les scripts analytics et de tracking ne concurrencent pas le rendu critique.

import Script from 'next/script';

export function Analytics() {
  return <Script src="https://analytics.example.com/script.js" strategy="afterInteractive" />;
}

Les polices web provoquent du layout shift et bloquent le rendu du texte. font-display: swap affiche le texte de fallback immédiatement, et unicode-range limite le téléchargement au jeu de caractères réellement utilisé. Ensemble, ils éliminent la majorité du CLS lié aux polices.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+0000-00FF;
}

Les images non optimisées sont le frein le plus important sur les scores de performance. Le composant next/image gère le lazy loading, le dimensionnement responsive et la conversion de format automatiquement. Servir les images en AVIF et WebP via la config Next.js est l’optimisation à plus fort impact que Lighthouse remonte systématiquement.

const nextConfig: NextConfig = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1200, 1920],
  },
};

Intégrer Lighthouse dans la CI

Lancer Lighthouse manuellement après un déploiement, c’est réactif. L’intégrer dans l’intégration continue permet de capter les régressions avant la production. Google maintient @lhci/cli, un package dédié pour exécuter Lighthouse en environnement CI avec des assertions et des budgets de performance.

jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci && npm run build
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v12
        with:
          urls: |
            http://localhost:3000
            http://localhost:3000/blog
          budgetPath: ./budget.json
          uploadArtifacts: true

Les budgets de performance transforment Lighthouse d’un outil de diagnostic en une barrière qualité. Le build échoue si une page dépasse son budget JavaScript ou rate un seuil de timing. Un bundle de plus de 200 Ko sur mobile est la raison la plus fréquente pour laquelle les applications Next.js passent sous 90.

[
  {
    "path": "/*",
    "timings": [
      { "metric": "interactive", "budget": 3500 },
      { "metric": "first-contentful-paint", "budget": 1800 }
    ],
    "resourceSizes": [
      { "resourceType": "script", "budget": 200 },
      { "resourceType": "image", "budget": 300 }
    ]
  }
]

Audits d’accessibilité pour les développeurs frontend

Le score d’accessibilité de Lighthouse détecte des problèmes qui affectent à la fois les utilisateurs et la qualité du code. Textes alt manquants, hiérarchie de titres cassée, contraste insuffisant et labels de formulaire absents sont signalés avec des références directes au DOM. Lighthouse embarque axe-core sous le capot, donc corriger ses avertissements corrige aussi les tests d’accessibilité automatisés.

Un composant React qui rend un bouton sans label accessible, ou une structure de titres qui saute de h1 à h3, fera échouer l’audit. Ce sont les mêmes problèmes sur lesquels les lecteurs d’écran butent et que des outils comme les tests d’accessibilité de Playwright détectent.

Conclusion

Un seul passage Lighthouse est un instantané. La vraie valeur vient du suivi des tendances à travers les déploiements. La différence entre une équipe qui livre systématiquement des applications web rapides et accessibles et une qui ne le fait pas tient généralement à une chose : elles mesurent. Lancez-le sur chaque pull request, imposez des budgets, et traitez les baisses de score comme des tests qui échouent.