Core Web Vitals : mesurer et améliorer LCP, INP et CLS en 2026

Les Core Web Vitals sont trois indicateurs définis par Google pour mesurer l’expérience réelle d’une page : le LCP pour le chargement, l’INP pour la réactivité et le CLS pour la stabilité visuelle. En 2026, le changement majeur reste le remplacement du FID par l’INP, effectif depuis le 12 mars 2024. Les seuils, eux, n’ont pas bougé. Ce guide fait le point sur ce qui a réellement changé, sur la manière de mesurer chaque signal avec les bons outils (PageSpeed Insights, CrUX, Lighthouse, Search Console) et sur les leviers concrets pour les améliorer, sans surestimer leur poids dans le classement.

01Core Web Vitals : définition et rôle dans le SEO

Les Core Web Vitals (en français, signaux web essentiels) sont un sous-ensemble des Web Vitals, l’initiative de Google pour fournir des indicateurs unifiés de qualité d’expérience. Chacun mesure un aspect distinct :

• LCP (Largest Contentful Paint) : temps nécessaire pour afficher le plus grand élément visible de la fenêtre (image principale, bloc de texte, vidéo).
• INP (Interaction to Next Paint) : délai entre une interaction de l’utilisateur (clic, tap, touche) et la mise à jour visuelle suivante, observé sur l’ensemble des interactions de la visite.
• CLS (Cumulative Layout Shift) : ampleur des décalages inattendus de mise en page pendant la vie de la page.

Côté SEO, Google indique que de bons Core Web Vitals vont dans le sens de ce que ses systèmes de classement cherchent à récompenser, tout en précisant dans sa documentation sur l’expérience de page que de bons résultats dans ces rapports ne garantissent pas un classement en tête. Autrement dit, ce ne sont pas des leviers qui font passer une page moyenne devant une page plus pertinente. Ils comptent surtout à pertinence comparable, et ils comptent toujours pour l’utilisateur : une page lente ou instable fait perdre des visites et des conversions, quel que soit son classement. C’est la bonne manière de les présenter à une direction : un sujet d’expérience et de conversion avec un effet SEO réel mais limité.

02Ce qui a réellement changé depuis 2024

L’INP a remplacé le FID

Le FID (First Input Delay) ne mesurait que le délai avant le traitement de la première interaction. Il ignorait le temps de traitement lui-même, l’affichage du résultat et toutes les interactions suivantes. La plupart des sites obtenaient un bon FID sans offrir pour autant une page réactive. L’INP comble ces angles morts : il observe toutes les interactions et retient une valeur représentative des plus lentes.

L’INP est devenu Core Web Vital officiel le 12 mars 2024. Chrome a ensuite mis fin au support du FID dans ses outils à partir du 10 septembre 2024 : PageSpeed Insights, API CrUX, tableau de bord CrUX et extension Web Vitals ne le remontent plus. Si un rapport ou un prestataire vous parle encore de FID en 2026, les données sont obsolètes.

Des seuils stables depuis leur introduction

Contrairement à une idée répandue, il n’y a pas de « nouveaux seuils » en 2026. Les valeurs de référence, évaluées au 75e centile des chargements de page, séparément sur mobile et sur ordinateur, sont les suivantes :

• LCP : bon jusqu’à 2,5 secondes, à améliorer jusqu’à 4 secondes, mauvais au-delà.
• INP : bon jusqu’à 200 millisecondes, à améliorer jusqu’à 500 millisecondes, mauvais au-delà.
• CLS : bon jusqu’à 0,1, à améliorer jusqu’à 0,25, mauvais au-delà.

La documentation Web Vitals de web.dev précise que les métriques stables ne changent pas plus d’une fois par an. Le 75e centile signifie que trois visites sur quatre doivent atteindre le seuil pour qu’une page ou un groupe de pages soit jugé « bon ».

Dans Search Console, le statut d’une URL pour un type d’appareil correspond à celui de sa métrique la moins bonne, comme l’explique l’aide du rapport Core Web Vitals. Une page avec un LCP et un CLS « bons » mais un INP « à améliorer » sera donc classée « à améliorer ». C’est pourquoi le passage à l’INP a pu faire basculer des sites dont le FID était bon mais l’INP ne l’était pas. Si votre rapport s’est dégradé en mars 2024 sans modification du site, vérifiez d’abord cette piste : le problème n’est pas nouveau, il était simplement invisible avec l’ancien indicateur, et la correction passe par le travail sur la réactivité décrit plus bas.

Les évolutions en cours : navigations douces et données CrUX

Deux chantiers méritent d’être suivis. Le premier concerne les applications monopage (SPA), dont les changements de vue en JavaScript ne sont pas mesurés comme de vraies navigations. Chrome teste une API de mesure des « soft navigations » : le dernier essai d’origine, annoncé le 20 avril 2026, couvre les versions 147 à 149 de Chrome. Google précise que cet essai évalue l’API elle-même, pas la façon dont ces données seront utilisées dans CrUX ou dans les outils : cette décision interviendra plus tard, et rien ne change pour l’instant dans vos données Core Web Vitals.

Le second concerne la richesse des données terrain. Depuis la version de février 2025 du Chrome UX Report, l’API CrUX fournit des informations plus fines pour diagnostiquer le LCP, comme ses sous-parties pour les images et le type de ressource concerné (texte ou image), ainsi que des données de temps aller-retour réseau (RTT). Ces ajouts ne changent pas les seuils, mais ils facilitent l’identification de la cause d’un mauvais LCP.

03Comment mesurer chaque signal

La règle de base : les données terrain (utilisateurs réels) servent à juger, les données de laboratoire (tests simulés) servent à diagnostiquer. Confondre les deux est la première source d’erreurs d’interprétation.

Données terrain : CrUX, Search Console, PageSpeed Insights

• Rapport Core Web Vitals de Search Console : regroupe les URL similaires et classe les groupes en « bon », « à améliorer » ou « mauvais », par appareil. C’est le point d’entrée pour repérer les gabarits en difficulté.
• PageSpeed Insights : affiche en haut de rapport les données CrUX de la page ou de l’origine sur les 28 derniers jours, puis un test Lighthouse en dessous. Seule la partie terrain dit si la page passe les seuils.
• CrUX : accessible par API, par tableau de bord et dans BigQuery pour suivre l’historique d’une origine et se comparer à des concurrents.

Limite importante : CrUX ne couvre que les pages et origines ayant suffisamment de trafic Chrome. Un site à faible audience peut n’avoir aucune donnée terrain.

Pour tester la performance d’une page sans vous tromper dans PageSpeed Insights, lisez le rapport dans cet ordre :

1. Vérifiez si des données terrain existent pour l’URL elle-même ou seulement pour l’origine (tout le domaine). Une donnée d’origine peut masquer un gabarit en difficulté.
2. Regardez l’évaluation globale des Core Web Vitals (réussie ou non), puis chaque métrique au 75e centile, sur mobile d’abord.
3. Descendez ensuite dans le diagnostic Lighthouse pour comprendre les causes : élément LCP identifié, tâches longues, ressources bloquantes, décalages de mise en page.
4. Répétez le test sur deux ou trois URL du même gabarit avant de conclure : un résultat isolé peut être trompeur.

Données de laboratoire : Lighthouse et DevTools

Lighthouse simule un chargement dans des conditions fixées. Il mesure bien le LCP et le CLS de chargement, mais l’INP nécessite des interactions réelles : en navigation simple, Lighthouse s’appuie sur le Total Blocking Time (TBT) comme indicateur approchant, et le mode « période » des flux utilisateur permet de mesurer l’INP sur des interactions scénarisées. Le panneau Performance de Chrome DevTools affiche par ailleurs les métriques en direct pendant que vous naviguez et cliquez : c’est l’outil le plus rapide pour reproduire un mauvais INP.

Mesure en continu avec vos propres données

Pour aller plus loin que CrUX, collectez vos propres mesures avec la bibliothèque JavaScript web-vitals de Google et envoyez-les dans votre outil d’analytics (par exemple sous forme d’événements GA4). Vous obtenez des données par page, par type d’appareil et même, pour l’INP, l’élément qui a déclenché l’interaction lente. Notre guide sur GA4 pour le SEO et les rapports à interpréter aide à structurer ces données.

Côté automatisation, un workflow n8n peut interroger chaque semaine l’API CrUX ou l’API PageSpeed Insights pour une liste d’URL représentatives de chaque gabarit, stocker les valeurs au 75e centile dans un Google Sheet et déclencher une alerte si une métrique passe au-dessus du seuil. Ce suivi s’intègre dans un dispositif plus large de monitoring SEO avec alertes de trafic, d’indexation et de positions.

04Améliorer le LCP, l’INP et le CLS

LCP : accélérer l’affichage de l’élément principal

Le LCP se décompose en quatre parties : temps de réponse du serveur (TTFB), délai avant le début du chargement de la ressource, durée de chargement de la ressource, délai de rendu de l’élément. Identifiez la partie dominante avant d’agir.

• TTFB élevé : cache serveur ou CDN, optimisation des requêtes, hébergement adapté.
• Découverte tardive de l’image LCP : image présente dans le HTML initial (pas injectée en JavaScript), attribut fetchpriority= »high », pas de chargement différé (lazy loading) sur l’image principale.
• Chargement lent : formats modernes (WebP, AVIF), dimensions adaptées à l’écran, compression.
• Rendu retardé : CSS et JavaScript bloquants, polices web qui retardent l’affichage du texte.

INP : libérer le thread principal

Une interaction lente se décompose aussi : délai d’entrée (le navigateur est occupé), durée de traitement (votre code s’exécute), délai de présentation (le navigateur recalcule et affiche). Les causes les plus fréquentes sont les scripts tiers (tags marketing, chat, A/B testing), les gestionnaires d’événements trop lourds et les mises à jour massives du DOM.

• Découper les tâches longues et céder la main au navigateur entre deux traitements.
• Afficher d’abord un retour visuel, puis exécuter le traitement lourd.
• Auditer et différer les scripts tiers, supprimer ceux qui ne servent plus.
• Réduire la taille du DOM sur les pages très longues (listes produits, filtres).

Mini-procédure pour diagnostiquer un mauvais INP : ouvrez la page dans Chrome, lancez le panneau Performance de DevTools avec un ralentissement du processeur pour simuler un mobile moyen, puis reproduisez les interactions clés (ouverture du menu, filtre, ajout au panier, bouton d’accordéon). Repérez l’interaction la plus lente, identifiez la phase qui domine (délai d’entrée, traitement ou présentation) et le script responsable. Si vos données terrain collectées avec la bibliothèque web-vitals indiquent l’élément cible des interactions lentes, commencez par celui-là : il désigne souvent un composant précis, comme un menu déroulant ou un filtre de catalogue.

CLS : stabiliser la mise en page

• Déclarer largeur et hauteur (ou un ratio) pour les images, vidéos et iframes.
• Réserver l’espace des publicités, bannières de consentement et contenus intégrés.
• Éviter d’insérer du contenu au-dessus de celui déjà affiché, sauf en réponse à une action.
• Maîtriser le chargement des polices pour limiter les changements de taille du texte.
• Rendre les pages compatibles avec le cache de navigation (bfcache), qui élimine les décalages lors d’un retour arrière.

Cas fréquent en e-commerce : une bannière promotionnelle injectée en haut de page après le chargement pousse tout le contenu vers le bas. Le correctif est simple (réserver sa hauteur dès le HTML) et fait souvent passer un gabarit entier de « mauvais » à « bon » en CLS.

Cas particulier : WordPress

Sur WordPress, les mauvais résultats viennent rarement du CMS lui-même, mais de l’empilement de thèmes lourds, de constructeurs de pages et d’extensions qui chargent leurs scripts sur toutes les pages. Quelques leviers ciblés produisent l’essentiel des gains :

• Inventaire des extensions : supprimez celles qui ne servent plus et limitez le chargement des autres aux pages où elles sont utiles.
• Cache de page et CDN : indispensables pour réduire le TTFB, surtout sur un hébergement mutualisé.
• Image mise en avant : excluez-la du chargement différé et servez-la en formats modernes, car c’est souvent l’élément LCP des articles.
• Optimisation JavaScript : les options de report ou de différé des extensions de performance améliorent souvent l’INP, mais testez-les page par page car elles peuvent casser des fonctionnalités.

05Prioriser les chantiers de performance

Tout optimiser partout n’est ni possible ni utile. Une approche en quatre temps :

1. Partir des groupes d’URL du rapport Search Console en « mauvais » sur mobile, là où le volume d’utilisateurs est souvent le plus fort.
2. Croiser avec la valeur business : pages de catégories, fiches produits, pages de service et pages d’atterrissage SEO passent avant les pages institutionnelles.
3. Traiter au niveau du gabarit : une correction de modèle de page améliore des milliers d’URL à la fois.
4. Mesurer l’effet : les données CrUX portent sur 28 jours glissants, il faut donc plusieurs semaines pour qu’une amélioration se reflète entièrement dans Search Console.

Exemple de priorisation : sur un site de services, le rapport Search Console signale un groupe de pages d’agences locales en « mauvais » pour le LCP sur mobile, et un groupe d’articles de blog « à améliorer » pour le CLS. Les pages d’agences génèrent l’essentiel des demandes de contact. Le premier chantier porte donc sur leur image d’en-tête et leur temps de réponse serveur, le second sur les emplacements publicitaires du blog. Chaque chantier a un indicateur de sortie clair : le passage du groupe d’URL en « bon » dans Search Console.

Pour rendre ces progrès lisibles par une direction, intégrez l’évolution des trois métriques par gabarit à un dashboard SEO de pilotage pour clients et direction, à côté des indicateurs de trafic et de conversion.

06Erreurs fréquentes et idées reçues

• Viser 100 dans Lighthouse : le score de laboratoire n’est pas un Core Web Vital. Une page peut avoir un score moyen et passer les trois seuils terrain, ou l’inverse.
• Tester uniquement sur ordinateur et en fibre : vos utilisateurs mobiles vivent une autre expérience.
• Attendre un bond de positions : Google ne garantit aucun classement lié aux Core Web Vitals. Mesurez aussi l’effet sur le taux de conversion et l’engagement.
• Confondre signaux d’expérience et indicateurs d’analytics : le taux de rebond ou la durée de session ne sont pas des Core Web Vitals. Sur ce sujet, voyez notre analyse du taux de rebond comme signal Google en 2026.
• Juger un site sur une seule URL : la page d’accueil est rarement représentative des fiches produits ou des articles. Testez chaque gabarit.
• Oublier les scripts tiers : ils sont souvent la première cause d’un mauvais INP et échappent à l’équipe de développement.
• Corriger sans surveiller : un nouveau tag ou une nouvelle bannière peut annuler des mois d’optimisation en une mise en production.

Les Core Web Vitals sont un sujet d’ingénierie autant que de SEO : les résultats durables viennent d’une responsabilité partagée entre SEO, développement et marketing, avec des seuils suivis en continu. Pour les replacer dans votre stratégie globale, notre page SEO présente l’approche d’ensemble.