Les core web vitals ont changé de visage depuis mars 2024, date à laquelle Google a remplacé le FID par l’INP. La plupart des contenus français consultés en 2026 décrivent encore la version 2022 et ses seuils. Résultat : des dirigeants persuadés d’être au vert, des développeurs qui optimisent une métrique morte, et des audits qui passent à côté de la vraie source de friction perçue. Cet article remet les compteurs à zéro avec les seuils 2026, la méthodologie de mesure honnête, le diagnostic des cinq pertes les plus fréquentes, et un plan en dix étapes priorisé par retour sur investissement.
Les Core Web Vitals 2026, version courte
Les Core Web Vitals (CWV) sont les trois indicateurs que Google utilise pour qualifier l’expérience perçue d’une page : la vitesse à laquelle le contenu principal apparaît, la réactivité aux interactions, et la stabilité visuelle pendant le chargement. Ils alimentent un signal de classement officiellement intégré au référencement depuis 2021, renforcé en 2024 et reconfirmé en 2026.
LCP, INP, CLS — seuils mis à jour
Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus grand élément visible. L’INP (Interaction to Next Paint) mesure la latence pire-cas entre une interaction utilisateur et le rafraîchissement visuel qui en découle. Le CLS (Cumulative Layout Shift) mesure les sauts visuels involontaires au cours du chargement. Voici les seuils en vigueur en 2026, identiques côté mobile et desktop pour les valeurs publiées par Google.
| Métrique | Good (75e percentile) | Needs improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5 s – 4,0 s | > 4,0 s |
| INP | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
À noter que le 75e percentile reste la règle. Une page n’est jugée « Good » que si trois utilisateurs sur quatre, sur 28 jours glissants, voient une métrique sous le seuil. C’est cette mécanique qui explique qu’un site rapide en laboratoire puisse rester rouge en données de terrain.
Pourquoi INP est plus dur que FID
Le FID (First Input Delay) mesurait uniquement la première interaction et seulement le délai avant que le navigateur ne réponde. L’INP, lui, mesure toutes les interactions de la session, garde la pire, et inclut le temps de traitement complet jusqu’au prochain rendu. Conséquence directe : selon les données CrUX publiées par Google en 2024, environ 36 % des sites mobiles passaient le FID mais échouaient à l’INP au moment de la bascule. Si votre application embarque un framework JavaScript lourd, vous êtes probablement dans cette zone.
- L’INP capture les
click,tapetkeydown. - Il ignore le scroll et le hover.
- Il prend la pire valeur de la session, hors valeurs aberrantes.
- Il s’agrège sur le 75e percentile à l’échelle de la page.
Mesurer correctement (et ne pas se mentir)
Données de terrain vs données de labo
Une métrique de laboratoire (Lighthouse en local, WebPageTest, PageSpeed Insights en mode lab) reproduit un environnement contrôlé : même CPU, même réseau, même viewport. Une métrique de terrain (CrUX, Search Console, RUM maison) agrège les vrais utilisateurs avec leurs vrais terminaux, leur 4G fluctuante et leur extension qui ralentit tout. Le second jeu de données est celui qui compte pour le classement Google. Le premier sert au diagnostic.
L’écart classique observé en 2026 sur un site WordPress moyen est de 1 à 1,5 seconde sur le LCP entre Lighthouse desktop et CrUX mobile. Pas un bug, juste la réalité du parc.
Search Console, CrUX, Lighthouse, RUM maison
- Search Console : rapport « Signaux web essentiels » qui agrège vos URL en bonnes, à améliorer ou médiocres. C’est la vue Google.
- CrUX : Chrome User Experience Report, accessible via PageSpeed Insights ou BigQuery. Données de terrain à 28 jours.
- Lighthouse : audit local, parfait pour reproduire un problème, pas pour qualifier un site en production.
- RUM maison : librairie
web-vitalscôté client qui pousse les valeurs vers votre analytics. Indispensable au-delà de quelques pages.
La règle pratique : Search Console pour le verdict business, RUM maison pour le suivi continu, Lighthouse pour le diagnostic ponctuel.
Diagnostiquer les pertes
Long tasks et JavaScript bloquant
Une long task est une opération qui occupe le thread principal plus de 50 ms d’affilée. C’est la cause numéro un d’un INP au-dessus de 200 ms. Tags marketing chargés en synchrone, hydratation React qui réveille toute l’application au premier clic, listeners onClick qui font appel à un module de 200 Ko : on est rarement loin du compte. L’onglet Performance de Chrome DevTools, en mode Record + Interaction, isole la coupable en quelques secondes.
Images et fonts qui sabotent le LCP
Sur un site éditorial, le LCP est presque toujours une image ou un titre qui attend sa fonte. Les pièges récurrents : image hero en lazy loading par erreur, format JPEG quand AVIF coûte trois fois moins, fonte personnalisée chargée en font-display: block qui invisibilise le texte plus de deux secondes, et absence de preload sur l’asset critique.
Layout shifts invisibles
Le CLS est rarement spectaculaire. Il vient de bandeaux cookies qui poussent le contenu, d’images sans width et height explicites, de polices qui repaginent un paragraphe au moment du swap, ou d’une bannière publicitaire injectée 800 ms après le premier rendu. La règle : tout élément susceptible d’apparaître après le premier paint doit réserver son espace.
Corriger sans tout réécrire
Priorité 1 — Lazy loading et fetchpriority
L’attribut fetchpriority="high" sur l’image LCP, combiné à un loading="eager" explicite et à un preload dans le <head>, fait gagner 300 à 800 ms de LCP sur un site WordPress moyen. Le code reste trivial.
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<img src="/hero.avif"
alt="Visuel principal de la page"
width="1600" height="900"
fetchpriority="high"
loading="eager"
decoding="async">
<img src="/article-3.avif"
alt="Illustration article"
width="800" height="450"
loading="lazy"
decoding="async">Priorité 2 — Découpage du JS et hydratation partielle
Sur un site React monolithique, l’INP s’effondre dès que le bundle dépasse 250 Ko gzippé. Le découpage par route, le dynamic import sur les blocs lourds (carrousel, éditeur, chat) et l’hydratation partielle façon îlots Astro divisent souvent l’INP par deux. Si vous repartez de zéro, jetez un œil au comparatif choisir Next.js, Astro ou SvelteKit en 2026 avant de figer un choix par habitude.
Priorité 3 — Server-side rendering sélectif
Sortir du tout-client pour le contenu critique (navigation, hero, premier paragraphe) puis hydrater le reste de manière différée gagne couramment 1 seconde de LCP sur un SPA. Les Server Components Next.js et les îlots Astro permettent ce découpage sans réécriture massive.
Priorité 4 — Critical CSS et fonts
Inliner le CSS critique du fold, charger les fontes en font-display: swap avec une fallback métrique alignée, et précharger les deux fontes les plus utilisées coupe 200 à 400 ms de LCP. Les outils comme critters ou beasties automatisent l’extraction.
Le plan en 10 étapes priorisé
Voici l’ordre que nous suivons systématiquement sur un audit, du plus rentable au plus marginal. Les colonnes effort / impact correspondent à un site moyen en e-commerce ou éditorial.
| # | Action | Métrique visée | Effort | Impact |
|---|---|---|---|---|
| 1 | Preload + fetchpriority sur l’image LCP | LCP | 30 min | Élevé |
| 2 | Conversion images en AVIF / WebP | LCP | 2 h | Élevé |
| 3 | Reserve d’espace sur images, iframes, ads | CLS | 1 h | Élevé |
| 4 | Suppression des tags marketing inutilisés | INP | 2 h | Élevé |
| 5 | Découpage du bundle JS par route | INP | 1 j | Élevé |
| 6 | font-display: swap + preload des 2 fontes critiques | LCP | 1 h | Moyen |
| 7 | Critical CSS inliné | LCP | 1 j | Moyen |
| 8 | Hydratation différée des composants non critiques | INP | 2 j | Moyen |
| 9 | CDN edge avec cache HTML court | LCP | 1 j | Moyen |
| 10 | Migration framework adapté (RSC, îlots) | LCP + INP | 1 sprint+ | Variable |
Sur un site WordPress éditorial passé récemment de Poor à Good par nos soins, les étapes 1 à 5 ont suffi à descendre le LCP mobile de 4,2 s à 2,1 s et l’INP de 480 ms à 170 ms en deux jours de travail effectif. Les étapes 6 à 10 ont sécurisé la marge sur 28 jours glissants. Comme le rappelle web.dev, « responsiveness matters as much as load speed ».
Mesurer le ROI : trafic, conversion, classement
Le gain CWV se lit sur trois axes. Le trafic organique progresse parce que le signal de classement bascule au vert, ce qui peut représenter 5 à 15 % de positions gagnées sur les requêtes concurrentielles selon les retours de la communauté SEO 2024-2026. Le taux de conversion suit, parce qu’un INP qui passe de 500 à 200 ms réduit l’abandon sur les formulaires d’environ 7 % en moyenne. Et la qualité perçue de la marque s’améliore, ce qui se traduit par des sessions plus longues et un panier moyen supérieur sur les sites e-commerce.
Pour brancher ces gains à votre stratégie SEO globale, voyez notre lecture perf web et SEO 2026. Et si vous repartez d’un projet en construction, le sujet performance se branche directement sur la stack DevOps minimum efficace et sur l’accessibilité dès le sprint 1, deux chantiers qui pèsent ensemble dans la note finale. Cela prolonge l’héritage responsive et mobile-first que nous documentions déjà au début du blog.
Questions fréquentes
Quels sont les seuils Core Web Vitals en 2026 ?
En 2026, les seuils restent ceux fixés en mars 2024. Une page est considérée Good si, au 75e percentile sur 28 jours, son LCP ne dépasse pas 2,5 s, son INP reste sous 200 ms et son CLS sous 0,1. Au-delà de 4 s de LCP, 500 ms d’INP ou 0,25 de CLS, la page est classée Poor et le signal de classement Google bascule au rouge.
Qu’est-ce que l’INP et en quoi diffère-t-il du FID ?
L’INP mesure la latence pire-cas entre une interaction utilisateur et le rafraîchissement visuel correspondant, sur l’ensemble de la session. Le FID, lui, ne regardait que la première interaction et seulement le délai d’entrée. L’INP couvre l’intégralité du traitement, ce qui durcit considérablement la barre pour les applications JavaScript chargées en hydratation lourde.
Comment mesurer ses Core Web Vitals correctement ?
Search Console donne le verdict officiel via le rapport Signaux web essentiels. PageSpeed Insights affiche les données CrUX de terrain en parallèle de Lighthouse. Pour un suivi quotidien, branchez la librairie web-vitals sur votre analytics afin de récupérer LCP, INP et CLS par session réelle. Lighthouse en local sert au diagnostic, pas au verdict.
Pourquoi mon site WordPress échoue-t-il aux Core Web Vitals ?
Trois causes reviennent quasi systématiquement : un thème lourd qui charge plus de 400 Ko de JavaScript bloquant, des images servies en JPEG sans dimensions explicites, et une accumulation de plugins qui injectent leurs scripts en synchrone. Un audit ciblé règle 80 % du problème en une journée, sans changer ni de thème ni d’hébergeur.
Les Core Web Vitals impactent-ils encore le SEO en 2026 ?
Oui, le signal Page Experience reste actif et a été reconfirmé par Google Search Central en 2025. Les core web vitals ne font pas gagner de positions seul, mais ils départagent les pages au contenu équivalent et pèsent dans les requêtes très concurrentielles. Sur un SERP serré, passer du rouge au vert vaut souvent deux à trois positions.
Votre score Lighthouse stagne malgré les efforts ? Un audit perf ciblé règle souvent 80 % du problème en une journée. Parlons-en via le formulaire de contact et nous vous indiquerons le diagnostic prioritaire pour vos core web vitals.