Un client m'envoie un mail l'autre jour : « Search Console me dit que mon site est "à améliorer" sur les Core Web Vitals. C'est grave ? ». Je regarde son URL. Quatre secondes et demie de LCP sur mobile. Il vend des meubles en ligne, et sa page produit met plus de temps à s'afficher que le temps moyen qu'un visiteur accorde avant de fermer l'onglet. Voilà le vrai problème.
Les Core Web Vitals ne sont pas une case à cocher dans un audit SEO pour faire joli dans un rapport. Ce sont trois mesures de ce que votre visiteur ressent physiquement en arrivant chez vous : est-ce que ça s'affiche vite, est-ce que ça répond quand je clique, est-ce que la page arrête de bouger sous mon doigt. Google les utilise comme signal de classement depuis 2021, mais leur intérêt réel dépasse largement le référencement.
Points clés à retenir
- Trois métriques : LCP (vitesse d'affichage), INP (réactivité), CLS (stabilité visuelle).
- Seuils à viser : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1.
- Les données de terrain (utilisateurs réels) comptent plus que les scores de laboratoire.
- Corriger le LCP rapporte presque toujours plus que corriger le CLS.
- Un mauvais INP se répare rarement en installant un plugin.
- Mesurez avant, mesurez après. Sinon vous ne saurez jamais ce qui a marché.
Comprendre les Core Web Vitals : trois mesures, trois expériences
Le LCP (Largest Contentful Paint) mesure le moment où le plus gros élément visible de la page est affiché : souvent une image d'en-tête, un titre, une bannière produit. C'est la métrique du « ça arrive enfin ». En dessous de 2,5 secondes, on considère que c'est bon. Au-delà de 4 secondes, Google classe la page comme médiocre.
Le CLS (Cumulative Layout Shift) traque les sauts de mise en page. Vous connaissez cette sensation : vous allez cliquer sur un bouton, une publicité se charge, le bouton descend, vous cliquez à côté. Score à ne pas dépasser : 0,1. Ce n'est pas une question de vitesse, c'est une question de nerfs.
Et l'INP, la métrique qu'on a tous apprise à la dure
L'INP (Interaction to Next Paint) a remplacé le FID en mars 2024. Il mesure le délai entre une interaction (clic, appui, frappe) et le moment où la page réagit visuellement. Seuil : 200 millisecondes. Sur le papier, ça a l'air simple. En pratique, c'est la métrique qui m'a le plus surpris.
Je me souviens d'un site de réservation de restaurants que je suivais. LCP nickel à 1,9 s. CLS à 0,04. Et un INP qui explosait à 480 ms dès qu'on filtrait les résultats. La cause ? Un script de carte interactive qui recalculait tout le DOM à chaque frappe dans le champ de recherche. Rien de visible dans les tests de laboratoire. Il a fallu plonger dans les données terrain pour le voir.
Voilà le piège : un site peut afficher de bons scores en laboratoire et de mauvais chiffres réels sur le terrain, parce que le laboratoire ne connaît ni votre connexion mobile dans le métro, ni votre vieux processeur de 2019.
Quel score écouter : laboratoire ou données réelles ?
Deux sources de mesure existent et elles ne racontent pas la même histoire.
| Source | Ce qu'elle mesure | Quand la consulter |
|---|---|---|
| PageSpeed Insights (labo) | Une visite simulée, connexion et appareil standardisés | Pour diagnostiquer une cause technique précise |
| Search Console / CrUX (terrain) | Les visites réelles des 28 derniers jours | Pour savoir si votre visiteur souffre vraiment |
| Extension Web Vitals | Les mesures de votre propre session, en direct | Pour ressentir ce que ressent l'utilisateur, à l'instant |
Pourquoi les deux sources divergent-elles autant ?
Le laboratoire charge la page une fois, sur un serveur rapide, sans extension ni cookie. Le terrain agrège des milliers de visites, dont la moitié sur du matériel modeste avec un réseau moyen. Résultat : un écart qui va souvent du simple au double sur le LCP. Et c'est le terrain qui compte pour le classement, parce que c'est lui qui décrit l'expérience réelle.
Ma règle, et j'y tiens : le terrain décide, le laboratoire explique. Si Search Console dit « médiocre » mais que PageSpeed affiche 92, ne vous réjouissez pas. Vous avez un problème que les tests simulés ne voient pas.
Le diagnostic pas à pas pour améliorer les performances
Vous ouvrez Search Console, rapport Expérience sur la page, onglet Core Web Vitals. Vous regardez quel groupe d'URL échoue. Ensuite, et seulement ensuite, vous ouvrez PageSpeed Insights sur deux ou trois URL représentatives de ce groupe.
- Repérer la métrique la plus pénalisante — dans 8 cas sur 10, c'est le LCP.
- Identifier l'élément coupable — l'outil vous dit précisément quel nœud HTML est l'élément LCP.
- Corriger une seule chose à la fois, puis re-mesurer après 24 à 48 h.
- Vérifier sur le terrain, jamais sur votre machine en Wi-Fi fibre.
Pas de hasard. Une hypothèse, un test, un résultat.
L'erreur que je faisais au début : tout optimiser d'un coup
Je vais être franc : ma première tentative d'optimisation a été catastrophique. J'ai installé trois plugins de cache, minifié tout le CSS, converti les images en WebP, tout en même temps. Résultat : le site est tombé, puis est remonté avec un score PageSpeed de 98 en labo. Sur le terrain ? Aucun changement. Pire, un léger recul du LCP mobile.
J'avais optimisé ce qui se mesure facilement, pas ce qui posait problème. Deux semaines perdues. Depuis, je teste une seule chose à la fois, et je note chaque variation de LCP et d'INP dans un tableur. C'est moins glamour, mais ça marche. Sur un site e-commerce que j'ai suivi l'an dernier, cette méthode a fait passer le LCP mobile de 4,2 s à 2,1 s en trois semaines, et le taux de conversion mobile a grimpé d'environ 15 % sur la même période. Pas de hasard là-dedans, mais pas de miracle non plus.
Comment prioriser par métrique (et où va l'effort)
Le LCP est le levier le plus rentable. Chaque seconde gagnée se ressent physiquement. Les actions qui fonctionnent réellement, dans l'ordre :
- Compresser les images d'en-tête (elles pèsent souvent 2 à 3 Mo pour rien)
- Servir les images en WebP ou AVIF, avec un srcset adapté aux écrans
- Précharger la police de caractères critique
- Supprimer les scripts bloquants du haut de page
- Héberger sur un serveur correct (un mutualisé bas de gamme est un plafond de verre)
Le CLS se corrige en dix minutes quand on sait d'où il vient : des dimensions fixes sur les images et les iframes, un espace réservé pour les bannières publicitaires. Réservez la place avant que le contenu arrive.
Et l'INP, franchement, c'est un chantier
L'INP est la métrique la plus difficile à réparer, parce qu'elle dépend de la charge JavaScript côté navigateur. Il faut souvent retirer du code, ce qui fait grincer des dents en réunion. J'ai un client qui refusait de lâcher son carrousel de quatre sliders sur mobile. On a testé en le désactivant une semaine : INP passé de 340 à 110 ms, taux de rebond mobile en baisse de plusieurs points. Il l'a gardé désactivé. Les chiffres ont tranché, pas moi.
Que faire quand l'évaluation Core Web Vitals échoue ?
Échec ne veut pas dire catastrophe. Le rapport distingue trois états : bon, à améliorer, médiocre. Un site « médiocre » sur une catégorie de pages n'est pas pénalisé d'un coup de massue. Il perd un léger avantage face aux concurrents qui font mieux, à contenu équivalent. C'est un signal parmi des centaines.
Mais voilà le vrai risque : si votre site est « médiocre », votre visiteur est parti avant de lire vos arguments. La perte de conversion arrive avant la perte de position. C'est ce qu'on oublie trop souvent dans les rapports.
Combien de temps avant de voir un effet dans Search Console ?
Les données terrain sont agrégées sur une fenêtre glissante de 28 jours. Après une correction, comptez deux à quatre semaines avant que l'état bascule dans le rapport, parfois plus si le trafic est faible. Ne concluez rien au bout de trois jours.
Peut-on faire un audit gratuit de son site ?
Oui, et c'est même le point de départ obligatoire. Search Console et PageSpeed Insights sont gratuits et suffisent pour un premier diagnostic complet. Un audit payant n'a de sens qu'après avoir épuisé ces deux sources.
Ce qui reste quand le score est vert
Un site à 100 partout n'est pas un site fini. Vous avez juste arrêté de gaspiller le temps de vos visiteurs en bas de page. La vraie question n'est pas « ai-je un bon score ? », c'est « est-ce que le produit derrière mérite qu'on attende la page ? ». Les Core Web Vitals enlèvent un obstacle, mais ils ne remplacent ni une offre claire ni une navigation lisible.
C'est là que la plupart des audits s'arrêtent trop tôt, d'ailleurs. Un score vert avec un tunnel d'achat de huit étapes reste un tunnel de huit étapes. Et je vous le dis d'expérience : le jour où vous corrigez un vrai problème de performance, vous n'avez pas gagné des visiteurs. Vous avez rendu à ceux qui étaient déjà là le temps qu'ils vous avaient accordé.
