PageSpeed Insights, Lighthouse, GTmetrix : pourquoi les scores de vitesse ne concordent jamais

Vous lancez PageSpeed Insights sur votre landing page fraîchement publiée : 45 sur mobile, alerte rouge. Un peu inquiet·e, vous testez la même URL sur GTmetrix : 92, note A. Par acquit de conscience, vous ouvrez l'onglet Lighthouse de Chrome DevTools, sur votre propre poste : 98. Trois outils, trois verdicts sur la page strictement identique, et aucune indication de celui à croire pour décider si la page a un problème ou non. Ce n'est pas un bug d'un des trois outils : c'est qu'ils ne mesurent pas la même chose, dans les mêmes conditions, pour la même personne. Comprendre ce qui les sépare évite de perdre une après-midi à optimiser un chiffre qui ne reflète pas ce que vivent vos vrais visiteurs.

Le premier écart : laboratoire contre terrain

Lighthouse (qu'il tourne dans Chrome DevTools, en ligne de commande, ou derrière PageSpeed Insights) fait toujours la même chose : il charge la page une fois, dans un environnement contrôlé, avec un réseau et un processeur simulés selon un profil fixe. C'est ce qu'on appelle des données de laboratoire — reproductibles, utiles pour comparer un avant/après, mais issues d'un seul chargement synthétique. PageSpeed Insights, lui, affiche en plus des données de terrain : les métriques réellement mesurées chez vos visiteurs Chrome au cours des 28 derniers jours, agrégées par Google via le Chrome User Experience Report (CrUX) et présentées au 75ᵉ centile, comme nous le détaillons dans notre article sur le LCP. Ce sont deux blocs distincts dans le même rapport : le score chiffré (0 à 100) ne provient que du passage de laboratoire, tandis que le verdict « Bon / À améliorer / Mauvais » sur les Core Web Vitals, lui, s'appuie sur le terrain quand assez de trafic existe. Une page peut donc afficher un score de laboratoire élevé et, juste en dessous, un badge rouge sur le LCP réel — les deux chiffres cohabitent sans se contredire, ils ne répondent simplement pas à la même question.

Pourquoi Lighthouse seul donne déjà des scores différents d'une exécution à l'autre

Avant même de comparer deux outils, relancez Lighthouse trois fois de suite sur la même page depuis le même ordinateur : les scores bougent, parfois de 10 à 15 points. Le chargement d'une page n'est pas une opération unique mesurée une fois pour toutes, mais l'exécution d'un graphe de dépendances entre le réseau, l'analyse du HTML, l'exécution du CSS et du JavaScript, et le rendu à l'écran — un travail de recherche de Xiao Sophia Wang et ses coauteurs, présenté en 2013 à la conférence NSDI sous le nom de WProf, a modélisé précisément ce graphe sur 350 pages et montré que le calcul (analyse, exécution JavaScript) représente jusqu'à 35 % du temps sur le chemin critique du chargement, aux côtés du réseau et du rendu (Wang et al., 2013). Concrètement, cela veut dire que le temps de calcul disponible au moment précis du test — un autre onglet ouvert, un processus en arrière-plan, la charge du serveur qui héberge PageSpeed Insights à cet instant — modifie le résultat, même à code et connexion strictement identiques. Un score isolé n'a donc jamais de valeur absolue ; seule une tendance mesurée plusieurs fois, ou un écart net (20 points, pas 3), mérite d'être pris au sérieux.

GTmetrix : un laboratoire, mais paramétrable

GTmetrix ajoute une troisième source d'écart : il laisse choisir la localisation du serveur de test, le profil de connexion simulé et, sur les comptes payants, l'appareil émulé — autant de réglages qui, par défaut, ne correspondent pas forcément à ceux de PageSpeed Insights. Un test lancé depuis un serveur à Londres sur une connexion « Unlimited » n'a pas de raison de produire le même chiffre qu'un test Google lancé depuis les infrastructures Google avec un profil de limitation réseau différent. GTmetrix reste un outil de laboratoire, au même titre que Lighthouse : il offre en revanche un détail souvent plus lisible, cascade de requêtes à l'appui, sur la ressource précise qui bloque l'affichage — un bon complément pour diagnostiquer une image ou un script problématique une fois qu'on sait déjà, via les données de terrain, qu'un problème existe réellement pour vos visiteurs.

Le chiffre qui compte pour le SEO n'est ni Lighthouse ni GTmetrix

Pour le classement Google, seules les données de terrain (CrUX) pèsent dans les Signaux Web essentiels — pas le score de laboratoire, quel que soit l'outil qui l'affiche. Une page peut scorer 60 sur PageSpeed Insights en laboratoire et être jugée « Bonne » côté terrain si vos visiteurs réels, sur leurs appareils et connexions, restent sous les seuils des Core Web Vitals (LCP, INP, CLS). L'inverse existe aussi, et c'est le cas le plus piégeux : un score de laboratoire excellent qui masque un terrain dégradé, parce que vos visiteurs réels utilisent des appareils d'entrée de gamme ou une connexion 4G que le test de laboratoire, calibré sur un profil générique, ne reproduit pas fidèlement. Le rapport « Signaux Web essentiels » de Google Search Console reste la seule source qui reflète ce que vivent réellement vos visiteurs, une fois le trafic suffisant pour que Google y consacre des données — voir notre article sur la vitesse de chargement et la conversion pour ce que ces secondes coûtent réellement en visiteurs perdus.

Une méthode simple pour arrêter de courir après un chiffre

1. Choisissez un seul outil de laboratoire pour vos comparaisons avant/après un changement (toujours Lighthouse, ou toujours GTmetrix avec les mêmes réglages) — comparer un score GTmetrix d'hier à un score PageSpeed Insights d'aujourd'hui ne veut rien dire.
2. Lancez trois passages, pas un seul, et retenez la médiane plutôt que le premier chiffre affiché : cela filtre une bonne partie du bruit lié à la charge du moment.
3. Une fois le site en ligne avec du trafic réel, basculez votre attention sur le rapport « Signaux Web essentiels » de Search Console : c'est la seule mesure qui compte pour le référencement et qui reflète vos vrais visiteurs.
4. Ne visez jamais 100/100 comme objectif en soi : au-delà des seuils « Bon » de chaque métrique (2,5 s pour le LCP, 0,1 pour le CLS, 200 ms pour l'INP), les points supplémentaires n'ont plus d'effet mesurable ni sur le classement ni sur la conversion.
5. Traitez un écart de 3 à 5 points entre deux passages du même outil comme du bruit ; un écart de 20 points ou plus, lui, signale un vrai changement à investiguer.

Partir d'une base qui ne dépend pas du hasard du test

La façon la plus fiable d'éviter ces allers-retours entre outils reste de partir d'une page qui n'a structurellement rien à cacher : pas de thème générique chargeant du CSS inutilisé, pas d'empilement de scripts tiers, pas de moteur de rendu appelé à chaque visite. Les templates LanderKit sont des pages Next.js pré-générées, sans CMS ni plugin, que vous pouvez tester vous-même sur n'importe quel outil avant achat via leurs démos live — la variance d'un test à l'autre y est minime, précisément parce qu'il n'y a presque rien pour la provoquer. Pour l'hébergement et la génération statique qui conditionnent une bonne partie de ce résultat, notre guide de déploiement Next.js sur Vercel détaille la configuration complète.