Depuis 2020, Google a développé un vaste écosystème d’outils pour analyser la performance des sites sous l’angle des Core Web Vitals. Certains reposent sur des données d’utilisateurs réels, d’autres sur des tests lancés à la demande, et les deux plus connus, PageSpeed Insights et Lighthouse, sont si souvent confondus qu’on lit encore des audits qui présentent un score de laboratoire comme une note attribuée par Google au site.
Lighthouse est un moteur d’audit open source, intégré aux outils de développement de Chrome, qui charge une page dans des conditions simulées et produit un score et des recommandations. PageSpeed Insights est un service en ligne qui exécute ce même moteur sur les serveurs de Google, et y ajoute les données de terrain du Chrome User Experience Report. La différence tient donc en une phrase : l’un mesure une simulation, l’autre y ajoute la réalité, et seule la réalité compte pour le référencement.
Cet article explique ce qui sépare les données de terrain des données de laboratoire, ce que les deux outils partagent et ce qui les distingue, comment lire un score Lighthouse depuis la refonte de la version 13 en octobre 2025, et lequel utiliser selon la question posée. Pourquoi un site peut-il afficher 100 sur Lighthouse et échouer aux Core Web Vitals dans la Search Console ?
Quelle différence entre données de terrain et de laboratoire ?
Les données de terrain sont collectées auprès de vos visiteurs réels pendant leur navigation, sur leurs appareils et leurs connexions ; les données de laboratoire proviennent d’un chargement rejoué dans des conditions contrôlées, un Moto G4 simulé sur réseau mobile pour PageSpeed Insights. Les premières mesurent ce qui se passe, les secondes expliquent pourquoi. Aucune ne remplace l’autre.
Que sont les données de terrain ?
Les données de terrain, ou données field, sont relevées sur les appareils et les connexions de vos visiteurs, puis agrégées au 75e centile sur 28 jours glissants. La seule base publique est le Chrome User Experience Report, le CrUX, alimenté par les utilisateurs de Chrome, et c’est celle que Google utilise pour évaluer les Core Web Vitals dans la Search Console. Sa méthodologie précise que pour qu’un utilisateur y contribue, quatre conditions doivent être réunies :
- avoir activé l’envoi des statistiques d’utilisation dans Chrome ;
- synchroniser son historique de navigation avec son compte Google ;
- ne pas avoir défini de phrase secrète de synchronisation, qui chiffre les données de bout en bout ;
- utiliser une plateforme prise en charge, ce qui exclut Chrome sur iOS, les WebView Android et les autres navigateurs basés sur Chromium comme Edge.
Google ne publie pas la proportion d’utilisateurs qui remplissent ces critères, et l’absence d’iOS introduit un biais connu : les possesseurs d’iPhone, souvent mieux équipés, n’y figurent pas, ce qui tire les chiffres vers le bas. Ces données sont en outre sujettes à une forte variabilité, selon la localisation, la connexion, le matériel et les extensions de chaque visiteur. C’est pourquoi on travaille au 75e centile, et avec la jauge de répartition en trois segments, bon, à améliorer et mauvais :
Que sont les données de laboratoire ?
Les données de laboratoire, ou données synthétiques, proviennent d’un chargement déclenché à la demande sur une machine et un réseau simulés. Elles sont reproductibles, disponibles immédiatement et détaillées jusqu’à la requête et à la ligne de code. Elles ne disent rien de vos visiteurs réels, mais elles seules permettent de diagnostiquer, parce qu’elles exposent la cascade de chargement complète.
L’analyse peut être lancée depuis le navigateur d’un utilisateur, comme le fait Lighthouse dans les DevTools, ou depuis une infrastructure dédiée, comme le font PageSpeed Insights, WebPageTest ou GTmetrix. Dans ce second cas, l’intérêt est que les conditions restent identiques d’un test à l’autre : même processeur, même mémoire, même débit et même latence simulés. Cette stabilité permet de comparer un même site dans le temps, ou plusieurs sites entre eux, avec des indicateurs qui ne dépendent pas de l’humeur du réseau.
À l’inverse des données de terrain, le laboratoire produit des valeurs uniques, en millisecondes pour le FCP, le LCP, le Speed Index et le Total Blocking Time, en indice pour le CLS, chacune associée à un seuil vert, orange ou rouge. Une métrique manque à l’appel, et ce n’est pas un hasard : l’INP n’existe pas en laboratoire, faute d’interactions, et le TBT n’en est qu’une approximation au chargement.
Quels sont les points communs entre PageSpeed Insights et Lighthouse ?
Les deux outils exécutent le même moteur d’analyse, Lighthouse, et produisent donc le même score de performance et les mêmes recommandations sur une page donnée. PageSpeed Insights est Lighthouse exécuté sur les serveurs de Google, dans un centre de données d’Amérique du Nord, d’Europe ou d’Asie selon la charge, avec une configuration réseau et matérielle imposée.
La documentation de PageSpeed Insights précise que Lighthouse y simule un appareil de milieu de gamme, un Moto G4, sur un réseau mobile, et un desktop émulé sur connexion filaire. Le premier outil effectue donc le test via l’infrastructure de Google, le second via votre propre machine et votre propre connexion, ce qui explique la plupart des écarts entre les deux. Les résultats se présentent dans une interface visuellement identique, déclinée pour mobile et pour desktop :
Cette mise en page commune se décompose en trois sections. Un score de performance global sur 100, calculé en toute transparence à partir des métriques de laboratoire, orange à partir de 50 et vert à partir de 90. Les cinq métriques principales, FCP, Speed Index, LCP, TBT et CLS, censées refléter l’expérience utilisateur. Et une vue pellicule des étapes du chargement, qui permet de repérer d’un coup d’œil un TTFB trop élevé, une image principale découverte tard ou un décalage de mise en page.
Depuis Lighthouse 13, les anciens audits ont été remplacés par des insights, les mêmes que dans le panneau Performance des DevTools.
Pour l’un comme pour l’autre, il faut prendre du recul : ces données ne sont qu’une capture à l’instant T, dans des conditions qui ne reflètent probablement pas celles de vos visiteurs. La documentation de PageSpeed Insights le dit sans détour, de bonnes données de laboratoire ne signifient pas nécessairement que l’expérience des utilisateurs réels sera bonne. Un score vert ne garantit pas de passer les Core Web Vitals sur le terrain, et seules les données du CrUX comptent pour Google.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Quelles sont les différences entre PageSpeed Insights et Lighthouse ?
PageSpeed Insights ajoute les données de terrain du CrUX, absentes de Lighthouse ; Lighthouse, en local, analyse quatre volets au lieu d’un seul, accepte les pages non publiques et laisse choisir l’appareil et le réseau simulés. L’un sert à situer un site, l’autre à le diagnostiquer, y compris en préproduction ou derrière une authentification.
| Critère | PageSpeed Insights | Lighthouse |
|---|---|---|
| Données de terrain | Oui, via le CrUX, 28 jours glissants | Non |
| Données de laboratoire | Oui, moteur Lighthouse | Oui, en local |
| Volets analysés | Performance | Performance, accessibilité, bonnes pratiques, SEO |
| Environnement d’exécution | Serveurs Google, Moto G4 simulé, imposé | Votre machine, paramétrable |
| Pages privées ou locales | Non | Oui |
| Usage recommandé | Situer et suivre | Diagnostiquer et recetter |
La ligne décisive de ce tableau est la première. Seul PageSpeed Insights expose les données de terrain, celles que Google utilise pour évaluer votre site : un score de laboratoire à 100 sur une page dont les Core Web Vitals de terrain sont mauvais ne vaut rien pour le référencement. L’inverse est vrai aussi, et bien plus fréquent qu’on ne le croit : un score de 70 avec un terrain intégralement vert est un site qui va bien.
Lighthouse, au-delà de la performance
Lighthouse ne se limite pas à la performance : il analyse aussi l’accessibilité, les bonnes pratiques et le référencement, chacun noté sur 100. Ces trois volets sont absents du score public de PageSpeed Insights. C’est ce qui en fait un outil de recette, exécutable avant chaque mise en production, y compris en ligne de commande dans une intégration continue :
# Lighthouse en ligne de commande : les quatre volets, en JSON, sur une page de preproduction
npm install -g lighthouse
lighthouse https://preprod.exemple.fr/produit/ \
--preset=desktop \
--only-categories=performance,accessibility,best-practices,seo \
--output=json --output-path=./rapport.json
# Les scores, entre 0 et 1
jq '.categories[] | {id, score}' rapport.json
# Les insights de performance qui ont echoue (Lighthouse 13)
jq '.audits | to_entries[] | select(.key | endswith("-insight")) | select(.value.score != null and .value.score < 0.9) | .key' rapport.jsonCes volets complémentaires ne remplacent ni un audit d’accessibilité au sens du RGAA ni un audit SEO, mais ils permettent de prendre la température en quelques secondes, et de détecter des régressions grossières à chaque déploiement. La web performance étant une discipline transverse, il est courant pour un expert d’aborder ces sujets voisins, et Lighthouse est la première approche la moins coûteuse pour le faire.
PageSpeed Insights, les données de terrain en plus
PageSpeed Insights affiche, au-dessus du score de laboratoire, les Core Web Vitals réellement mesurés sur votre site par les utilisateurs de Chrome, sur les 28 derniers jours. Cette section n’apparaît que si votre trafic suffit à alimenter le CrUX : la documentation précise qu’à défaut de données pour la page, l’outil retombe sur l’origine entière, et qu’à défaut de données pour l’origine, il n’affiche rien. Son absence signale un site trop peu visité pour figurer dans la base publique, et non un site rapide.
Cette section est présentée en tout premier, avant l’analyse synthétique, et ce n’est pas un hasard de mise en page. Il convient de bien distinguer la section Découvrez l’expérience de vos utilisateurs, qui porte le terrain, de celle intitulée Analysez les problèmes de performances, qui porte le laboratoire. La première dit si vous avez un problème, la seconde aide à comprendre lequel :
Le panneau se lit en quatre zones. À droite du titre, un sélecteur bascule entre les métriques de la page, Cette URL, et celles du site entier, Origine, très utile pour repérer un problème transversal. En haut au centre, l’outil indique si la page ou le site passe l’évaluation des Signaux Web essentiels. Au centre, les métriques de terrain en barres de répartition, dont les trois Core Web Vitals, LCP, INP et CLS, plus le FCP et le TTFB.
En bas, sur fond gris, les conditions de collecte, avec la période de 28 jours glissants, qui explique l’inertie de ces chiffres : une correction déployée aujourd’hui met près d’un mois à se refléter entièrement.
Comment interpréter un score Lighthouse ?
Un score Lighthouse se lit en trois paliers : de 90 à 100 il est bon et vert, de 50 à 89 il demande des correctifs et s’affiche en orange, en dessous de 50 il est mauvais et rouge. Ce score n’est pas une note de qualité du site, mais la moyenne pondérée de cinq métriques de laboratoire, où le Total Blocking Time pèse 30 % à lui seul.
Une moyenne pondérée, pas une note
La pondération explique la plupart des incompréhensions. La documentation du calcul du score donne les poids en vigueur depuis Lighthouse 10 : First Contentful Paint 10 %, Speed Index 10 %, Largest Contentful Paint 25 %, Total Blocking Time 30 %, Cumulative Layout Shift 25 %. Le TBT et le LCP font donc plus de la moitié du score, et gagner dix points ne demande pas le même effort selon la métrique visée : deux sites au même score peuvent avoir des profils opposés, l’un lent à afficher et réactif, l’autre l’inverse.
La variabilité, et ce qui n’est pas un signal
Deux exécutions successives sur la même page donnent couramment des scores écartés de plusieurs points. La même documentation le reconnaît : une grande partie de la variabilité ne vient pas de Lighthouse mais des conditions sous-jacentes, tests A/B ou publicités servies, routage réseau, appareil de test, extensions qui injectent du JavaScript, antivirus.
Google recommande d’ailleurs de voir la performance d’un site comme une distribution de scores plutôt qu’un nombre unique, et précise qu’un score parfait de 100 est extrêmement difficile à atteindre et n’est pas attendu. Un écart de moins de cinq points n’est pas un signal, c’est du bruit de mesure.
Ce qui a changé avec Lighthouse 13
Le score n’a pas bougé, mais les recommandations ont changé de forme. Depuis Lighthouse 13, publié le 10 octobre 2025 et déployé dans PageSpeed Insights la semaine suivante, les anciens audits ont été remplacés par des insights communs au panneau Performance des DevTools : la latence du document, la découverte et les phases du LCP, les responsables du CLS, le rendu bloquant, les tiers. Barry Pollard, de l’équipe Chrome, l’annonçait dès avril 2025 en précisant la logique de cette consolidation.
Dans certains cas, les conseils de nombreux audits sont regroupés en un seul insight, et nous avons retiré certains conseils.
Barry Pollard, Web Performance Developer Advocate chez Google, dans son billet Lighthouse is moving to performance insight audits, publié le 28 avril 2025
Parmi les conseils retirés figurent l’audit des façades pour les tiers, celui des images hors écran et celui du préchargement, jugés trop souvent contre-productifs. Un rapport de 2026 ne ressemble donc plus à un rapport de 2024, et les guides qui listent encore les anciens audits sont datés. Ce que Lighthouse ne verra jamais, en revanche, n’a pas changé : le score de laboratoire n’a aucune valeur de classement. Google utilise les Core Web Vitals de terrain, au 75e centile, et un site peut très bien les passer avec un score de 75.
Quel outil choisir entre PageSpeed Insights et Lighthouse ?
Utilisez PageSpeed Insights pour savoir où vous en êtes, Lighthouse pour comprendre pourquoi et corriger. Le premier arbitre, puisqu’il porte les données que Google utilise ; le second diagnostique, sur n’importe quelle page, même privée, avec l’appareil et le réseau que vous choisissez. Se fier au seul score de laboratoire est l’erreur la plus fréquente que nous rencontrons.
Les deux outils abordent la web performance sous un angle particulier, et ils se complètent à tous les niveaux. Dans l’idéal, ils ne constituent qu’une brique d’un écosystème plus large. À l’agence, nous utilisons en complément des outils qui ne viennent pas de Google : WebPageTest et GTmetrix, qui offrent des options de test bien plus nombreuses, cascade détaillée, blocage de domaines, scripts de parcours, répétition de vues ; et des dizaines d’outils spécialisés, sur le CLS, les en-têtes HTTP, les polices ou la sécurité.
Notre article sur la mesure de la web performance situe chacun dans ce paysage, et le guide sur les scripts tiers montre comment le blocage de domaine tranche un débat en cinq minutes.
Il reste un cas où ni l’un ni l’autre ne suffit. Un widget en iframe, un chat ou un bloc d’avis, produit du CLS et de l’INP que le CrUX compte mais que ni Lighthouse ni un RUM maison ne voient, et un tag manager dégrade l’INP à chaque clic sans jamais apparaître dans un rapport de chargement. Ces angles morts feront l’objet de guides dédiés aux widgets de relation client et à Google Tag Manager.
Dans l’absolu, les seules données dont on ne peut se passer sont celles du Chrome User Experience Report, et la Search Console vous y donne déjà accès via l’onglet Signaux Web essentiels, avec plus de détail que PageSpeed Insights. Ni l’un ni l’autre des deux outils n’est donc indispensable : l’essentiel est de savoir quelle question chacun sait poser, ce qui est précisément le point de départ d’un audit de performance web.
