Core Web Vitals : le guide complet 2026

Comment interpréter le LCP, l'INP et le CLS à partir des données terrain, diagnostiquer la couche responsable et améliorer l'expérience utilisateur, sans promettre de meilleur classement.

Les Core Web Vitals (CWV) sont l'ensemble de métriques de Google qui mesurent l'expérience réelle des utilisateurs : vitesse de chargement, réactivité de l'interface et stabilité visuelle. Depuis mai 2021, elles font partie de Page Experience et entrent dans le calcul du classement.

Les trois métriques sont évaluées par URL : de bons scores sur votre page d'accueil ne profiteront pas aux pages produits. Google s'appuie sur le Chrome UX Report (utilisateurs réels), et non sur des simulations en laboratoire.

Les trois métriques Core Web Vitals et leurs seuils verts. Une page est considérée comme bonne lorsque 75 % des utilisateurs réels se situent dans la zone verte.
Google évalue les CWV au seuil p75, c'est-à-dire au 75e centile. Une page est « bonne » lorsque 75 % des utilisateurs réels obtiennent une valeur dans la zone verte. Les outils de laboratoire comme Lighthouse simulent un appareil médian : ils sont utiles pour le diagnostic, mais ne donnent pas l'évaluation finale.

Qu'est-ce que les Core Web Vitals

≤ 2,5 s

LCP – bon

Élément le plus volumineux affiché

≤ 200 ms

INP – bon

L'interface a répondu à l'action

≤ 0,1

CLS – bon

Décalage de mise en page minimal

75 %

Seuil d'évaluation

Part des utilisateurs dans la zone verte

Historique : du FID à l'INP

Google a introduit les Core Web Vitals en 2020 avec trois métriques : le LCP, le FID (First Input Delay) et le CLS. Le FID mesurait le délai du premier clic ou tap : utile, mais il ne couvrait qu'une partie de l'interactivité de la page.

mai 2020Annonce des Core Web Vitals

Google introduit trois métriques : LCP, FID et CLS. Les outils commencent à prendre en charge ces nouveaux signaux.

juin 2021Mise à jour Page Experience

Les CWV entrent officiellement dans l'algorithme de classement. Le déploiement se termine en août 2021.

mars 2024FID → INP

Interaction to Next Paint remplace le First Input Delay. L'INP couvre toutes les interactions de la session, et pas seulement la première.

2025–2026L'INP en conditions réelles

Les sites riches en JavaScript (SPA, e-commerce, filtres) subissent la pression de l'INP. L'optimisation des Long Tasks devient une priorité.

LCP – Largest Contentful Paint

Le LCP enregistre le moment où le plus grand bloc de contenu visible de la page est entièrement affiché. Il s'agit généralement d'une image principale, de l'image de couverture d'un article ou d'un grand titre H1.

Valeur LCPNoteAction
≤ 2,5 sBonMaintenir, suivre dans la GSC
2,5 – 4,0 sÀ améliorerOptimiser les images, réduire le TTFB
> 4,0 sMauvaisPriorité absolue, auditer immédiatement

Causes courantes d'un LCP lent

  • TTFB lent (serveur, CDN, absence de cache) : jusqu'à 40 % du temps de LCP
  • Image principale non priorisée : attribut fetchpriority="high" absent
  • Image principale non préchargée (<link rel="preload">)
  • CSS et JS bloquants qui retardent le premier affichage
  • Images trop lourdes : pas de WebP ni d'AVIF, pas de srcset
  • Élément LCP généré par JavaScript (rendu SSR React pas encore terminé au moment du LCP)
Exemple de priorisation de la ressource LCP :
html
<!-- Prioritise the LCP image -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

<img
  src="/hero.webp"
  alt="Hero"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  width="1280"
  height="720"
/>
N'utilisez pas loading="lazy" sur les images principales : le navigateur retarde leur chargement et le LCP augmente. Réservez lazy aux images situées sous le pli.

INP – Interaction to Next Paint

INP mesure le délai entre une interaction de l'utilisateur (clic, frappe au clavier, tap) et l'affichage visuel suivant de la page. Contrairement au FID, l'INP prend en compte toutes les interactions de la session et retient le pire cas, après écrêtage des valeurs aberrantes.

Anatomie de l'INP

INP = délai d'entrée + temps de traitement + délai de présentation

Délai d'entrée (attente dans la file)jusqu'à 50 ms
Temps de traitement (gestionnaire JS)jusqu'à 100 ms
Délai de présentation (rendu et affichage)jusqu'à 50 ms

Ce qui dégrade l'INP

  • Les Long Tasks de plus de 50 ms bloquent le thread principal : le navigateur ne peut pas traiter les entrées
  • Gestionnaires d'événements lourds : setState synchrone dans React, mises à jour massives du DOM
  • Absence de scheduler.yield() ou de setTimeout(0) pour découper les longues tâches
  • Scripts tiers (chat, publicité, analytics) qui occupent le thread principal
  • Animations pilotées par JavaScript au lieu de transform et opacity en CSS
Exemple de découpage d'une Long Task avec le scheduler :
javascript
// Breaking up a Long Task with scheduler.yield()
async function processLargeList(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    // Yield to the main thread every 50 items
    if (i % 50 === 0) {
      await scheduler.yield();
    }
  }
}
scheduler.yield() est une alternative moderne à setTimeout(0). Le navigateur reprend la main, traite l'entrée utilisateur, puis reprend la tâche. Pris en charge à partir de Chrome 115 ; pour les autres navigateurs, prévoyez un polyfill basé sur setTimeout.

CLS – Cumulative Layout Shift

Le CLS est une métrique sans unité qui décrit le décalage imprévu total des éléments de la page. Formule : fraction d'impact × fraction de distance. Le déplacement d'un bouton sur lequel on vient de cliquer ne compte pas : seuls comptent les éléments qui bougent sans action de l'utilisateur.

Valeur CLSNoteCause typique
≤ 0,1BonEspace réservé pour tous les éléments
0,1 – 0,25À améliorerPolices sans font-display: swap, bannières
> 0,25MauvaisImages sans dimensions, insertions dynamiques

Principales sources de CLS

  • Images sans attributs width et height : le navigateur ne connaît pas leur taille avant le chargement
  • Polices web sans font-display: optional ou swap : le FOUT fait bouger le texte
  • Bannières et bandeaux (cookies) injectés dynamiquement en haut de page
  • Animations CSS qui modifient top, left ou margin au lieu de transform
  • Publicités sans espace réservé (min-height sur le conteneur)
Exemple de réservation d'espace pour éviter le CLS :
css
/* Reserve space for an ad slot */
.ad-container {
  min-height: 250px;
  width: 100%;
}

/* Animation without CLS: transform and opacity only */
.card:hover {
  transform: translateY(-4px);
  /* Wrong: margin-top: -4px — this shifts layout */
}

Impact sur le classement

Google confirme que les CWV font partie des signaux Page Experience pris en compte dans le classement. Mais c'est un critère départageant, et non le facteur principal. Une page au contenu solide et aux mauvais CWV devancera une page aux excellents CWV mais au contenu faible.

Effet concret des CWV : les sites dans la zone verte ont des taux de rebond plus faibles et apparaissent dans le rapport Page Experience de la Google Search Console. Test rapide : si un concurrent au contenu comparable vous devance, vérifiez ses CWV dans PageSpeed Insights.

L'effet indirect pèse davantage : des pages rapides réduisent le taux de rebond, augmentent la profondeur de session et la conversion. L'argument économique en faveur des CWV est plus fort que l'argument SEO. Amazon a constaté : +100 ms de LCP = -1 % de chiffre d'affaires.

Comment mesurer les CWV

Il existe deux types de données : les données de laboratoire (simulation avec Lighthouse, WebPageTest) et les données terrain (utilisateurs réels, avec CrUX et la GSC). Google classe les pages sur la base des données terrain. Le laboratoire sert au diagnostic.

TypeOutilCe qu'il montreCas d'usage
TerrainGoogle Search ConsoleCWV de toutes les URL du site (p75)Prioriser les pages à problème
TerrainTableau de bord CrUX (Looker)Tendances sur une fenêtre de 28 joursSuivre la progression dans le temps
LaboratoirePageSpeed InsightsLCP/INP/CLS + recommandationsDiagnostiquer une URL précise
LaboratoireLighthouse (DevTools)Cascade détaillée, traceAnalyse approfondie des causes
LaboratoireWebPageTestEnregistrement vidéo, filmstripComparaison avant et après
PageSpeed Insights affiche les deux types de données sur une même page : les données terrain (CrUX) en haut, les données de laboratoire (Lighthouse) en dessous. Utilisez les données terrain pour évaluer l'état, et les données de laboratoire pour trouver les causes.

Outils de diagnostic

OutilGratuitLCPINP
Google Search ConsoleOui✓✓
PageSpeed InsightsOui✓✓
Chrome DevToolsOui✓✓
Lighthouse CIOui✓✓
WebPageTestOui (limité)✓✓
SpeedCurvePayant✓✓
Sentry (web-vitals SDK)Freemium✓✓
CLS et données terrain pour les mêmes outils :
OutilCLSDonnées terrain
Google Search Console✓✓
PageSpeed Insights✓✓ (CrUX)
Chrome DevTools✓—
Lighthouse CI✓—
WebPageTest✓—
SpeedCurve✓✓
Sentry (web-vitals SDK)✓✓
Pour le suivi en production, ajoutez la bibliothèque JavaScript web-vitals de Google : elle collecte les CWV réels et les envoie à votre outil d'analyse (GA4, Sentry, DataDog).
javascript
// web-vitals v4 — collect real CWV
import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToAnalytics({ name, value, id }) {
  // Send to GA4
  gtag('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_id: id,
    metric_delta: value,
  });
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Liste d'optimisation

Valeurs seuils des Core Web Vitals de Google pour le LCP, l'INP et le CLS.

LCP

  • Ajoutez fetchpriority="high" et supprimez loading="lazy" sur l'image principale
  • Ajoutez <link rel="preload" as="image"> pour l'image principale dans le <head>
  • Convertissez les images en WebP ou en AVIF, et configurez srcset
  • Ramenez le TTFB à 800 ms maximum : CDN, cache, Edge SSR
  • Supprimez les scripts bloquants du <head> (async, defer, module)
  • Définissez Cache-Control: max-age=31536000 pour les ressources statiques

INP

  • Profilez les Long Tasks dans Chrome DevTools → Performance → Main Thread
  • Découpez les tâches de plus de 50 ms avec scheduler.yield() ou setTimeout(0)
  • Temporisez (debounce) les gestionnaires input et scroll (16 à 100 ms)
  • Optimisez React : useMemo, useCallback, React.memo, virtualisation des listes
  • Déplacez les scripts tiers vers des Web Workers ou chargez-les après le LCP
  • Animations CSS : transform et opacity uniquement

CLS

  • Définissez width et height sur tous les <img> : le navigateur réserve l'espace
  • Utilisez aspect-ratio pour les conteneurs dont les dimensions sont inconnues
  • Configurez font-display: optional pour les polices critiques
  • Réservez un min-height pour les emplacements publicitaires et les contenus dynamiques
  • Placez les avis (cookies, bandeaux) en bas de page, et non en haut
  • Vérifiez le FOUT : une police sans repli fait bouger le texte au chargement
Ordre de priorité : commencez par le LCP, qui est le plus souvent dans le rouge et pèse le plus lourd dans Page Experience. Une fois le LCP passé au vert, passez à l'INP (critique pour les SPA et les pages interactives), puis au CLS.
Que sont les Core Web Vitals, et pourquoi comptent-ils pour le SEO ?
Les Core Web Vitals mesurent le chargement, la réactivité et la stabilité visuelle. Google indique que les systèmes de classement les utilisent dans le cadre plus large de l'expérience de page, mais un bon score ne garantit pas de bonnes positions : la pertinence et les autres signaux restent déterminants.
Comment vérifier les Core Web Vitals de mon site ?
Utilisez le rapport Core Web Vitals de Google Search Console, PageSpeed Insights (données réelles CrUX et données de laboratoire), l'onglet Performance des outils de développement Chrome ou Lighthouse. Pour un suivi continu, intégrez la bibliothèque web-vitals.js et envoyez les données vers GA4.
Le LCP dépasse 4 secondes : à quel point est-il urgent de le corriger ?
Considérez-le comme une priorité d'expérience utilisateur et de diagnostic. Repérez l'élément LCP, son chemin de livraison et le groupe d'appareils concerné, puis vérifiez l'effet d'une modification dans les données de laboratoire et les données terrain. Ne promettez ni un gain de classement ni un délai précis à partir d'une seule correction.
Les seuils des Core Web Vitals sont-ils les mêmes sur mobile et sur ordinateur ?
Les seuils sont identiques (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1), mais les scores sont mesurés séparément. Le mobile obtient presque toujours de moins bons résultats, à cause de processeurs et de réseaux plus lents. La GSC affiche les deux segments : priorisez le mobile.
Pour l'e-commerce, qu'est-ce qui compte le plus : le LCP ou le CLS ?
Le LCP compte davantage pour les conversions : un élément principal lent sur une page produit ou une page de destination réduit directement les ventes (environ −1 % de conversion pour +0,1 s de LCP, selon les données de Google). Le CLS compte davantage pour l'UX : un bouton « Acheter » qui se déplace sous le curseur est une source directe d'abandons. Travaillez les deux en parallèle.

Check it with SpiderHead

Free and local: run the audit on your own machine.

Try it