Core Web Vitals en 2026 : LCP, INP, CLS — optimiser les 3 métriques

Les Core Web Vitals mesurent trois choses : la vitesse d’affichage du contenu principal, avec un LCP visé sous 2,5 secondes, la réactivité aux interactions, avec un INP sous 200 millisecondes, et la stabilité visuelle, avec un CLS sous 0,1. Elles se calculent sur les visites réelles, au 75e centile, sur vingt-huit jours glissants. Ce ne sont pas les leviers de classement les plus puissants, mais ce sont parmi les rares que vous contrôlez de bout en bout.

Core Web Vitals : les trois métriques et leurs seuils

Ce que chacune mesure, en une phrase

Le LCP, pour Largest Contentful Paint, correspond au moment où le plus gros élément visible s’affiche, généralement une image de couverture ou un gros titre. L’INP, pour Interaction to Next Paint, mesure le délai entre une action du visiteur et la réponse visible à l’écran, sur l’ensemble de la visite. Le CLS, pour Cumulative Layout Shift, quantifie les déplacements de contenu qui font cliquer à côté.

Métrique	Bon	À améliorer	Mauvais
LCP	≤ 2,5 s	≤ 4 s	> 4 s
INP	≤ 200 ms	≤ 500 ms	> 500 ms
CLS	≤ 0,1	≤ 0,25	> 0,25

Données de terrain et données de laboratoire

C’est la distinction qui explique la plupart des incompréhensions. Les notes affichées par un outil d’audit viennent d’une simulation, faite sur une machine, une fois. Les Core Web Vitals qui comptent viennent du rapport d’expérience utilisateur de Chrome, alimenté par les visites réelles de vos visiteurs, avec leurs téléphones et leurs connexions. Un site peut afficher 98 sur 100 en laboratoire et rester dans le rouge sur le terrain, simplement parce que la moitié de son audience navigue sur un mobile de milieu de gamme.

Le diagnostic en trois chiffres

Relevez vos trois valeurs dans la Search Console ou dans PageSpeed Insights, saisissez-les ci-dessous, et l’outil vous dit où vous en êtes et par quoi commencer.

Optimiser LCP : trouver l’élément coupable, puis le servir plus vite

Identifier l’élément LCP

Avant toute correction, il faut savoir quel élément est mesuré. Les outils de développement de Chrome le désignent explicitement dans le panneau des performances, et PageSpeed Insights le nomme dans son diagnostic. Dans neuf cas sur dix, c’est l’image de couverture ou le bloc de titre du haut de page. Optimiser autre chose ne changera rien à la note, quel que soit le temps passé.

Les corrections par ordre de rentabilité

• Servir l’image de couverture en format moderne, correctement dimensionnée, et surtout pas en 2000 pixels de large réduite par le navigateur.
• La précharger et lui donner la priorité de chargement, plutôt que de la laisser attendre son tour derrière les scripts.
• Ne jamais mettre l’image du haut de page en chargement différé : c’est l’erreur qui coûte le plus cher, et elle vient souvent d’une extension activée sans réglage.
• Supprimer ce qui bloque l’affichage, en particulier les polices et les feuilles de style chargées depuis un autre domaine.
• Regarder le temps de réponse du serveur : si le premier octet arrive après une seconde, aucune optimisation d’image ne rattrapera le retard.

Optimiser INP : la métrique qui a remplacé le FID

Pourquoi le changement de mars 2024 a fait mal

Jusqu’en mars 2024, la métrique de réactivité était le FID, qui ne mesurait que le délai avant la prise en compte de la première interaction. C’était une mesure indulgente : beaucoup de sites obtenaient une excellente note tout en étant pénibles à utiliser. L’INP mesure toutes les interactions de la visite et retient les plus mauvaises. Le jour du remplacement, des sites parfaitement verts sont passés à l’orange sans qu’une ligne de code ait changé.

Découper les tâches longues

Un INP dégradé vient presque toujours du JavaScript qui monopolise le fil principal. La démarche est la même partout : enregistrer une session dans le panneau des performances, repérer les tâches qui dépassent cinquante millisecondes, et regarder qui les déclenche. Les coupables habituels sont les scripts tiers, en particulier les outils de mesure d’audience, les bandeaux de consentement et les widgets de chat, ainsi que les animations recalculées à chaque défilement.

Les corrections vont du simple au structurant : différer ce qui n’est pas nécessaire au premier affichage, charger les widgets seulement quand le visiteur en approche, découper les traitements lourds en morceaux qui rendent la main au navigateur, et retirer purement et simplement les scripts que plus personne ne consulte. Sur beaucoup de sites, la suppression de deux outils oubliés fait plus que trois jours de refonte.

CLS score : supprimer les sauts de mise en page

Le CLS est le plus facile des trois à corriger, parce que ses causes sont peu nombreuses et bien identifiées. Les images sans dimensions déclarées réservent zéro pixel puis poussent le texte vers le bas. Les emplacements publicitaires et les intégrations tierces font la même chose, en pire, parce que leur hauteur varie. Les polices personnalisées provoquent un déplacement au moment où elles remplacent la police de secours, si les deux n’ont pas des métriques comparables. Enfin, les bandeaux insérés en haut de page après le chargement décalent tout ce qui suit.

Les remèdes sont mécaniques : déclarer largeur et hauteur sur chaque image et chaque iframe, réserver la place des blocs qui arrivent plus tard, ajuster le chargement des polices, et insérer les bandeaux en superposition plutôt qu’au-dessus du contenu. Une demi-journée suffit sur la plupart des sites.

Ce que ça pèse vraiment dans le classement

Autant être clair : sur une requête disputée, une page lente au contenu excellent passera devant une page rapide au contenu médiocre. Les Core Web Vitals interviennent comme un signal parmi beaucoup d’autres, et Google l’a répété. Leur intérêt est ailleurs, et il est double. Elles départagent des pages comparables, ce qui arrive plus souvent qu’on ne le croit. Et elles agissent directement sur le taux de conversion, indépendamment de tout classement : un tunnel qui répond mal fait perdre des commandes que le référencement avait apportées.

C’est pourquoi je les traite dans le même mouvement que le reste de la technique, au sein d’un audit technique SEO, et pas comme un chantier séparé mené pour faire verdir un tableau de bord.

Les erreurs à éviter

• Optimiser la note de laboratoire au lieu des données de terrain, seules retenues par Google.
• Mesurer la page d’accueil et en déduire l’état du site : ce sont les pages de catégorie et de tunnel qui rapportent.
• Empiler les extensions de performance, qui finissent par se marcher dessus et par ajouter le poids qu’elles prétendent retirer.
• Activer le chargement différé partout, y compris sur l’image de couverture.
• Juger un changement le jour même : les données de terrain sont lissées sur vingt-huit jours, il faut attendre pour conclure.