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.
Qu'est-ce que les Core Web Vitals
LCP – bon
Élément le plus volumineux affiché
INP – bon
L'interface a répondu à l'action
CLS – bon
Décalage de mise en page minimal
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.
Google introduit trois métriques : LCP, FID et CLS. Les outils commencent à prendre en charge ces nouveaux signaux.
Les CWV entrent officiellement dans l'algorithme de classement. Le déploiement se termine en août 2021.
Interaction to Next Paint remplace le First Input Delay. L'INP couvre toutes les interactions de la session, et pas seulement la première.
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 LCP | Note | Action |
|---|---|---|
| ≤ 2,5 s | Bon | Maintenir, suivre dans la GSC |
| 2,5 – 4,0 s | À améliorer | Optimiser les images, réduire le TTFB |
| > 4,0 s | Mauvais | Priorité 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)
<!-- 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"
/>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.
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 desetTimeout(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
transformetopacityen CSS
// 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 CLS | Note | Cause typique |
|---|---|---|
| ≤ 0,1 | Bon | Espace réservé pour tous les éléments |
| 0,1 – 0,25 | À améliorer | Polices sans font-display: swap, bannières |
| > 0,25 | Mauvais | Images sans dimensions, insertions dynamiques |
Principales sources de CLS
- Images sans attributs
widthetheight: le navigateur ne connaît pas leur taille avant le chargement - Polices web sans
font-display: optionalouswap: le FOUT fait bouger le texte - Bannières et bandeaux (cookies) injectés dynamiquement en haut de page
- Animations CSS qui modifient
top,leftoumarginau lieu detransform - Publicités sans espace réservé (
min-heightsur le conteneur)
/* 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.
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.
| Type | Outil | Ce qu'il montre | Cas d'usage |
|---|---|---|---|
| Terrain | Google Search Console | CWV de toutes les URL du site (p75) | Prioriser les pages à problème |
| Terrain | Tableau de bord CrUX (Looker) | Tendances sur une fenêtre de 28 jours | Suivre la progression dans le temps |
| Laboratoire | PageSpeed Insights | LCP/INP/CLS + recommandations | Diagnostiquer une URL précise |
| Laboratoire | Lighthouse (DevTools) | Cascade détaillée, trace | Analyse approfondie des causes |
| Laboratoire | WebPageTest | Enregistrement vidéo, filmstrip | Comparaison avant et après |
Outils de diagnostic
| Outil | Gratuit | LCP | INP |
|---|---|---|---|
| Google Search Console | Oui | ✓ | ✓ |
| PageSpeed Insights | Oui | ✓ | ✓ |
| Chrome DevTools | Oui | ✓ | ✓ |
| Lighthouse CI | Oui | ✓ | ✓ |
| WebPageTest | Oui (limité) | ✓ | ✓ |
| SpeedCurve | Payant | ✓ | ✓ |
| Sentry (web-vitals SDK) | Freemium | ✓ | ✓ |
| Outil | CLS | Données terrain |
|---|---|---|
| Google Search Console | ✓ | ✓ |
| PageSpeed Insights | ✓ | ✓ (CrUX) |
| Chrome DevTools | ✓ | — |
| Lighthouse CI | ✓ | — |
| WebPageTest | ✓ | — |
| SpeedCurve | ✓ | ✓ |
| Sentry (web-vitals SDK) | ✓ | ✓ |
// 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
LCP
- Ajoutez
fetchpriority="high"et supprimezloading="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=31536000pour 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()ousetTimeout(0) - Temporisez (debounce) les gestionnaires
inputetscroll(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 :
transformetopacityuniquement
CLS
- Définissez
widthetheightsur tous les<img>: le navigateur réserve l'espace - Utilisez
aspect-ratiopour les conteneurs dont les dimensions sont inconnues - Configurez
font-display: optionalpour les polices critiques - Réservez un
min-heightpour 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
Que sont les Core Web Vitals, et pourquoi comptent-ils pour le SEO ?
Comment vérifier les Core Web Vitals de mon site ?
Le LCP dépasse 4 secondes : à quel point est-il urgent de le corriger ?
Les seuils des Core Web Vitals sont-ils les mêmes sur mobile et sur ordinateur ?
Pour l'e-commerce, qu'est-ce qui compte le plus : le LCP ou le CLS ?
Check it with SpiderHead
Free and local: run the audit on your own machine.



