Mesurer la performance web avec Lighthouse, PageSpeed Insights et CrUX

Votre site de la coopérative Niani s’affiche vite sur votre ordinateur portable, relié à la fibre, dans votre navigateur. Et pourtant un client à Bobo-Dioulasso, sur un téléphone d’entrée de gamme en 3G, attend cinq secondes devant un écran blanc avant de voir la bannière. Lequel de vous deux a raison ? Les deux — vous ne mesurez simplement pas la même chose. Tant que vous n’avez pas chiffré la performance avec les bons outils, vous optimisez à l’aveugle. Ce tutoriel vous apprend à mesurer la vitesse réelle de vos pages, en laboratoire et chez vos vrais visiteurs, pour savoir exactement quoi corriger.

🎯 Ce que vous allez apprendre

• Distinguer les données de laboratoire des données de terrain, et savoir laquelle fait foi pour le référencement.
• Lancer un audit Lighthouse depuis Chrome et lire chaque section du rapport sans vous noyer.
• Interpréter le rapport CrUX et le fameux 75ᵉ centile qui sert de verdict à Google.
• Automatiser la mesure en ligne de commande pour suivre l’évolution à chaque mise en ligne.
• Collecter les Core Web Vitals chez vos vrais utilisateurs avec la bibliothèque web-vitals.

🛠️ Ce que vous allez construire

Au fil des étapes, vous mettez en place un véritable poste de mesure pour la page d’accueil de Niani : un audit Lighthouse reproductible, la lecture du rapport terrain dans PageSpeed Insights, un script en ligne de commande qui crache un rapport à la demande, et un petit mouchard JavaScript qui remonte les vrais chiffres de vos visiteurs. À la fin, vous ne devinez plus : vous avez des nombres.

Prérequis

• Google Chrome à jour (l’outil Lighthouse y est intégré, version 13 au moment d’écrire).
• Node.js 22 ou 24 LTS si vous voulez la partie ligne de commande (vérifiez avec node -v).
• Une page en ligne à tester — idéalement la page d’accueil de votre projet, accessible publiquement.
• Niveau : débutant accepté. Si vous savez ouvrir les outils de développement du navigateur (touche F12), vous êtes prêt.
• ⏱️ Temps estimé : ~40 minutes.

Étape 1 — Comprendre laboratoire contre terrain (le modèle mental qui change tout)

Avant de cliquer sur quoi que ce soit, il faut comprendre pourquoi deux outils donnent parfois deux scores opposés pour la même page. La mesure de performance se fait selon deux régimes radicalement différents, et confondre les deux est l’erreur numéro un des débutants.

Les données de laboratoire (lab data) sont produites dans un environnement contrôlé : une machine simule un appareil mobile précis, bride le réseau à une vitesse fixe, charge la page une fois et chronomètre. C’est reproductible, idéal pour déboguer, mais c’est une simulation. Lighthouse et l’onglet Performance des outils de développement travaillent ainsi.

Les données de terrain (field data) viennent de vrais utilisateurs, sur leurs vrais téléphones, leurs vraies connexions, partout dans le monde. Google les agrège dans le Chrome User Experience Report (CrUX). Ce sont ces données — et elles seules — qui comptent pour l’évaluation des Core Web Vitals utilisée par la recherche Google.

Retenez la règle d’or : le laboratoire sert à diagnostiquer et à reproduire un problème ; le terrain sert à savoir si vos utilisateurs souffrent vraiment. Une page peut décrocher un 95 en laboratoire et échouer sur le terrain, simplement parce que vos visiteurs réels ont des appareils plus lents que la simulation. C’est exactement le piège du portable-fibre contre le téléphone-3G de l’introduction.

✅ Point d’étape — Vous devez pouvoir répondre à cette question : « Mon score Lighthouse est-il une donnée de laboratoire ou de terrain ? » Réponse : laboratoire. Si c’est clair, continuez.

Étape 2 — Lancer votre premier audit Lighthouse dans Chrome

Lighthouse est l’outil d’audit gratuit intégré à Chrome. Il note votre page sur 100 pour la performance, l’accessibilité, les bonnes pratiques et le référencement. Commençons par l’ouvrir sur la page d’accueil de Niani.

Ouvrez la page en ligne, appuyez sur F12 pour ouvrir les outils de développement, puis cliquez sur l’onglet Lighthouse. Choisissez la catégorie Performance, le mode Navigation, le terminal Mobile, puis lancez l’analyse.

# En ligne de commande, l'équivalent exact se lance ainsi
# (on l'installe à l'étape 5) :
lighthouse https://niani.example --only-categories=performance --form-factor=mobile

Au bout de vingt à trente secondes, vous obtenez un score coloré : vert si au moins 90, orange entre 50 et 89, rouge en dessous de 50. Sous le score, cinq métriques de laboratoire sont détaillées. Trois d’entre elles pèsent l’essentiel de la note : le Largest Contentful Paint (25 %), le Total Blocking Time (30 %) et le Cumulative Layout Shift (25 %) ; le First Contentful Paint et le Speed Index complètent les 20 % restants.

Le Total Blocking Time mérite une note : c’est le substitut de laboratoire de l’interactivité. Comme on ne peut pas simuler un vrai clic d’utilisateur de façon fiable, Lighthouse mesure combien de temps le fil principal reste bloqué par du JavaScript. Un TBT élevé annonce presque toujours un mauvais INP sur le terrain.

Faites défiler jusqu’à la section Diagnostics et Opportunités : Lighthouse y liste, classées par gain estimé, les corrections concrètes — image trop lourde, script bloquant, élément LCP identifié. C’est votre liste de courses.

✅ Point d’étape — Vous avez un score chiffré et une liste d’opportunités. Notez votre LCP, votre TBT et votre CLS : ce sont vos trois chiffres de référence avant optimisation.

Étape 3 — PageSpeed Insights : laboratoire et terrain au même endroit

Lighthouse en local ne voit que le laboratoire. Pour croiser les deux régimes, on utilise PageSpeed Insights, l’outil web de Google qui combine un audit Lighthouse frais et les données CrUX de votre page.

Rendez-vous sur pagespeed.web.dev, collez l’URL de votre page et lancez l’analyse. Le rapport s’ouvre en deux blocs distincts qu’il ne faut surtout pas confondre.

En haut, « Découvrez ce que vivent vos utilisateurs réels » : ce bloc est terrain (CrUX). Il affiche vos trois Core Web Vitals — LCP, INP, CLS — avec un verdict Réussi ou non, agrégé sur les 28 derniers jours. En bas, « Diagnostiquer les problèmes de performance » : ce bloc est laboratoire (Lighthouse), avec le score sur 100 et les opportunités.

Si le bloc terrain affiche « Données insuffisantes », ce n’est pas un bug : votre page ne reçoit pas encore assez de trafic Chrome pour figurer dans CrUX. C’est fréquent pour un site qui démarre, comme la vitrine de Niani à ses débuts. Dans ce cas, le bloc laboratoire et la mesure chez vos propres utilisateurs (étape 6) prennent le relais.

✅ Point d’étape — Vous savez maintenant lire les deux blocs séparément. Si le bloc terrain est vide, ce n’est pas grave : passez par le laboratoire et le suivi maison.

Étape 4 — Décoder CrUX et le 75ᵉ centile

Le bloc terrain ne donne pas une moyenne, et c’est crucial. Google évalue chaque métrique au 75ᵉ centile de vos chargements de page, séparément sur mobile et sur ordinateur. Concrètement : on prend la valeur en dessous de laquelle se situent 75 % de vos visites. Si votre LCP au 75ᵉ centile est de 2,2 secondes, cela signifie que les trois quarts de vos visiteurs ont eu un LCP de 2,2 s ou mieux.

Pourquoi le 75ᵉ centile et pas la moyenne ? Parce que la moyenne masque les utilisateurs en souffrance. Quelques visites très lentes sur un vieux téléphone tireraient la moyenne sans la faire exploser ; le centile, lui, garantit qu’une large majorité d’utilisateurs vit une bonne expérience. C’est une exigence plus honnête.

Les seuils de verdict sont fixes et valables pour les trois métriques au 75ᵉ centile : le LCP est bon à 2,5 secondes ou moins, l’INP est bon à 200 millisecondes ou moins, le CLS est bon à 0,1 ou moins. Une métrique n’est considérée « réussie » par Google que si son 75ᵉ centile reste sous le seuil bon.

Pour aller plus loin que la page testée, le tableau de bord CrUX (gratuit, basé sur Looker Studio) affiche l’évolution mois par mois à l’échelle d’un domaine entier, et la CrUX API permet de récupérer ces chiffres dans vos propres scripts. La Search Console propose aussi un rapport Core Web Vitals qui regroupe vos URL par état (Bon / À améliorer / Médiocre), pratique pour repérer des familles de pages à problème.

✅ Point d’étape — Vous savez ce que veut dire « LCP de 2,4 s au 75ᵉ centile » et pourquoi c’est un bon résultat. Le centile, pas la moyenne : gardez ce réflexe.

Étape 5 — Automatiser la mesure en ligne de commande

Cliquer dans le navigateur à chaque modification devient vite pénible. Pour mesurer de façon reproductible — et plus tard, dans une chaîne d’intégration continue — on installe Lighthouse en ligne de commande. Cela suppose Node.js installé.

# Installation globale via npm
npm install -g lighthouse

# Audit performance, terminal mobile, rapport HTML ouvert automatiquement
lighthouse https://niani.example   --only-categories=performance   --form-factor=mobile   --view

L’option --view ouvre le rapport HTML dès qu’il est prêt. Vous pouvez aussi produire un fichier JSON exploitable par un script avec --output=json --output-path=./rapport.json, puis comparer deux rapports avant/après une optimisation.

Un point méthodologique important : lancez toujours plusieurs fois. Le laboratoire comporte une part de variabilité (charge de votre machine, réseau du moment). Trois passages et on retient la valeur médiane — c’est bien plus fiable qu’une mesure unique. Pour un suivi sérieux à chaque déploiement, Lighthouse CI automatise exactement cela et bloque une mise en ligne qui ferait régresser le score.

✅ Point d’étape — Vous pouvez générer un rapport depuis le terminal et le rejouer à l’identique. Lancez-le trois fois sur la page Niani et notez la médiane du LCP.

Étape 6 — Mesurer chez vos vrais utilisateurs avec web-vitals

Tant que CrUX manque de données, ou si vous voulez vos propres chiffres en temps réel, vous pouvez instrumenter votre page avec la bibliothèque officielle web-vitals (version 5 au moment d’écrire). Elle mesure les Core Web Vitals dans le navigateur de chaque visiteur et vous laisse les envoyer où vous voulez.

// chargé via un CDN, sans build, directement dans une balise module
import { onLCP, onINP, onCLS } from 'https://unpkg.com/web-vitals@5?module';

function envoyer(metric) {
  // metric.name vaut 'LCP', 'INP' ou 'CLS' ; metric.value est la mesure
  const corps = JSON.stringify({ nom: metric.name, valeur: metric.value, page: location.pathname });
  navigator.sendBeacon('/collecte-vitals', corps);
}

onLCP(envoyer);
onINP(envoyer);
onCLS(envoyer);

Trois choses à comprendre dans ce code. D’abord, onINP et onCLS ne se déclenchent pas au chargement mais quand l’utilisateur interagit ou quitte la page : ces métriques s’accumulent pendant toute la visite. Ensuite, navigator.sendBeacon envoie les données même au moment où l’utilisateur ferme l’onglet, sans ralentir la navigation. Enfin, pour diagnostiquer la cause d’une mauvaise valeur, importez depuis web-vitals/attribution : chaque mesure arrive alors avec l’élément exact responsable.

Côté serveur, il vous reste à recevoir ces relevés sur la route /collecte-vitals et à les stocker. Même une simple table avec nom, valeur et date vous donne, en quelques jours, votre propre 75ᵉ centile — sans attendre CrUX.

✅ Point d’étape — Les vitals de vos visiteurs partent vers votre serveur. Ouvrez l’onglet Réseau, interagissez avec la page, et vérifiez qu’un appel à /collecte-vitals apparaît.

Étape 7 — Vérification finale : fixer un budget de performance

Mesurer ne sert à rien sans objectif chiffré. La dernière étape consiste à transformer vos relevés en budget de performance : un seuil que vous refusez de dépasser. Par exemple : « le LCP au 75ᵉ centile reste sous 2,5 s, le poids JavaScript de la page d’accueil sous 170 Ko compressés ».

Récapitulez vos trois sources : le laboratoire (Lighthouse) pour déboguer, le terrain agrégé (CrUX, via PageSpeed Insights et Search Console) pour le verdict Google, et votre suivi maison (web-vitals) pour réagir vite. Quand les trois pointent dans la même direction, vous savez où porter l’effort. Et c’est précisément l’objet des tutoriels suivants : réparer le LCP, l’INP et le CLS un par un.

🐞 Pièges fréquents

🌍 Réalités du terrain

En Afrique de l’Ouest, l’écart entre votre poste de travail et l’appareil médian de vos visiteurs est souvent énorme. À Niamey, Lomé ou Conakry, une part importante du trafic arrive sur des téléphones d’entrée de gamme, en 3G ou en 4G saturée, parfois avec un forfait de données compté au mégaoctet. Auditer depuis un bureau câblé donne une image flatteuse et fausse.

Prenez l’habitude de mesurer dans les conditions de vos clients : dans les outils de développement, l’onglet Performance permet de brider le processeur (réglage « 4× slowdown ») et le réseau (profil « Slow 4G »). PageSpeed Insights, lui, applique déjà par défaut une émulation mobile et un bridage réseau — raison de plus pour s’y fier plutôt qu’à un Lighthouse local non bridé. Enfin, gardez en tête le coût des données : chaque mégaoctet économisé sur vos images et vos scripts, ce sont des francs CFA économisés par vos visiteurs, et une page qui se charge même sur une connexion fragile.

✅ Récapitulatif

Vous savez désormais mesurer la performance d’une page sur les deux régimes qui comptent. Le laboratoire (Lighthouse, en navigateur ou en ligne de commande) vous donne un diagnostic reproductible et une liste d’opportunités. Le terrain (CrUX, lu via PageSpeed Insights et la Search Console) vous donne le verdict des vrais utilisateurs au 75ᵉ centile. Et la bibliothèque web-vitals vous offre vos propres chiffres en temps réel. Avec ces trois sources et un budget de performance, vous avez tout pour attaquer les corrections — c’est l’objet des prochains tutoriels.

🧾 Aide-mémoire

💪 À vous de jouer

Auditez la page d’accueil de votre projet en mode Mobile avec Lighthouse, puis relancez-la avec le bridage « Slow 4G » et « 4× CPU » activé dans l’onglet Performance. Comparez les deux LCP. L’écart vous dira à quel point votre score « de bureau » est optimiste.

Dans la même série

• Optimiser le LCP (Largest Contentful Paint) — accélérer l’affichage du plus gros élément visible.
• Optimiser le JavaScript et le bundling avec Vite — alléger le code qui bloque le fil principal.

Pour aller plus loin

• 🔝 Retour au guide principal : Core Web Vitals et performance web.
• Documentation officielle : web.dev — Core Web Vitals et Chrome User Experience Report.

FAQ

Faut-il viser un score Lighthouse de 100 ?
Non. Le score de laboratoire est un indicateur, pas une fin. Ce qui compte pour le référencement, ce sont les Core Web Vitals mesurés sur le terrain au 75ᵉ centile. Une page à 88 en laboratoire mais « Réussi » partout sur le terrain vaut mieux qu’un 100 fragile.

Mon site est récent et CrUX n’a pas de données. Suis-je pénalisé ?
Non : l’absence de données dans CrUX n’est pas une mauvaise note. Google s’appuie sur le terrain quand il existe, sinon sur d’autres signaux. En attendant, mesurez chez vos propres visiteurs avec web-vitals.

Quelle différence entre TBT et INP ?
Le Total Blocking Time est une mesure de laboratoire (le fil principal bloqué), l’INP une mesure de terrain (la latence réelle des interactions). Un TBT élevé prédit presque toujours un mauvais INP, c’est pourquoi on surveille le premier en attendant le second.