C’est une conversation que j’ai plusieurs fois par an. Un client m’envoie une capture d’écran : 98 sur 100 sur PageSpeed Insights, tout en vert. Et à côté, dans Search Console, le rapport Signaux web essentiels affiche des URL en échec.
Les deux sont justes. Ce sont deux mesures différentes, et une seule sert au classement.
Deux chiffres qui portent le même nom
Les données de laboratoire. Quand vous lancez PageSpeed Insights ou Lighthouse, l’outil charge votre page une fois, depuis un serveur, sur une connexion simulée, avec un appareil simulé. C’est reproductible, c’est pratique pour comparer deux versions d’une page, et c’est entièrement artificiel.
Les données de terrain. En parallèle, Chrome collecte les temps réellement vécus par les visiteurs qui ont accepté le partage de statistiques d’usage. Ces mesures alimentent le rapport d’expérience utilisateur de Chrome, et ce sont elles que Google utilise, et celles que Search Console affiche.
Ces données de terrain ont trois caractéristiques qui expliquent presque tous les écarts constatés.
Elles sont calculées sur une fenêtre glissante de vingt-huit jours. Une correction déployée aujourd’hui ne se verra pas avant plusieurs semaines, et la remontée sera progressive, pas franche. Beaucoup de gens concluent trop vite que leur correction n’a rien donné.
Elles sont exprimées au soixante-quinzième centile, pas en moyenne. Autrement dit, votre site est jugé sur l’expérience des 25 % de visiteurs les moins bien servis. Une moyenne confortable peut parfaitement cacher un échec.
Elles n’existent pas pour tout le monde. Un site à faible trafic n’a pas assez de visiteurs pour alimenter un échantillon fiable. Dans ce cas, Search Console peut n’afficher aucune donnée, ou des données à l’échelle du domaine entier plutôt que de la page.
Les trois indicateurs, et leurs seuils
| Indicateur | Ce qu’il mesure | Seuil « bon » |
|---|---|---|
| LCP | affichage du plus gros élément visible | 2,5 secondes |
| CLS | déplacements de la mise en page | 0,1 |
| INP | réactivité aux interactions | 200 millisecondes |
Ces seuils s’apprécient au soixante-quinzième centile, et sur mobile séparément du bureau. Un site peut parfaitement être conforme sur ordinateur et en échec sur mobile, ce qui est le cas le plus fréquent.
L’INP mérite une attention particulière, parce que c’est l’indicateur le plus difficile à anticiper en laboratoire. Il mesure le délai entre le clic d’un visiteur et la réponse visible de la page. Or un test automatique ne clique pas, ne fait pas défiler, n’ouvre pas de menu. Un score de laboratoire ne peut structurellement pas prédire un bon INP. C’est la principale raison des écarts.
Pourquoi les deux divergent
Au delà de l’INP, quatre causes reviennent systématiquement.
Le parc d’appareils réel. L’outil simule un appareil milieu de gamme sur une connexion bridée. Vos visiteurs ont parfois mieux, souvent pire, et surtout une grande variété que la simulation ne reproduit pas.
Les scripts tiers. Une bannière de consentement, un outil de chat, un pixel publicitaire, un script de test A/B : chacun ajoute du travail au navigateur au pire moment. Certains ne se déclenchent pas dans un test automatisé mais se déclenchent chez le visiteur.
Le cache. Un test se fait souvent sur une page déjà en cache côté serveur. Le visiteur qui arrive sur une page rarement consultée déclenche une génération complète, et attend.
La géographie. Vos clients ne sont pas tous à côté de votre serveur. Si votre hébergement est en France et que vous visez aussi le Maroc ou le Canada, la latence réseau change la donne.
Quoi corriger en premier sur un site WordPress
Par ordre de retour sur effort, d’après ce que je constate en intervention.
L’image principale. Dans la grande majorité des cas, le LCP est une image du haut de page. Trois règles : elle ne doit pas être chargée en différé, elle doit être servie en WebP ou AVIF à la bonne dimension, et elle doit être préchargée. Une image de 1,8 Mo redimensionnée en CSS reste une image de 1,8 Mo à télécharger.
Les polices. Une police hébergée chez un tiers ajoute une connexion et un risque de texte invisible pendant le chargement. Hébergez vos polices sur votre propre domaine, en woff2, avec un affichage de secours immédiat.
Le JavaScript bloquant. Chaque script chargé avant le rendu repousse l’affichage. La plupart peuvent être différés sans rien casser. Les scripts de mesure et de publicité, en particulier, n’ont aucune raison de s’exécuter en premier.
Les dimensions déclarées. Un CLS dégradé vient presque toujours d’images, d’iframes ou de publicités sans hauteur et largeur déclarées, ou d’une bannière injectée après coup qui pousse le contenu vers le bas.
Le thème et les extensions. C’est le sujet dont personne ne veut parler. Un thème commercial polyvalent charge un volume considérable de code dont votre site utilise une fraction. Aucun réglage de cache ne compense cela durablement. C’est aussi pour cette raison que la maintenance d’un site WordPress est autant une affaire d’hygiène que de réglages.
Un exemple : le site que vous lisez
Je ne vais pas prêcher sans montrer. Cette page est servie par un thème écrit sur mesure, sans constructeur visuel. La page d’accueil pèse environ 15 kilooctets une fois compressée, hors images. Les polices sont hébergées localement. Aucun script tiers ne se charge tant que vous n’avez pas accepté la mesure d’audience, ce qui signifie que pour un visiteur qui refuse, il n’y a tout simplement rien à exécuter.
Ce n’est pas un exploit technique, c’est un choix de construction. Il est beaucoup plus facile de partir léger que d’alléger ensuite.
Ce que cela change pour votre classement
Dernier point, pour remettre les choses à leur place. Les Core Web Vitals sont un critère de classement réel, mais modeste. Un site rapide et sans intérêt ne dépassera pas un site lent et pertinent.
Leur effet se joue surtout à pertinence comparable, et sur le comportement des visiteurs : une page lente est abandonnée avant d’être lue, et cela se voit dans vos conversions bien avant de se voir dans vos positions. C’est là que se trouve le vrai retour sur investissement.
FAQ
Mon score PageSpeed est de 100, pourquoi Search Console signale un échec ? Parce que Search Console affiche des données de terrain, collectées chez vos visiteurs réels, et non le résultat d’un test simulé. Fiez-vous au rapport Signaux web essentiels de Search Console, c’est lui qui reflète ce que Google utilise.
Combien de temps pour voir l’effet d’une correction ? Comptez vingt-huit jours au minimum, le temps que la fenêtre de mesure se renouvelle entièrement. Une amélioration partielle apparaît généralement avant, de façon progressive.
Search Console n’affiche aucune donnée pour mon site, est-ce un problème ? Non, c’est presque toujours un manque de trafic. L’échantillon est insuffisant pour produire une mesure fiable. Dans ce cas, travaillez sur les données de laboratoire et sur les bonnes pratiques, et la mesure de terrain arrivera avec l’audience.
Faut-il viser 100 sur 100 ? Non. Viser le vert sur les trois indicateurs de terrain suffit largement. Les derniers points d’un score de laboratoire coûtent cher en temps et ne rapportent rien en classement.
Faire mesurer votre site
Demandez un audit gratuit : je regarde vos données de terrain, pas un score, et je vous dis lesquelles de vos pages sont réellement en cause.