Core Web Vitals : comprendre et optimiser LCP, INP et CLS (2026)

« Vos Core Web Vitals sont dans le rouge. » Cette phrase, on l'entend souvent, mais elle ne veut rien dire tant qu'on n'a pas compris ce qui se cache derrière. Les Core Web Vitals ne sont pas un score abstrait sorti d'un outil : ils traduisent, en chiffres, ce que ressent une personne réelle quand elle ouvre votre page. Une page qui met du temps à s'afficher, un bouton qui ne répond pas, un texte qui saute pendant la lecture — voilà ce qu'ils mesurent. Ce guide vous explique chaque métrique, comment la lire, et par où commencer.

Que sont les Core Web Vitals ?

Les Core Web Vitals sont un ensemble de trois indicateurs définis par Google pour mesurer l'expérience utilisateur d'une page web. Ils font partie des signaux de classement : à contenu comparable, une page rapide et stable est mieux placée qu'une page lente et instable. Ils ne remplacent pas la pertinence ni les liens, mais ils départagent.

Chaque métrique cible une dimension précise de l'expérience : le chargement (LCP), la réactivité (INP) et la stabilité visuelle (CLS). Prises ensemble, elles décrivent ce que vit un visiteur entre le moment où il clique sur votre lien et celui où il peut vraiment utiliser la page. Voyons-les une par une.

LCP (Largest Contentful Paint) — le temps d'affichage

Le LCP mesure le temps qu'il faut pour afficher le plus gros élément visible de la page dans la fenêtre du navigateur : le plus souvent une grande image, une vidéo ou un bloc de texte principal. C'est un bon proxy du moment où l'internaute a l'impression que « la page est chargée ».

Le seuil : un bon LCP est sous 2,5 secondes. Au-delà, l'expérience se dégrade, et le visiteur risque de repartir avant même d'avoir vu votre contenu.

Ce qui plombe le LCP est souvent en amont de l'affichage : un temps de réponse serveur (TTFB) trop lent. Si le serveur met une seconde à renvoyer la page, le navigateur n'a même pas commencé à dessiner l'élément principal. Vient ensuite le poids de l'élément lui-même (une image lourde et non optimisée) et la façon dont il est chargé. On y revient dans les leviers.

INP (Interaction to Next Paint) — la réactivité

L'INP mesure la réactivité de la page : quand l'internaute clique, tape ou touche un élément, combien de temps s'écoule avant que l'écran réponde visuellement ? Il évalue l'ensemble des interactions sur la durée de la visite, pas seulement la première.

C'est un changement important : l'INP a remplacé le FID (First Input Delay) en 2024 comme Core Web Vital officielle. Le FID ne mesurait que le délai de la toute première interaction ; l'INP est plus exigeant et plus représentatif de l'expérience réelle.

Le seuil : un bon INP est sous 200 millisecondes. Et c'est là que le bât blesse : l'INP est la Core Web Vital la plus souvent ratée. Environ 43% des sites échouent au seuil des 200 ms. La cause principale : un excès de JavaScript qui monopolise le fil principal du navigateur et l'empêche de répondre aux clics.

CLS (Cumulative Layout Shift) — la stabilité visuelle

Le CLS mesure la stabilité visuelle de la page : les éléments bougent-ils de manière inattendue pendant le chargement ? Vous connaissez la sensation — vous allez cliquer sur un lien, une image se charge au-dessus, tout se décale, et vous cliquez sur le mauvais bouton. C'est exactement ce que le CLS pénalise.

Le seuil : un bon CLS est sous 0,1. À la différence des deux autres, ce n'est pas une durée mais un score sans unité, qui additionne l'ampleur des décalages inattendus.

La bonne nouvelle : le CLS est souvent la métrique la plus simple à corriger. La plupart des sauts viennent d'éléments dont le navigateur ne connaît pas la taille à l'avance — images sans dimensions, publicités, bannières, polices qui se substituent. Réserver l'espace à l'avance règle l'essentiel.

Comment les mesurer

Avant d'optimiser, il faut mesurer correctement — et surtout comprendre qu'il existe deux types de données qui ne racontent pas la même histoire.

• Les données terrain (field data), issues du rapport CrUX (Chrome User Experience Report). Elles reflètent ce que vivent vos vrais utilisateurs, sur leurs vrais appareils et connexions, sur les 28 derniers jours. C'est cette donnée que Google utilise pour le classement.
• Les données labo (lab data), issues d'un test ponctuel dans un environnement simulé. Utiles pour diagnostiquer et reproduire un problème, mais elles ne représentent qu'une seule mesure, dans des conditions données.

La distinction est cruciale : un bon score en labo n'empêche pas d'échouer sur le terrain, et inversement. Pour piloter votre SEO, c'est le terrain qui compte.

Les trois outils à connaître :

• PageSpeed Insights — affiche à la fois les données terrain (si disponibles) et un test labo, page par page.
• Le rapport Core Web Vitals de la Search Console — la vue d'ensemble de votre site, groupée par type de page, à partir des données terrain.
• Lighthouse — intégré aux outils de développement de Chrome, idéal pour un audit labo détaillé pendant les corrections.

La bonne méthode : repérer les groupes de pages en échec dans la Search Console, puis diagnostiquer une page représentative avec PageSpeed Insights et Lighthouse. Cette logique s'inscrit dans un audit SEO plus large, où la performance est l'un des chantiers techniques.

Les leviers universels d'optimisation

Chaque métrique a ses propres leviers. La bonne nouvelle : ils sont valables sur n'importe quel site, quelle que soit la technologie. On corrige métrique par métrique.

Améliorer le LCP

• Précharger l'image LCP pour que le navigateur la récupère en priorité, sans attendre.
• Extraire le CSS critique et charger le reste plus tard, pour afficher l'essentiel au plus vite.
• Un bon hébergement et un cache efficace pour réduire le temps de réponse serveur (TTFB).
• Des images modernes en WebP ou AVIF, correctement dimensionnées, pour alléger l'élément principal.
• Un CDN pour rapprocher vos fichiers de vos visiteurs, où qu'ils soient.

Améliorer l'INP

• Alléger et différer le JavaScript : c'est le premier coupable. Moins de code exécuté, c'est un fil principal libre pour répondre aux clics.
• Limiter les scripts tiers (widgets, chats, trackers, pixels publicitaires) qui s'accumulent et bloquent l'interactivité.

Améliorer le CLS

• Déclarer les dimensions (width et height) sur les images, vidéos et iframes, pour que le navigateur réserve l'espace à l'avance.
• Réserver l'espace des bannières, encarts et éléments injectés après coup.
• Utiliser font-display: swap pour éviter les sauts de texte au chargement des polices.

Et sur WordPress ?

Les principes ci-dessus valent pour tous les sites. Mais leur mise en œuvre change selon la technologie — et sur WordPress, elle passe par des choix bien précis : le choix de l'hébergement, les plugins de cache et de performance, et la gestion du poids ajouté par les page builders comme Elementor ou Divi.

Comme ces correctifs sont spécifiques à l'écosystème WordPress, nous les détaillons dans un guide dédié plutôt que de les mélanger ici : Accélérer WordPress. Vous y trouverez les réglages concrets, plugin par plugin, pour repasser au vert.

Que vous soyez sur WordPress ou non, la démarche reste la même : mesurer sur le terrain, isoler la métrique en échec, appliquer le bon levier. C'est le cœur du travail de notre SEO technique, et l'un des piliers de toute agence SEO sérieuse.

Questions fréquentes