La performance web se mesure de deux façons qui ne répondent pas à la même question. Le terrain (RUM, real user monitoring) agrège des chargements réels. Le laboratoire rejoue un chargement dans un cadre fixe. Search Console et le Chrome UX Report sont du terrain. Lighthouse est du laboratoire. Choisir l’un comme s’il invalidait l’autre mélange une moyenne de visiteurs et un banc d’essai.
Le terrain : CrUX et Search Console
Le Chrome UX Report (CrUX) regroupe, sur 28 jours glissants, des mesures de navigateurs Chrome qui ont accepté de remonter des statistiques d’usage. Les trois signaux lus pour les Core Web Vitals sont LCP, INP et CLS, en général au 75e centile. Le rapport distingue mobile et ordinateur. Il peut exister pour l’origine entière (le site) avant d’exister pour une URL précise.
Search Console reprend ces données dans le rapport Signaux Web essentiels. Il ne mesure pas la page au moment où vous l’ouvrez. Il affiche l’agrégat, avec du retard, et il reste vide ou « données insuffisantes » quand CrUX n’a pas de série.
Google ne publie pas le nombre de visites à partir duquel une origine entre dans CrUX. Un site peu visité reste donc souvent sans ligne : ce n’est ni une panne de Search Console ni une mauvaise note cachée. Il n’y a simplement pas assez de chargements Chrome agrégés pour constituer un jeu public. Inventer un effectif de visiteurs pour « expliquer » l’absence n’apporte rien : le seuil n’est pas donné.
C’est le cas de SiteGarde : pas de données CrUX publiées, le trafic étant encore sous ce seuil non communiqué. On n’en déduit pas un LCP, ni un INP, ni un volume de visites. On constate l’absence de série.
Quand la série existe, elle dit ce que les visiteurs ont vécu : téléphones variés, réseaux variés, cache parfois chaud. Elle ne dit pas quel fichier raccourcir. Une régression y apparaît tard, parce que la fenêtre dure 28 jours.
Le laboratoire : Lighthouse
Lighthouse charge la page une fois (ou quelques fois), avec un bridage simulé, un viewport fixé, un cache froid. Le score de performance mélange des mesures de laboratoire, dont le LCP et le CLS de cet essai, et le Total Blocking Time, qui n’est pas l’INP des visiteurs. L’INP ne se lit pas dans ce score : il se constate au moment d’une interaction réelle, donc plutôt sur le terrain ou avec un suivi de terrain que vous auriez installé.
Le laboratoire sert à une chose : rendre la cause reproductible. On y voit l’élément LCP, les longues tâches, le poids des images, l’ordre des requêtes. On compare avant et après un correctif, sur le même profil. Un seul passage varie. Une médiane de plusieurs passages est plus stable. Aucune de ces passes n’est « la » valeur des utilisateurs.
Les deux divergent pour des raisons ordinaires. Le laboratoire est un mobile bridé ; vos visiteurs sont peut-être surtout sur ordinateur au bureau. Le laboratoire a le cache vide ; un visiteur qui revient a déjà la police. Le laboratoire teste une URL ; CrUX origine mélange toutes les pages. Écart ne veut pas dire que l’un des deux outils est cassé.
Quoi utiliser tant qu’il n’y a pas de CrUX
Sans série de terrain, Lighthouse reste l’outil pour choisir le correctif : image principale, JavaScript, serveur. Les pistes de cause sont dans page lente, et les seuils officiels des signaux, pour le jour où le rapport existera, dans Core Web Vitals. On ne publie pas le score Lighthouse comme s’il était le 75e centile des visiteurs.
En parallèle, le temps de réponse HTTP se suit de l’extérieur, indépendamment de Chrome. Il ne remplace ni CrUX ni Lighthouse : il dit si le document part tard, ce qui plafonne tout le reste. Le jour où Search Console affiche des URL dans les signaux web, on lira ce rapport pour le vécu, et on gardera le laboratoire pour expliquer un écart. D’ici là, l’absence de CrUX se respecte : pas de chiffre de terrain inventé à la place.