PageSpeed vert mais Search Console en rouge : pourquoi ?

C’est l’une des questions qu’un responsable de site pose le plus souvent à son développeur : « PageSpeed est bon, mais la Search Console dit que nos Core Web Vitals sont mauvais. Qui a raison ? » La réponse surprend : les deux. Le score PageSpeed vient d’un test de laboratoire, une visite simulée dans des conditions fixes. Le rapport de la Search Console agrège les visites réelles de vos utilisateurs sur plusieurs semaines.

Un score PageSpeed bon avec des Core Web Vitals mauvais dans la Search Console n’est donc pas un bug : c’est un signal. Il indique que vos visiteurs vivent quelque chose que le test ne reproduit pas. Tout l’enjeu consiste à trouver quoi, sans perdre des semaines à polir un score qui ne compte pas.

Deux outils, deux réalités : laboratoire et terrain

Le laboratoire est un banc d’essai : une page chargée une fois, sur un appareil émulé et un réseau bridé, sans historique ni interaction. Le terrain est la piste : toutes les visites réelles, sur des téléphones de toutes générations et des réseaux irréguliers, avec des visiteurs qui cliquent, font défiler et reviennent.

Laboratoire (Lighthouse, score PageSpeed) et terrain (CrUX, Search Console), critère par critère
Critère	Laboratoire	Terrain
Source	Une visite simulée	Les visites réelles d’utilisateurs de Chrome ayant accepté le partage de statistiques
Appareil et réseau	Un profil fixe, mobile émulé ou ordinateur	Tous les appareils et réseaux de vos visiteurs
Interactions	Aucune : le test s’arrête au chargement	Toutes celles de la visite
Période	L’instant du test	Une fenêtre glissante de 28 jours
Résultat	Un score sur 100 et des diagnostics	Une valeur au 75^e centile par indicateur
Usage	Comprendre une cause, vérifier un correctif	Savoir ce que vivent vos visiteurs, et ce que Google retient

La règle d’or : le terrain dit où se trouve le problème, le laboratoire aide à comprendre pourquoi. Les opposer n’a aucun sens ; les confondre coûte cher.

Ce que mesure le score PageSpeed, et ce qu’il ignore

La page de résultats de PageSpeed Insights réunit en réalité deux outils. En haut, les données de terrain issues de CrUX, quand votre site reçoit assez de trafic. En dessous, le diagnostic Lighthouse, qui produit le fameux score sur 100. C’est lui qui s’affiche en vert, et c’est lui que Google n’utilise pas pour évaluer l’expérience de vos pages.

Ce score est une moyenne pondérée de plusieurs indicateurs de laboratoire : le premier affichage de contenu, l’indice de vitesse, le LCP, le temps de blocage total et le CLS. Il présente trois angles morts majeurs.

L’INP n’y figure pas. Sans interaction, pas de mesure de réactivité : le temps de blocage total n’en est qu’un indicateur indirect. Un site peut afficher un score excellent et un INP médiocre sur le terrain.
Le CLS n’est mesuré qu’au chargement. Sur le terrain, il se cumule pendant toute la visite : publicités insérées au défilement, bandeaux qui apparaissent tard, blocs chargés en différé sans place réservée.
La visite testée n’est pas celle de vos visiteurs. Pas de bannière de consentement acceptée, pas de session connectée, pas de paramètres de campagne dans l’URL, un seul passage à cache vide.

Ajoutez la variabilité d’un test isolé, et l’on comprend pourquoi un score vert rassure à tort : il dit que la page peut être rapide, pas qu’elle l’est pour vos visiteurs.

Le rapport Core Web Vitals de la Search Console expliqué

Le rapport « Signaux Web essentiels » de la Search Console, nom français des Core Web Vitals, s’appuie sur les mêmes données de terrain que CrUX. Il les présente séparément pour le mobile et pour l’ordinateur, classe les URL en trois statuts (« bonne », « à améliorer », « médiocre ») et attribue à chaque URL le statut de son plus mauvais indicateur. Une page parfaite en LCP et en INP mais instable au chargement sera donc classée selon son CLS.

Conséquence pratique : lisez toujours le rapport indicateur par indicateur, et appareil par appareil. Un tableau global en rouge peut cacher un seul problème, très localisé.

Groupes d’URL : quand un gabarit entier est jugé sur quelques pages

Faute de données suffisantes pour chaque URL, la Search Console regroupe les pages qui se ressemblent, en pratique celles d’un même gabarit, et leur applique une évaluation commune, avec des exemples d’URL et le nombre de pages concernées.

Cas type : une boutique en ligne voit plusieurs milliers de fiches produits passer en « à améliorer » pour le LCP. Ce n’est pas un problème par fiche, c’est un problème de gabarit, probablement l’image principale ou le temps de réponse du serveur. Corriger le gabarit corrige le groupe. À l’inverse, tester une seule URL d’exemple dans PageSpeed peut tomber sur une page plus légère que la moyenne du groupe, et faire conclure à tort que tout va bien.

Le 75^e centile : pourquoi vos visiteurs les plus lents comptent

Google n’évalue pas une page sur la visite moyenne, mais au 75^e centile : pour qu’un indicateur soit jugé bon, au moins trois visites sur quatre doivent passer sous le seuil. Les seuils publics sont un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1.

Le 75^e centile ne regarde pas la visite typique : il se place à la frontière du quart des visites les plus lentes. Ce sont donc vos visiteurs lents, sans aller jusqu’aux cas extrêmes, qui déterminent la note : téléphones modestes ou de quelques années, réseaux mobiles chargés, premières visites sans cache. Si votre audience est surtout mobile, ce sont eux qui décident.

Mobile, réseau, appareils : reproduire les conditions réelles

Pour réconcilier les deux sources, le laboratoire doit se rapprocher du terrain. Quelques réglages rendent un test bien plus parlant.

Tester le mobile d’abord, avec un processeur ralenti et un réseau bridé dans les outils de développement. Sur un ordinateur récent relié à la fibre, presque tout semble rapide.
Rejouer le parcours réel : arrivée depuis un lien de campagne, acceptation de la bannière de consentement, ouverture d’un menu, ajout au panier.
Tester l’URL exacte, paramètres compris. Des paramètres de suivi ajoutés par les campagnes peuvent contourner le cache du CDN et allonger fortement le temps de réponse du serveur pour tout ce trafic.
Répéter les mesures plusieurs fois et comparer des médianes, plutôt qu’un essai unique.
Tester sur un vrai téléphone de milieu de gamme, relié en débogage à distance : rien ne remplace un appareil physique.

Gardez enfin en tête que les données CrUX proviennent uniquement de Chrome, hors iOS : un échantillon, pas la totalité de vos visiteurs.

Réconcilier les deux sources pour trouver la vraie cause

Voici la séquence que suit Julien Jimenez quand le laboratoire et le terrain divergent. Elle part toujours du terrain, et ne touche au code qu’en dernier.

identifier dans la Search Console l’indicateur en échec, l’appareil concerné et le groupe d’URL ;
vérifier dans l’historique CrUX de l’URL et de l’origine si le problème est récent ou ancien ;
relier le groupe à son gabarit, puis choisir trois ou quatre pages représentatives par leur trafic ;
pour l’INP, chercher les interactions lentes dans une mesure chez les visiteurs ; pour le CLS, observer la page pendant le défilement, pas seulement au chargement ;
reproduire en laboratoire dans les conditions réelles : mobile bridé, consentement, parcours, paramètres d’URL ;
formuler une hypothèse de cause, la tester sur une page, puis l’étendre au gabarit ;
noter la date de mise en production et suivre l’évolution sur le terrain.

Le cas type le plus instructif est celui d’un site éditorial : score mobile honorable, mais groupe d’URL d’articles en échec pour le CLS. Le test de laboratoire ne fait jamais défiler la page ; les lecteurs, si. Les emplacements publicitaires insérés au fil de la lecture, sans hauteur réservée, décalent le texte. La cause n’apparaît qu’en observant la page comme un lecteur.

Après correctif : pourquoi le rapport tarde à passer au vert

Le correctif est en ligne, le laboratoire confirme le gain, et la Search Console reste rouge. Là encore, rien d’anormal. Les données de terrain sont agrégées sur une fenêtre glissante de 28 jours, selon la documentation de CrUX : le lendemain de la mise en production, l’essentiel des visites prises en compte date encore d’avant le correctif. La courbe s’infléchit progressivement, puis le groupe d’URL change de statut. Pour accompagner ce délai :

lancez la validation dans la Search Console une fois le gabarit entièrement corrigé ;
suivez une mesure chez vos visiteurs, qui reflète les nouvelles visites dès le premier jour ;
surveillez les régressions : une mise en production ultérieure peut annuler le gain avant que le rapport ne l’enregistre.

Chaque cycle de correction coûte ainsi des semaines d’observation : une raison de plus pour viser juste du premier coup, cause identifiée sur le terrain.

Questions fréquentes sur PageSpeed et la Search Console

Q01

Le score PageSpeed a-t-il une influence sur le référencement ?

Pas directement. Google s’appuie sur les données de terrain des Core Web Vitals, celles des visites réelles, et non sur le score de laboratoire de Lighthouse. Ce score reste un excellent outil de diagnostic, mais l’améliorer sans changer l’expérience réelle ne modifie pas le rapport de la Search Console.

Q02

Pourquoi PageSpeed Insights n’affiche-t-il pas de données de terrain pour ma page ?

Parce que CrUX ne publie des données que pour une URL ou une origine qui reçoit assez de visites éligibles. Pour une page peu fréquentée, PageSpeed Insights se replie sur l’origine entière, ou n’affiche rien ; une mesure installée sur votre site prend alors le relais.

Q03

Mobile et ordinateur peuvent-ils avoir des statuts différents ?

Oui, et c’est fréquent. La Search Console évalue séparément mobile et ordinateur, avec des appareils, des réseaux et parfois des gabarits différents. Commencez par l’appareil qui concentre le plus de visites et de chiffre d’affaires, souvent le mobile.

Q04

Combien de temps après un correctif la Search Console passe-t-elle au vert ?

Comptez plusieurs semaines : les données de terrain sont agrégées sur 28 jours glissants, et la validation suit sa propre période d’observation. Des tests de laboratoire répétés et une mesure chez vos visiteurs confirment le gain sans attendre le changement de statut.

Score PageSpeed bon, Core Web Vitals mauvais : ce qu’il faut retenir

Un score PageSpeed vert et une Search Console en rouge ne racontent pas deux histoires contradictoires. Le premier décrit une visite idéale, la seconde la réalité de vos visiteurs au 75^e centile, sur plusieurs semaines. L’écart entre les deux est un indice précieux : il désigne ce que le test ne voit pas, qu’il s’agisse d’interactions, de décalages au défilement, d’appareils modestes ou de conditions d’arrivée particulières.

La bonne démarche part donc toujours du terrain, isole un indicateur, un appareil et un gabarit, reproduit la visite réelle en laboratoire, puis corrige la cause. Si l’INP est en cause, le décryptage consacré aux tâches longues JavaScript qui bloquent l’interaction détaille la méthode ; si c’est le LCP d’une grande image, la séquence pour optimiser une image hero prend le relais.