PageSpeed et Search Console ne sont pas d'accord : comment lire les données de labo et de terrain

Deux situations reviennent sans cesse. Dans la première, le rapport PageSpeed est au vert alors que Search Console liste des centaines d'URL « Médiocres » sur mobile. Dans la seconde, plus fréquente encore sur les sites dont les visiteurs naviguent avec de bonnes connexions, PageSpeed affiche un score orange ou rouge alors que Search Console classe toutes les URL en « Bon ». Lequel des deux ment ?

Aucun. Ils ne mesurent pas la même chose. Une fois que vous savez ce que chacun voit, l'écart entre les deux vous dit dans quel cas vous êtes, et quoi faire.

Deux types de mesure

Les données de labo sont le score et les métriques en bas du rapport. C'est une seule visite simulée : un téléphone émulé, une connexion bridée, un cache vide, depuis un data center de Google, et personne ne touche à la page. C'est reproductible, donc idéal pour déboguer, et ça s'arrête quand la page a fini de charger.

Les données de terrain sont celles qu'utilise Search Console, et celles qu'affiche le haut du rapport PageSpeed dans la section consacrée aux utilisateurs réels. Elles viennent du Chrome User Experience Report : de vrais visiteurs Chrome, leurs appareils, leurs réseaux, sur 28 jours glissants. Une page est validée quand 75 % des visites sont bonnes, donc c'est le quart le plus lent de votre audience qui décide.

Cas 1 : labo au vert, terrain médiocre

Ici, le test est plus clément que la réalité. Six raisons l'expliquent :

1. L'INP n'existe pas en labo. L'Interaction to Next Paint mesure la vitesse à laquelle la page réagit aux clics et aux touchers. Le labo ne clique jamais. Pire, une optimisation qui repousse le JavaScript jusqu'à la première interaction améliore le labo et peut ralentir le premier vrai toucher. Voir le guide sur le report du JavaScript.

2. Le labo s'arrête au chargement, pas le CLS. Le terrain compte les décalages de mise en page pendant toute la visite : au défilement, quand un bandeau glisse à l'écran, quand une pub ou un contenu intégré change de taille. Un CLS de zéro en labo ne dit rien de ce qui se passe sous la ligne de flottaison. Les coupables habituels sur les page builders sont dans notre guide sur le CLS.

3. Les vrais appareils sont plus lents. Le 75e percentile de votre audience peut être un téléphone ancien sur une connexion faible, bien en dessous du profil du labo. Une page qui passe tout juste en labo échoue pour eux.

4. Les vraies visites ratent votre cache. Le labo tombe souvent sur un cache de page déjà chaud. Le trafic réel inclut des pages non mises en cache : premières visites après une purge, clients connectés, et URL avec des paramètres de suivi comme utm_source, gclid ou fbclid, que beaucoup de caches traitent comme de nouvelles pages. Leur temps de réponse serveur se retrouve dans le LCP de terrain.

5. Search Console regroupe les URL. Le rapport affiche des groupes de pages similaires, et les pages sans assez de trafic héritent des données de leur groupe ou du site entier. L'URL que vous testez n'est peut-être pas celle qui tire le groupe vers le bas.

6. La fenêtre est de 28 jours. Un correctif livré aujourd'hui n'est pleinement pris en compte qu'au bout de quatre semaines environ. Retester le lendemain matin dans Search Console affiche les anciennes données.

Cas 2 : labo médiocre, terrain au vert

Ici, le test est plus sévère que la réalité. Le test de labo mobile émule un téléphone milieu de gamme dont le processeur est ralenti quatre fois, avec une connexion mobile bridée à environ 1,6 Mbit/s et 150 ms de latence. Ce profil est volontairement pessimiste, et beaucoup d'audiences réelles sont bien plus rapides :

• Des réseaux et des téléphones plus rapides. Les visiteurs en fibre, en 4G rapide ou en 5G, avec des téléphones récents, finissent de charger bien avant l'appareil émulé. Au 75e percentile, ils restent au vert.
• Des visites à chaud. Les visiteurs qui reviennent et la navigation de page en page réutilisent les fichiers en cache et les connexions ouvertes. Le labo part toujours à froid, sans rien en cache.
• Les scripts coûtent moins cher sur du vrai matériel. Un script lourd qui bloque le processeur émulé pendant plusieurs secondes n'en prend qu'une fraction sur un téléphone récent : le temps de blocage mesuré en labo exagère donc ce que ressentent les visiteurs.

L'endroit où se trouvent vos visiteurs décide du cas dans lequel vous êtes. Une audience située dans des pays où les connexions mobiles sont lentes se comporte comme le labo, voire pire : c'est le cas 1. Une audience sur des réseaux rapides fait mieux que le labo : c'est le cas 2. Search Console et PageSpeed affichent un seul chiffre pour l'ensemble de vos visiteurs ; si votre audience est internationale, les données publiques du Chrome UX Report peuvent être ventilées par pays.

Que faire dans le cas 2. Les signaux d'expérience sur la page de Google utilisent les données de terrain : c'est donc un terrain au vert qui compte. Ne cassez pas un site qui fonctionne pour courir après un score de labo. Gardez le labo comme outil de diagnostic : il montre ce que vivent vos visiteurs les plus lents, et il repère les régressions avant qu'elles n'atteignent le terrain. Améliorez ce qu'il pointe, une modification sûre à la fois, comme dans notre méthode pour optimiser sans casser.

Étape 1 : lire ce que Search Console dit vraiment

• Quelle métrique : LCP, INP ou CLS. La méthode diffère complètement pour chacune.
• Quel appareil : mobile et desktop sont des rapports séparés.
• Quel groupe : ouvrez le problème et regardez les exemples d'URL. Ils pointent presque toujours vers un template : fiches produit, articles, pages de catégorie, page d'accueil.

Ouvrez ensuite un exemple d'URL dans PageSpeed et regardez d'abord la section des utilisateurs réels. Si elle affiche des données pour cette URL, vous avez les chiffres de terrain propres à la page ; si elle affiche l'origine entière, la page est jugée avec le reste du site.

Étape 2 : reproduire le problème de terrain dans votre navigateur

Pour l'INP : ouvrez les DevTools, panneau Performance, réglez le bridage CPU sur 4x ou 6x, enregistrez, et interagissez comme le ferait un visiteur : ouvrir le menu, changer une variante, ajouter au panier, accepter le bandeau cookies. Les longs blocs jaunes après votre clic, c'est le délai. Les versions récentes de Chrome affichent aussi les valeurs LCP, CLS et INP en direct dans ce panneau.

Pour le CLS : rechargez avec le bridage, puis faites défiler toute la page lentement et interagissez. Dans l'onglet Rendering, « Layout Shift Regions » fait clignoter chaque décalage au moment où il se produit.

Pour le LCP : testez le template en émulation mobile, avec une URL qui n'est pas en cache (ajoutez un paramètre aléatoire), et regardez le temps de réponse serveur et le moment où l'élément LCP est découvert.

new PerformanceObserver(l => l.getEntries().forEach(e =>
  console.log('LCP', Math.round(e.startTime), e.element))).observe({ type: 'largest-contentful-paint', buffered: true });
new PerformanceObserver(l => l.getEntries().forEach(e => !e.hadRecentInput &&
  console.log('CLS', e.value.toFixed(3), e.sources?.map(s => s.node)))).observe({ type: 'layout-shift', buffered: true });

Étape 3 : ne jamais conclure sur un seul test

Le score de labo bouge d'un test à l'autre, parfois de dix points sur mobile, parce que la page, le réseau et la machine de test varient. Pour comparer deux versions :

• testez chaque version plusieurs fois et comparez les médianes, pas le meilleur test ;
• espacez les tests, car un résultat redemandé dans un court intervalle peut être servi depuis un cache et répéter le même chiffre ;
• comparez la même URL, le même appareil, les mêmes conditions, avec et sans la modification.

Étape 4 : valider et attendre

Une fois le correctif en ligne, cliquez sur « Valider la correction » sur le problème dans Search Console. La validation suit la fenêtre de 28 jours, donc comptez environ un mois. En attendant, ce sont le labo et vos propres mesures dans le navigateur qui vous disent que le correctif fonctionne.

Avec Mantys Core

En résumé

• Le score PageSpeed est un chargement simulé ; Search Console, ce sont 28 jours de vraies visites au 75e percentile.
• Labo au vert et terrain médiocre : le problème est une interaction, un décalage après le chargement, un appareil lent, une URL non mise en cache ou un autre template.
• Labo médiocre et terrain au vert : vos visiteurs sont plus rapides que le profil de test pessimiste ; c'est le terrain qui compte.
• Partez de Search Console : métrique, appareil, groupe d'URL, template.
• Reproduisez dans les DevTools avec bridage et vraies interactions, puis comparez plusieurs tests de labo, jamais un seul.
• Validez le correctif et laissez-lui quatre semaines.