Technique12 min de lecture

Core Web Vitals 2026

LCP, INP, CLS expliqués. Seuils 2026, mesure, optimisations concrètes. INP a remplacé FID en mars 2024.

TL;DR

Trois métriques : LCP < 2,5 s (chargement), INP < 200 ms (réactivité, remplace FID depuis mars 2024), CLS < 0,1 (stabilité visuelle). Mesurer sur Field Data CrUX (75ᵉ percentile mobile), pas sur Lab Data Lighthouse. Signal de ranking depuis juin 2021. Impact direct modéré, indirect massif (CTR, dwell time, conversions). Optimisations : thème léger, cache, images optimisées, défer JS non-critique.

Par Mattis Bétourné, fondateur d'Yvarn (ex-dev senior Thales / Capgemini / Betclic)

Cet article s'adresse aux développeurs, lead techniques et propriétaires de sites qui veulent comprendre et optimiser leurs Core Web Vitals concrètement.

1. Les 3 métriques Core Web Vitals

Les Core Web Vitals sont un ensemble de trois métriques publiées par Google sur web.dev en mai 2020 et intégrées au ranking depuis le Page Experience update de juin 2021.

LCP — Largest Contentful Paint

Mesure le temps avant l'affichage du plus gros élément visible au-dessus du fold (image hero, bloc de texte principal, vidéo). C'est le proxy "à quelle vitesse la page semble-t-elle chargée".

INP — Interaction to Next Paint

Mesure la réactivité du site aux interactions utilisateur. Pour chaque clic, tap, ou touche pressée, le temps entre l'action et la prochaine peinture visible. Officiellement remplaçant de FID depuis mars 2024.

CLS — Cumulative Layout Shift

Mesure les décalages visuels imprévus pendant le chargement (image qui pousse le texte, bannière qui apparaît, font swap visible). Calcul : somme des shifts × distance déplacée. Sans dimension, un score normalisé.

2. Seuils Core Web Vitals 2026

MétriqueGoodNeeds ImprovementPoor
LCP< 2,5 s2,5-4 s> 4 s
INP< 200 ms200-500 ms> 500 ms
CLS< 0,10,1-0,25> 0,25

Pour qu'une URL soit "approved" Core Web Vitals : les 3 métriques doivent être "Good" au 75ᵉ percentile mobile sur 28 jours glissants. Source : documentation officielle web.dev.

3. Field Data vs Lab Data

Distinction critique souvent confuse :

Field Data (CrUX)

Données réelles agrégées par Chrome User Experience Report sur les utilisateurs Chrome qui ont activé le partage de statistiques. Fenêtre glissante 28 jours, exposé via PageSpeed Insights et Google Search Console. C'est le score qui compte pour le ranking. Documentation : Chrome CrUX.

Lab Data (Lighthouse, WebPageTest)

Simulation d'une session unique dans un environnement contrôlé. Utile pour le debug (identifier ce qui ralentit, tester un fix), pas pour le ranking. Le score Lighthouse 100 ne garantit pas un score CrUX 100 si l'audience réelle a des conditions réseau ou device différentes.

Règle pratique : tracker Field Data hebdo (GSC + PageSpeed Insights). Utiliser Lab Data uniquement quand on debug un problème spécifique ou qu'on teste une optimisation avant déploiement.

4. Optimisations concrètes

Par métrique, les leviers qui marchent vraiment :

Améliorer le LCP

  • Préchargement de l'image hero : <link rel="preload" as="image" href="...">
  • Images optimisées WebP/AVIF, dimensions explicites, lazy loading uniquement below-the-fold
  • CDN edge (Cloudflare, Vercel, Fastly) pour réduire le TTFB
  • Server-side rendering au lieu de SPA pour éviter le rendu JS différé
  • Fonts auto-hébergées avec font-display: swap

Améliorer l'INP

  • Réduire le JavaScript bloquant (code splitting, lazy load non-critique)
  • Différer les scripts tiers (Tag Manager, analytics, chats)
  • Utiliser requestIdleCallback pour les tâches non-urgentes
  • Éviter les setTimeout et boucles longues sur le thread principal
  • Web Workers pour les calculs lourds

Améliorer le CLS

  • Dimensions explicites sur toutes les images et iframes (width + height)
  • Réserver l'espace pour les pubs, embeds, et notifications avant leur chargement
  • Éviter les insertions dynamiques de contenu au-dessus du fold
  • Fonts avec size-adjust ou font-display: optional si possible
  • aspect-ratio CSS sur containers dont le contenu se charge async

5. Erreurs fréquentes

  1. 01
    Optimiser sur Lab Data uniquement. Lighthouse score 100 mais Field Data CrUX rouge. C'est le terrain qui compte, pas le simulateur.
  2. 02
    Lazy loading agressif sur le hero. Image au-dessus du fold avec loading="lazy" = LCP catastrophique. Lazy uniquement below-the-fold.
  3. 03
    Ignorer mobile. Le score qui compte est mobile (75ᵉ percentile). Les optimisations desktop ne suffisent pas si le mobile reste rouge.
  4. 04
    Trop de Tag Manager et scripts tiers. Chaque tag ajoute du JS. Auditer dans Chrome DevTools Coverage, supprimer le mort.
  5. 05
    Mesurer une seule fois. CrUX a 28 jours de lag. Une optimisation déployée aujourd'hui apparaît dans le Field Data à J+14-28. Patience.
Pour aller plus loin

FAQ — Core Web Vitals

01C'est quoi les Core Web Vitals ?
Les Core Web Vitals sont trois métriques de Google mesurant l'expérience utilisateur sur une page : LCP (Largest Contentful Paint, vitesse de chargement du plus gros élément), INP (Interaction to Next Paint, réactivité aux interactions), CLS (Cumulative Layout Shift, stabilité visuelle). Signal de ranking depuis 2021.
02Pourquoi INP a-t-il remplacé FID ?
FID (First Input Delay) ne mesurait que la première interaction utilisateur, ce qui sous-estimait les vrais problèmes de réactivité. INP, devenu officiel en mars 2024, mesure toutes les interactions de la visite et garde la pire. Plus représentatif de l'expérience réelle. Source : Chrome Dev Blog.
03Quels sont les seuils Core Web Vitals en 2026 ?
Seuils "Good" inchangés depuis 2024 : LCP < 2,5 s, INP < 200 ms, CLS < 0,1. Seuils "Needs Improvement" : LCP 2,5-4 s, INP 200-500 ms, CLS 0,1-0,25. Au-delà : "Poor". Mesurer sur 75ᵉ percentile mobile (le pire 25 % de l'audience).
04Field Data ou Lab Data : que regarder ?
Field Data (CrUX) reflète l'expérience réelle des utilisateurs Chrome sur 28 jours. C'est le score qui compte pour Google ranking. Lab Data (Lighthouse) simule une session idéale, utile pour le debug mais pas pour le ranking. Toujours prioriser le Field Data pour les décisions business.
05Combien coûte une optimisation CWV complète ?
Variable selon la dette. Site WordPress avec thème lourd et 200 plugins : 5-15 jours de dev pour passer au vert (4 000-12 000 €). Site Nuxt/Next bien architecturé : 1-3 jours suffisent souvent (800-2 400 €). Audit CWV ponctuel chez Yvarn dans le mandat Standard, ou audit dédié ~1 490 €.
06CWS Vitals impactent-ils vraiment le ranking ?
Oui, signal confirmé par Google depuis le Page Experience update (juin 2021). Impact modéré sur le ranking direct (un site rapide ne battra pas un site avec meilleur contenu), mais critique en tie-breaker. Et impact massif indirect : meilleur taux de conversion, meilleur dwell time, signaux comportementaux positifs.

En résumé

Les Core Web Vitals sont un signal SEO modéré mais critique en tie-breaker. Plus important encore : leur impact indirect sur les conversions, le dwell time, et les signaux comportementaux. Un site rapide n'est pas optionnel en 2026.

Yvarn.fr lui-même affiche Performance 99/100, LCP 0,9 s, CLS 0,014 sur PageSpeed Insights mobile. La stack Nuxt 4 + Tailwind v4 + fonts self-hosted permet de livrer du premium sans effort additionnel.

· audit CWV

SEO technique Yvarn

Audit Core Web Vitals + Lighthouse + plan d'action 90 jours. Particulièrement pertinent pour les sites WordPress lourds ou les SPA legacy.

Découvrir SEO technique Yvarn
Mattis Bétourné, fondateur d'Yvarn
Mattis Bétourné

Fondateur d'Yvarn, agence SEO à Bordeaux. À propos.