Lighthouse calcule son score de performance à partir de scores de métriques pondérés, et non du nombre d’avertissements du rapport. Chaque mesure brute passe d’abord par une courbe de notation : la relation entre millisecondes gagnées et points obtenus n’est donc pas linéaire. Pour comparer deux résultats, conservez la même version de Lighthouse, le même profil d’appareil, la même limitation des ressources et le même état de page, puis examinez plusieurs exécutions avec les données des utilisateurs réels.
Vérifiez la version avant d’interpréter les poids
La dernière version logicielle indiquée par le projet Lighthouse lors de la vérification du 17 octobre 2026 était v13.5.0. Cela ne détermine pas la version utilisée par une requête PageSpeed Insights ou une installation de Chrome particulière. Les calendriers de diffusion et votre navigateur peuvent différer. La version inscrite dans le rapport est celle qui compte pour la comparaison.
Une distinction documentaire doit également être conservée. La page générale de Chrome nomme toujours son tableau habituel « Lighthouse 10 ». La configuration de la branche principale consultée pour cet article contient les cinq mêmes poids non nuls. L’accès à la configuration étiquetée v13.5.0 n’a pas pu être vérifié. Le tableau décrit donc la branche principale inspectée et le modèle documenté de Lighthouse 10, et non une configuration v13.5.0 vérifiée séparément. Pour un audit à version fixée, inspectez son JSON comme indiqué plus bas.
Voici les poids vérifiés dans ces deux sources.
| Métrique | Poids | Ce que mesure le résultat |
|---|---|---|
| First Contentful Paint (FCP) | 10% | L’apparition du premier contenu admissible |
| Speed Index (SI) | 10% | La vitesse de remplissage du contenu visible pendant le chargement |
| Largest Contentful Paint (LCP) | 25% | L’apparition du plus grand contenu visible admissible |
| Total Blocking Time (TBT) | 30% | Les portions bloquantes des tâches longues du thread principal dans la fenêtre mesurée |
| Cumulative Layout Shift (CLS) | 25% | Les déplacements inattendus mesurés pendant le chargement audité |
La configuration inspectée contient aussi INP avec un poids nul. Un score de navigation standard n’est donc pas un score INP. TBT aide à repérer le travail du thread principal à examiner, mais le substituer à l’INP des utilisateurs réels revient à répondre à une autre question.
Réorganiser le rapport ne change pas automatiquement la notation. Lighthouse 13 a regroupé d’anciens audits dans les insights ; son annonce précisait que le score de performance ne changeait pas. La disparition d’un ancien nom ne prouve pas que le problème sous-jacent a cessé d’importer.
Convertissez les mesures avant de faire la moyenne
LCP est une durée et CLS est sans unité. Additionner directement ces valeurs n’aurait pas de sens. Lighthouse transforme chaque mesure en un score propre, puis combine ces scores selon leurs poids.
Google décrit des distributions de notation log-normales éclairées par les données de HTTP Archive. Deux améliorations identiques d’une mesure ne produisent donc pas toujours le même gain de points. Sur une partie pentue de la courbe, le score peut évoluer visiblement ; près du maximum, un progrès similaire peut à peine modifier l’entier affiché. Les évaluations mobiles et de bureau ne sont pas interchangeables non plus : configurations et attentes de notation diffèrent.
Pour un exemple purement arithmétique, supposons que tous les scores restent constants sauf celui de TBT, qui gagne 10 points sur une échelle de 0 à 100. Avec un poids de 30%, sa contribution au total augmente de 3 points avant l’arrondi. Il s’agit d’un calcul hypothétique, ni d’un benchmark ni d’une promesse sur une modification de code.
Distinguez valeur et score d’une métrique. Supprimer 100 millisecondes de travail n’ajoute pas 100 points, ni un autre nombre fixe de points. La valeur initiale, la courbe, la fenêtre mesurée et les autres métriques comptent. Une optimisation peut également modifier plusieurs métriques à la fois et rendre les prévisions simples moins fiables.
Consultez l’explication officielle de la notation pour comprendre le modèle. Choisissez ensuite le travail technique à partir de votre rapport. Un faible gain de score peut accompagner une amélioration importante d’un élément lent, notamment lorsqu’une autre métrique limite encore le total.
Les avertissements indiquent des causes, pas des pénalités fixes
Une feuille de style qui bloque le rendu n’entraîne pas un retrait universel d’un nombre fixe de points. Son effet dépend du contenu qu’elle retarde et de sa contribution aux métriques. De même, un avertissement de script inutilisé signale du travail potentiellement évitable ; son intitulé n’est pas une métrique pondérée supplémentaire.
Cela évite deux erreurs fréquentes. Effacer tous les avertissements ne revient pas forcément à améliorer l’expérience. Additionner les économies estimées de plusieurs insights ne donne pas non plus une économie totale fiable : elles peuvent se chevaucher, dépendre de la même chaîne ou modifier la planification du navigateur lorsqu’elles sont appliquées ensemble.
Examinez la cascade réseau et la chronologie du thread principal avant d’intervenir. Une image principale découverte tard pose un autre problème qu’une image découverte rapidement mais téléchargée lentement. Si JavaScript monopolise le thread principal, commencez par réduire son temps d’exécution plutôt que de recompresser une image déjà légère.
Conservez les métriques individuelles même si votre organisation réclame un score unique. Un total supérieur peut cacher une régression. Une amélioration de CLS peut, par exemple, compenser un affichage du contenu plus lent dans la moyenne pondérée. Le total ne permet pas à lui seul de juger si ce compromis convient à votre page.
Contrôlez les conditions qui font varier le score
Lighthouse mesure un système en activité. Charge CPU en arrière-plan, extensions, publicités variables, expériences, cache, routage réseau et charge serveur peuvent changer le déroulement. Un navigateur qui reçoit du code d’une extension n’observe plus la même charge qu’un profil propre.
La méthode de limitation des ressources introduit une autre frontière. La limitation simulée estime les performances à partir d’une trace, tandis que la limitation appliquée contraint l’exécution elle-même. Un résultat issu d’une méthode n’est pas une répétition exacte d’un résultat issu de l’autre. Gardez la méthode fixe et notez-la.
La même URL peut proposer différentes expériences. Bandeau de consentement, session connectée, contenu géographique ou expérience active modifient le DOM, les requêtes et les scripts. Notez l’état testé au lieu de supposer que l’URL décrit toute l’expérience. Testez séparément les états significatifs présents en production.
Une première visite sans cache et une visite répétée nécessitent des observations distinctes. Une police ou un script en cache peut modifier le chemin critique ; une réponse HTML stockée peut modifier le temps serveur. Conservez la politique prévue entre référence et candidat. Ne comparez pas une référence à froid à un candidat à chaud en attribuant tout l’écart au code.
Utilisez une machine stable et peu chargée pour les comparaisons locales. Fermez les applications lourdes, évitez les audits concurrents et utilisez un profil propre. Gardez les réglages d’alimentation constants. Cela réduit le bruit évitable sans rendre un ordinateur portable représentatif de tous les visiteurs.
Lancez une comparaison reproductible en ligne de commande
La CLI permet de conserver ensemble commande, version du paquet et sortie. Elle nécessite une installation compatible de Node.js et Chrome ou Chromium. Vérifiez les exigences du paquet choisi avant installation. Les commandes suivantes fixent la version observée pendant la recherche ; elles sont illustratives et n’ont pas été exécutées contre example.com pour cet article.
Enregistrez cinq rapports JSON distincts avec une version fixe et la configuration mobile par défaut.
mkdir -p lighthouse-reports
for run in 1 2 3 4 5; do
npx --yes [email protected] https://example.com/ --only-categories=performance --chrome-flags="--headless" --output=json --output-path="lighthouse-reports/mobile-${run}.json"
doneCinq exécutions constituent un point de départ pratique, pas une garantie statistique ni une exigence officielle de réussite. Appliquez le même protocole à la référence et au candidat. Si la dispersion est importante, recherchez sa cause avant d’interpréter un petit écart comme un progrès.
Lisez la version, les poids non nuls et le score dans le rapport sauvegardé, plutôt que de les déduire d’une capture.
// inspect-lighthouse.mjs
import { readFileSync } from 'node:fs';
const file = process.argv[2];
if (!file) throw new Error('Pass a Lighthouse JSON report path.');
const report = JSON.parse(readFileSync(file, 'utf8'));
const performance = report.categories.performance;
console.log('Lighthouse version:', report.lighthouseVersion);
console.log('Performance score:', performance.score);
console.table(performance.auditRefs.filter(({ weight }) => weight > 0));Exécutez le script sur le premier rapport.
node inspect-lighthouse.mjs lighthouse-reports/mobile-1.jsonLe score JSON est normalisé : 0.9 correspond à 90 avant la mise en forme d’affichage. Conservez les rapports complets, pas seulement les totaux. Ils contiennent les réglages et les métriques nécessaires pour expliquer un écart ultérieurement. Pour le bureau, créez une série distincte avec --preset=desktop et ne la mélangez pas avec la série mobile.
Utilisez des médianes sans masquer la dispersion
Triez les scores répétés et communiquez la valeur centrale comme médiane simple. Conservez aussi minimum, maximum et valeurs individuelles. Une médiane résiste mieux à une exécution exceptionnellement rapide ou lente, mais ne répare pas un test mal contrôlé.
Ne fabriquez pas un « meilleur rapport » en combinant le LCP le plus rapide d’une exécution, le TBT minimal d’une autre et le CLS minimal d’une troisième. Cette combinaison n’a jamais existé. Gardez un rapport représentatif et toute la série afin de préserver les relations entre mesures.
Une comparaison utile indique URL et révision, état, versions de Chrome et Lighthouse, profil, méthode de limitation, nombre d’exécutions, médiane et dispersion pertinente. Ajoutez la modification étudiée et les différences environnementales connues. Vous obtenez une preuve reproductible plutôt qu’un nombre sans conditions.
PageSpeed Insights, DevTools et la CLI peuvent utiliser des versions et environnements différents. Le guide PageSpeed Insights explique ce rapport. En cas de désaccord, comparez d’abord réglages et états ; le score inférieur ne prouve pas que l’outil se trompe.
Transformez le score en prochaine mesure utile
Un score de 100 est un résultat de laboratoire arrondi dans des conditions particulières, pas un certificat de rapidité pour chaque visiteur. Il ne teste pas chaque route, interaction, appareil, langue ou durée de session. Des déplacements tardifs et des interactions lentes peuvent rester invisibles dans un audit de navigation.
Placez les données terrain et de laboratoire côte à côte. Les tests contrôlés expliquent rapidement une modification ; les mesures réelles indiquent ensuite si le public visé en bénéficie. Une divergence peut révéler une condition de test manquante sans invalider l’un des jeux de données.
Pour l’itération suivante, choisissez une métrique lente, identifiez sa cause réseau ou sur le thread principal et apportez une modification vérifiable. Sauvegardez une référence reproductible avec l’analyseur PageSpeed lorsqu’il est configuré, ou avec la CLI précédente. Poursuivez avec le guide d’optimisation de vitesse pertinent lorsque la mesure désigne la cause. L’objectif utile est un progrès démontré qui résiste aux répétitions et atteint les utilisateurs.
