Core Web Vitals en 2026 : ce qui compte vraiment pour le ranking

Depuis mars 2024, l'Interaction to Next Paint (INP) a remplacé le First Input Delay (FID) comme métrique d'interactivité dans les Core Web Vitals. Ce changement est significatif, FID ne mesurait que la réactivité au premier clic, INP mesure toutes les interactions pendant toute la durée de la session. Mais le vrai débat n'est pas sur la liste des métriques : c'est sur le poids réel de ces métriques dans le ranking Google, que la plupart des articles surestiment.

Le poids réel des CWV dans le ranking

Google a confirmé que les Core Web Vitals sont un signal de ranking depuis 2021. Ce que les communications Google ne précisent pas toujours clairement : c'est un tie-breaker, pas un facteur dominant.

En 2022, John Mueller (Google) a déclaré lors d'un SEO Office Hours que les Core Web Vitals peuvent faire la différence quand deux pages sont "comparables à tous autres égards". Pour la grande majorité des requêtes compétitives, le contenu, les backlinks, et la pertinence topicale ont un poids nettement supérieur.

Ce qui est observable dans les données : les pages qui passent du rouge au vert sur les CWV gagnent rarement plus de 1 à 3 positions sur des requêtes à fort volume de recherche. Le gain est plus visible sur les requêtes longue traîne où la concurrence est moindre et où les signaux d'autorité sont moins déterminants.

INP : pourquoi c'est une métrique plus honnête que FID

FID avait un défaut structurel : il ne mesurait que la latence de réponse au premier clic après le chargement de la page. Une page avec un FID parfait pouvait avoir des interactions ultérieures lentes sans que ça n'impacte le score.

INP (Interaction to Next Paint) mesure la pire interaction, ou le 98e percentile des interactions, sur toute la session. Si votre application React souffre de longs traitements synchrones lors de mises à jour d'état complexes, INP le capture.

Le seuil "good" pour INP est inférieur à 200 ms. Pour référence, une application Next.js avec beaucoup de Client Components et des handlers d'événements lourds peut facilement dépasser 500 ms sur des appareils mobiles d'entrée de gamme (CPU 4x throttling dans Chrome DevTools).

Les causes principales d'INP élevé :

• Handlers d'événements qui exécutent de la logique synchrone lourde (calculs, transformations de données)
• Mises à jour de state React qui déclenchent de larges re-renders
• Long Tasks JavaScript qui bloquent le main thread pendant plus de 50 ms

Ce qui a changé en 2025-2026

Google a affiné sa collecte de données CrUX (Chrome User Experience Report) pour inclure davantage d'appareils mobiles de milieu et bas de gamme. En pratique, votre score de terrain (field data) est maintenant calculé sur un panel d'appareils plus représentatif du marché mondial, et moins biaisé vers les appareils haut de gamme des marchés développés.

Conséquence : des sites qui affichaient de bonnes métriques en 2023-2024 ont vu leur score terrain se dégrader sans changement de code. Le parc d'appareils de référence s'est élargi, pas la qualité de leur implémentation.

Pour un site B2B français ciblant des professionnels sur desktop, l'impact est limité. Pour un site e-commerce avec une part mobile significative et une audience internationale, l'effet peut être notable.

LCP : la métrique la plus actionnable

Le Largest Contentful Paint reste la métrique sur laquelle les optimisations techniques ont le plus d'impact visible. Seuil "good" : inférieur à 2,5 secondes.

Le LCP est presque toujours l'image hero ou le bloc de texte principal au-dessus de la ligne de flottaison. Les causes les plus fréquentes de LCP dégradé que nous observons en audit :

Image non priorisée. En Next.js, le composant <Image> ajoute automatiquement loading="lazy" sur les images. Si votre image hero est gérée via ce composant sans priority, elle sera chargée de manière différée, ce qui retarde le LCP.

// Incorrect pour l'image hero
<Image src="/hero.jpg" alt="Hero" width={1200} height={600} />

// Correct
<Image src="/hero.jpg" alt="Hero" width={1200} height={600} priority />

Format d'image non optimisé. Next.js sert automatiquement du WebP ou AVIF via son composant Image. Si vous utilisez des balises <img> standard ou des images CSS background pour le LCP element, vous perdez cet avantage.

Serveur lent. Un TTFB supérieur à 600 ms consomme la majorité du budget LCP avant même que le navigateur commence à charger des ressources. Les optimisations front ne compensent pas un serveur lent.

CLS : le problème sous-estimé

Le Cumulative Layout Shift est souvent traité comme un problème de fonts ou d'images sans dimensions. Ce sont les cas les plus connus, mais pas les seuls.

Sur les applications Next.js avec App Router, nous observons un CLS récurrent lié au streaming : le shell HTML est envoyé immédiatement, puis les blocs <Suspense> se résolvent et injectent du contenu. Si ces blocs ont une taille variable et sont positionnés dans le flux du document, le CLS augmente.

La solution : donner aux squelettes de chargement des dimensions similaires au contenu qu'ils remplacent, ou positionner les éléments dynamiques hors flux (position: absolute, panneau latéral) pour que leur apparition ne provoque pas de déplacement.

La vraie question : optimiser les CWV ou optimiser la performance ?

L'erreur de priorité la plus fréquente est d'optimiser pour les métriques CWV plutôt que pour la performance perçue par l'utilisateur. Ce ne sont pas toujours la même chose.

Un score de 100 en Lighthouse en labo avec un LCP de 1,2 s et un INP simulé de 80 ms ne garantit pas une bonne expérience utilisateur en conditions réelles si la latence réseau est variable, si la base de données est lente sur les requêtes complexes, ou si l'application souffre de re-renders massifs lors des interactions.

Les Core Web Vitals sont des indicateurs, pas des objectifs. L'objectif est une application qui répond vite et reste stable visuellement, mesurée en conditions terrain sur le vrai panel d'utilisateurs. Les CWV en sont une approximation utile, mais partielle.