Score Lighthouse 90+ : comment j’optimise chaque projet React pour la performance

Introduction

Un score Lighthouse n’est pas une métrique de vanité.

C’est une mesure directe de l’expérience réelle de vos utilisateurs. Chaque point sous 90 sur mobile correspond à un visiteur qui attend trop, à une page qui bouge de façon inattendue, ou à une interaction qui paraît lente.

Chez Dywan Dev, j’optimise chaque projet pour dépasser 90 sur Lighthouse en Performance, Accessibilité, Bonnes pratiques et SEO. Pas parce que les clients le demandent — la plupart ne savent pas ce qu’est Lighthouse — mais parce qu’ignorer ces sujets a un coût concret.

Ce guide documente exactement ma méthode : les décisions, configurations et patterns appliqués avant chaque mise en production React.

1. Comprendre ce que Lighthouse mesure réellement

Lighthouse mesure cinq catégories :

Performance : vitesse de chargement et rapidité d’interaction
Accessibilité : usage au clavier, lecteurs d’écran, contraste, HTML sémantique
Bonnes pratiques : HTTPS, APIs non dépréciées, erreurs console, ratios d’images
SEO : crawlabilité, metas, structure, adaptation mobile
PWA : conformité Progressive Web App

Les métriques Core Web Vitals clés pour la performance :

LCP (25%) < 2,5s, TBT (30%) < 200ms, CLS (15%) < 0,1, FCP (10%) < 1,8s, SI (10%) < 3,4s.

TBT a le poids le plus fort : réduire le JavaScript bloquant est le levier principal.

2. Workflow d’audit

Ne testez jamais en mode dev. Auditez toujours un build production :

npm run build
npm run preview

Exécutez Lighthouse en navigation privée, 3 fois, puis gardez la médiane.

Ajoutez Lighthouse CI :

npm install -D @lhci/cli

module.exports = {
  ci: {
    collect: { staticDistDir: './dist', numberOfRuns: 3 },
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.9 }],
        'categories:accessibility': ['error', { minScore: 0.9 }],
        'categories:best-practices': ['error', { minScore: 0.9 }],
        'categories:seo': ['error', { minScore: 0.9 }]
      }
    }
  }
};

3. Optimisation du bundle JavaScript — impact maximal

Analysez d’abord le bundle :

npm install -D rollup-plugin-visualizer

import { visualizer } from 'rollup-plugin-visualizer';
// ... plugin dans vite.config.js ...

Appliquez un découpage manuel des chunks vendors :

manualChunks: {
  'react-vendor': ['react', 'react-dom'],
  'router': ['react-router-dom'],
  'animation': ['framer-motion'],
  'i18n': ['i18next', 'react-i18next'],
  'ui': ['@headlessui/react']
}

Remplacez les libs lourdes par des alternatives légères et importez de manière ciblée.

4. Code splitting par route

Chaque page doit être chargée à la demande via lazy + Suspense. Un visiteur sur la home ne doit pas télécharger le code admin/blog/contact inutilement.

5. Optimisation des images — levier LCP

LCP est souvent dominé par l’image hero.

Convertissez en WebP/AVIF, utilisez des images responsives avec srcset, préchargez l’image hero, et définissez toujours width/height.

Pour les images hors écran : loading="lazy" + decoding="async".

6. Optimisation des polices

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

Utilisez display=swap et ajustez la fallback avec size-adjust pour limiter le CLS. Sur les projets critiques, préférez l’hébergement local des fonts.

7. Éliminer le CLS

Sources fréquentes : images sans dimensions, contenu injecté tardivement, webfonts, embeds sans taille, animations de layout.

Animez transform et opacity, pas width/height/margin/padding.

8. Accessibilité — le score souvent négligé

Un score accessibilité < 90 signifie que des utilisateurs réels ne peuvent pas utiliser votre produit correctement.

Checklist minimale : alt text correct, labels de formulaires, contraste WCAG AA, navigation clavier, labels ARIA pour boutons icône-only, lien “Skip to content”.

9. SEO dans React

Si SSR complet non disponible, pré-rendez les routes importantes à build time. Sinon, gérez rigoureusement le head (title, description, OG, Twitter, canonical) page par page.

Ajoutez des données structurées JSON-LD pour les businesses locaux.

10. Checklist pré-déploiement

Bundle analysé, dépendances lourdes justifiées
Hero prioritaire, images correctement dimensionnées
Code splitting + chunks vendors en place
Fonts optimisées (swap, preconnect, fallback ajustée)
Accessibilité validée (labels, ARIA, clavier, contraste)
SEO complet (meta, OG/Twitter, données structurées, canonical, sitemap)
3 audits Lighthouse sur build prod, médiane > 90

Conclusion

Un Lighthouse 90+ n’arrive jamais par hasard. C’est le résultat de décisions répétées avec discipline sur le bundle, les images, les fonts, l’accessibilité et le SEO.

Ce qui sépare un développeur qui “livre” d’un développeur qui “livre et performe”, c’est la constance de ce standard.

Chez Dywan Dev, 90+ Lighthouse est le minimum sur chaque projet. Performance, accessibilité et SEO ne sont pas des options. Si vous voulez un produit web construit avec ces standards, construisons-le ensemble.