Accueil / Blog / Core Web Vitals : quoi corriger et jusqu...
Conseils SEO

Core Web Vitals : quoi corriger et jusqu'où aller

4 septembre 2026·8 min de lecture·par Florian Roger

Les Core Web Vitals occupent une place disproportionnée dans les discussions SEO au regard de leur influence réelle sur le classement. Cela ne veut pas dire qu'il faut les ignorer : leur effet sur le taux de conversion, lui, est direct et mesurable. Voici comment je les traite, et ce que j'ai cessé de chercher.

Article de référence sur les Core Web Vitals et les métriques de performance web

Trois indicateurs, chacun mesurant une facette différente de l'expérience réelle.

Les infos à retenir
  • 1Trois indicateurs : le LCP pour la vitesse d'affichage, l'INP pour la réactivité, le CLS pour la stabilité visuelle.
  • 2Les seuils considérés comme bons : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1.
  • 3Les données de terrain, issues des visites réelles, priment sur les mesures de laboratoire, utiles seulement pour diagnostiquer.
  • 4Sur ce site, un rapport relevé le 5 août 2026 donne 99 en performances et 100 en SEO sur ordinateur, obtenus avec des pages statiques légères.
  • 5L'influence sur le classement est faible et n'intervient qu'à pertinence comparable. L'influence sur le taux de conversion est immédiate.

Ce que mesurent les trois indicateurs

Chacun répond à une question que se pose l'utilisateur sans la formuler.

Le LCP, ou Largest Contentful Paint, mesure le temps au bout duquel le plus grand élément visible de la page est affiché. C'est la réponse à « quand est-ce que je vois quelque chose d'utile ». Il s'agit presque toujours d'une image de couverture ou d'un bloc de titre.

L'INP, ou Interaction to Next Paint, mesure le délai entre une action de l'utilisateur et la réponse visible de la page. C'est la réponse à « est-ce que ça réagit quand je clique ». Cet indicateur a remplacé l'ancien FID, qui ne mesurait que la première interaction et donnait une image trop favorable.

Le CLS, ou Cumulative Layout Shift, mesure les déplacements d'éléments pendant le chargement. C'est la réponse à « est-ce que le bouton va bouger au moment où je clique ». Un score élevé correspond à cette expérience désagréable où le contenu saute pendant qu'on lit.

Laboratoire ou terrain

Distinction essentielle, et pourtant souvent ignorée. Les mesures de laboratoire sont produites par un test simulé, dans des conditions standardisées. Les données de terrain proviennent des visites réelles de vos utilisateurs, avec leurs connexions et leurs appareils.

Ce sont les données de terrain qui comptent, y compris pour Google. Un site peut très bien afficher un excellent score en laboratoire et de mauvaises données réelles, parce que ses visiteurs sont majoritairement sur mobile avec une connexion moyenne.

Les mesures de laboratoire gardent leur utilité pour diagnostiquer : elles disent quel élément pose problème et pourquoi. Mais elles ne disent pas si vos utilisateurs souffrent réellement.

Le décalage entre les deux

J'ai vu un site afficher un score de laboratoire correct et des données de terrain nettement moins bonnes, simplement parce que la majorité de son audience naviguait sur mobile en 4G. Optimiser sur la base du test simulé revenait à traiter un problème que personne ne rencontrait.

Améliorer le LCP

C'est l'indicateur sur lequel les gains sont les plus rapides, parce que les causes sont peu nombreuses. Dans mon expérience, quatre leviers couvrent l'essentiel :

  • Optimiser l'image de couverture. Format moderne, dimensions adaptées à l'affichage réel, et surtout pas de chargement différé sur l'image visible d'emblée.
  • Réduire le temps de réponse du serveur. Un cache correct et un hébergement décent règlent la plupart des cas.
  • Supprimer les ressources bloquantes. Feuilles de style et scripts chargés avant l'affichage retardent tout le reste.
  • Précharger l'élément principal quand il est identifiable à l'avance.

L'erreur la plus fréquente, et de loin, est le chargement différé appliqué à l'image de couverture. On croit accélérer la page, et on retarde précisément l'élément que l'indicateur mesure.

Améliorer l'INP

Plus difficile, parce que le problème est presque toujours le JavaScript. Un fil d'exécution occupé ne peut pas répondre aux interactions, et l'utilisateur perçoit un décalage.

Les pistes qui fonctionnent : réduire la quantité de scripts chargés, découper les tâches longues pour laisser le navigateur respirer, différer ce qui n'est pas nécessaire à l'affichage initial, et limiter les scripts tiers.

Sur les sites que j'audite, les scripts tiers représentent régulièrement la majeure partie du problème. Outils de mesure, chats, bandeaux, tests d'affichage : chacun paraît anodin, l'accumulation ne l'est pas. La question à poser à chaque fois est simple, et rarement posée : ce script rapporte-t-il plus qu'il ne coûte ?

Rapport PageSpeed Insights du site florian-roger.com

Le rapport de ce site au 5 août 2026 : 99 en performances, 91 en accessibilité, 100 en bonnes pratiques et en SEO.

Améliorer le CLS

C'est l'indicateur le plus simple à corriger, et celui qui gêne le plus les utilisateurs. Les causes sont presque toujours les mêmes.

Images sans dimensions réservées, polices personnalisées qui se substituent avec un décalage, bandeaux insérés au-dessus du contenu déjà affiché, éléments ajoutés après le chargement. Les corrections correspondantes :

  • Réserver l'espace des images en CSS, avec un rapport d'aspect, plutôt qu'en attributs HTML.
  • Précharger les polices et prévoir une police de secours aux métriques proches.
  • Réserver la place des bandeaux et des encarts publicitaires avant leur chargement.
  • Éviter d'insérer du contenu au-dessus de ce qui est déjà affiché.

Une précision qui a son importance, et qui m'a valu un correctif en production : réserver l'espace d'une image se fait en CSS, avec un rapport d'aspect, plutôt qu'avec des attributs HTML de largeur et de hauteur. Certains navigateurs mobiles ignorent le rapport d'aspect et appliquent l'attribut de hauteur littéralement, ce qui déforme complètement l'affichage.

Un bug rencontré en production

Une image en 1200 par 675 déclarée en attributs HTML s'affichait sur 273 px de large et 675 px de haut dans un navigateur mobile intégré, écrasant tout le contenu situé en dessous. Retirer les attributs et laisser le CSS gérer le dimensionnement a suffi.

Quel effet réel sur le référencement

Autant être clair : l'effet direct sur le classement est faible. Ces indicateurs interviennent comme critère de départage entre des pages de pertinence comparable, pas comme un levier de positionnement.

Concrètement, améliorer son LCP ne fera pas passer une page de la troisième page à la première. Ce qui l'y ferait passer, c'est un meilleur contenu et davantage d'autorité, ce qui relève du travail éditorial et d'une stratégie de netlinking plutôt que de l'optimisation technique. Sur un site WordPress, l'essentiel des mauvaises mesures vient d'ailleurs de l'accumulation d'extensions, comme je le détaille dans mon article sur le SEO WordPress.

En revanche, l'effet sur le comportement des visiteurs est direct. Une page lente perd des visiteurs avant même d'être vue, et un contenu qui saute pendant la lecture fait fuir. Ce sont ces gains-là qui justifient le travail, et ils se mesurent en conversions plutôt qu'en positions.

Le poids des scripts tiers

Sur un site où j'ai mesuré la répartition, les scripts tiers représentaient la majeure partie du temps d'exécution JavaScript, pour des fonctionnalités dont aucune n'était indispensable. Retirer deux outils de mesure redondants a suffi à faire passer l'INP dans le vert.

Questions fréquentes

Quel score viser sur PageSpeed ?
Le score global n'est qu'un résumé. Ce qui compte, c'est que les trois indicateurs de terrain soient dans le vert. Un site à 75 avec de bonnes données réelles est en meilleure situation qu'un site à 95 dont les visiteurs subissent des lenteurs.
Faut-il optimiser mobile ou ordinateur en priorité ?
Mobile, dans la quasi-totalité des cas. C'est l'indexation mobile qui fait référence, et c'est généralement là que se trouvent les mauvaises mesures, parce que les conditions réelles y sont plus contraignantes.
Combien de temps pour voir les données mises à jour ?
Les données de terrain sont calculées sur une fenêtre glissante de vingt-huit jours. Une correction déployée aujourd'hui met donc environ un mois à se refléter pleinement dans les rapports.
Les Core Web Vitals comptent-ils pour les moteurs génératifs ?
Indirectement. Un temps de réponse serveur correct compte, parce qu'un serveur lent peut être abandonné pendant l'exploration. Le reste, réactivité et stabilité visuelle, n'a pas d'incidence sur un robot qui ne clique nulle part.
Un site WordPress peut-il atteindre de bons scores ?
Oui, à condition de limiter le nombre d'extensions et d'utiliser un thème sobre. Les mauvaises mesures viennent presque toujours de l'accumulation de fonctionnalités, pas du logiciel lui-même.

Jusqu'où aller

Ma règle est simple : atteindre le vert sur les trois indicateurs, puis arrêter. Le passage de mauvais à correct change réellement l'expérience. Le passage de correct à parfait coûte beaucoup de temps pour un gain que personne ne perçoit.

Concrètement, je traite le LCP en premier parce que c'est là que les gains sont les plus rapides, le CLS ensuite parce que les corrections sont simples et l'inconfort réel, et l'INP en dernier parce qu'il demande souvent d'arbitrer sur les scripts tiers, ce qui n'est pas seulement une décision technique.

Une fois ce niveau atteint, mieux vaut consacrer son énergie ailleurs. Les Core Web Vitals lèvent un frein, ils ne créent pas d'élan, et un site rapide sans contenu ni autorité reste un site rapide que personne ne voit. C'est aussi pour cela que je les place en dernier dans la séquence d'un audit technique SEO.

Florian Roger
Florian Roger
Consultant SEO freelance
Consultant SEO freelance depuis huit ans et certifie QASEO, j'accompagne PME et grandes marques pour gagner des positions durables sur Google. Je teste regulierement les outils du marche sur mes propres projets avant d'en parler ici.