Score de performance Lighthouse

Ce que vérifie ce contrôle

Appelle l’API PageSpeed Insights pour l’URL de la page et rapporte le score global de performance (0–100). Le score est une moyenne pondérée de cinq métriques labo : First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift et Speed Index.

Pourquoi c’est important

La performance est un facteur de classement confirmé via les Core Web Vitals et un facteur de conversion confirmé par toutes les études de conversion publiées. Le score Lighthouse est le chiffre unique le plus simple à suivre — Google lui-même le regroupe en trois plages :

90–100 (vert) — rapide. Cible à atteindre.
50–89 (orange) — à améliorer.
0–49 (rouge) — lent. Vous perdez probablement des classements et des conversions.

Une page à 30 n’est pas légèrement pire qu’une page à 80 ; elle perd des visiteurs avant qu’ils ne voient quoi que ce soit.

Comment corriger

Le travail de performance se fait par couches. Attaquez les plus gros contributeurs en premier :

1. Optimisez les plus grosses images (LCP).

La plupart des pages lentes le sont à cause d’une image héros pesant 2 à 5 Mo. Compressez-la, servez-la en AVIF/WebP, définissez explicitement width et height :

<img
  src="/hero.avif"
  width="1200"
  height="630"
  alt="…"
  fetchpriority="high"
  loading="eager">

fetchpriority="high" indique au navigateur de télécharger cette image avant les actifs non critiques — améliore directement le LCP.

2. Différez le JavaScript non critique (TBT et INP).

Chaque script d’analytics, widget de chat et test A/B s’exécute sur le thread principal avant que l’utilisateur puisse interagir. Reportez-les en defer ou async :

<script src="/analytics.js" defer></script>
<script src="https://plausible.io/js/plausible.js" defer></script>

Pour React/Next.js : code-splittez les composants lourds, utilisez dynamic(() => import(...), { ssr: false }) pour les widgets sous la ligne de flottaison, et auditez les scripts tiers dans l’onglet Performance des DevTools.

3. Inlinez le CSS critique, différez le reste.

<style>/* CSS critique — visible au-dessus de la ligne de flottaison */</style>
<link rel="preload" href="/main.css" as="style" onload="this.rel='stylesheet'">

Les extracteurs de CSS critique (Critters, Beasties pour Next.js, astro:assets pour Astro) automatisent cela.

4. Réservez l’espace pour le contenu dynamique (CLS).

Chaque image a besoin de width et height. Chaque embed a besoin d’un conteneur explicite. Chaque police web a besoin de font-display: swap et d’une police de secours aux métriques voisines.

5. Cache, compression, CDN.

Servez les actifs statiques depuis un CDN (Cloudflare, Bunny, Fastly). Activez la compression Brotli sur HTML/CSS/JS. Définissez Cache-Control: public, max-age=31536000, immutable sur les actifs avec empreinte.

Outils à utiliser :

PageSpeed Insights — même moteur que MetricSpot appelle. Affiche les échecs d’audit spécifiques.
Chrome DevTools → panneau Performance — trouvez la vraie frame lente.
npx unlighthouse https://votredomaine.com — Lighthouse sur chaque page, pas seulement la page d’accueil.
WebPageTest — pour tester depuis des géographies et types de connexion spécifiques.

Contrôles connexes : LCP, INP, CLS.

Questions fréquentes

Pourquoi mon score Lighthouse local diffère-t-il de PSI ?

Lighthouse local utilise votre CPU et votre réseau ; PSI utilise un appareil Android moyen-gamme bridé sur connexion 4G. PSI est ce que Google utilise pour le signal réel — calez-vous toujours sur ça, pas sur le score de votre MacBook M3.

Le score affecte-t-il directement le classement ?

Indirectement. Google classe sur les trois Core Web Vitals (LCP, INP, CLS) — pas sur le score composite. Mais un faible score Lighthouse signifie presque toujours que les CWV sous-jacents sont aussi mauvais. Corrigez les métriques ; le score suit.

Mon score varie d’une visite à l’autre, pourquoi ?

Les données terrain (ce que PSI affiche quand l’URL a assez de trafic d’utilisateurs Chrome) sont stables. Les données labo (un seul run Lighthouse) sont variables — serveur chaud/froid, réseaux pub chargeant des créations différentes, scripts tiers. Lancez PSI trois fois et prenez la médiane, ou reposez-vous sur les données terrain sur 28 jours quand disponibles.