Core Web Vitals 2026 : LCP, CLS, INP expliqués

Les Core Web Vitals restent en 2026 le seul ensemble de métriques de performance que Google utilise officiellement comme signal de classement. Trois indicateurs composent l'évaluation : LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift) et INP (Interaction to Next Paint) — ce dernier ayant remplacé FID en mars 2024. Chaque métrique cible un aspect distinct de l'expérience utilisateur, depuis la vitesse perçue du chargement jusqu'à la réactivité de l'interface après interaction.

Sur les sites WordPress hébergés sur l'infrastructure LiteSpeed Tomco, le LCP médian en P75 mesure sous les 1,5 seconde — bien en deçà du seuil "bon" fixé à 2,5 secondes par Google. Ce guide détaille ce que mesure réellement chaque indicateur, comment Google collecte la donnée, pourquoi PageSpeed et Search Console peuvent diverger, et les corrections concrètes hiérarchisées par impact réel sur WordPress et e-commerce.

À retenir

• Trois métriques officielles Google : LCP, CLS, INP — INP a remplacé FID en mars 2024.
• Seuils "bon" mesurés en P75 sur 28 jours : LCP ≤ 2,5 s · CLS ≤ 0,1 · INP ≤ 200 ms.
• 30 à 40 % du LCP médian dépend du TTFB serveur — la corrélation hébergeur / Core Web Vitals reste sous-estimée.
• Sur infrastructure LiteSpeed Tomco : LCP P75 mesuré sous 1,5 s, TTFB 20-50 ms contre 200-500 ms sur Apache mutualisé.
• PageSpeed Insights ≠ Search Console : audit Lighthouse instantané vs CrUX agrégé sur 28 jours.

Sommaire

1. Ce qu'on appelle Core Web Vitals en 2026
2. LCP — Largest Contentful Paint
3. CLS — Cumulative Layout Shift
4. INP — Interaction to Next Paint
5. Mesurer ses Core Web Vitals
6. Pourquoi PageSpeed et Search Console divergent
7. Plan d'action priorisé pour WordPress
8. Questions fréquentes

Les trois Core Web Vitals en un coup d'œil

Seuils officiels Google appliqués au 75e percentile sur une fenêtre glissante de 28 jours. Une URL est "bonne" uniquement si les trois métriques le sont simultanément.

Ce qu'on appelle Core Web Vitals en 2026

Google a introduit les Core Web Vitals le 5 mai 2020 comme tentative de standardiser la mesure de la qualité technique d'une page. Trois métriques ont été retenues à l'origine — LCP, FID et CLS — venant compléter des indicateurs plus anciens comme First Contentful Paint et Time to Interactive sans les remplacer. L'inclusion comme signal de classement officiel est intervenue le 15 juin 2021 sur mobile (mise à jour Page Experience), puis en février 2022 sur desktop.

L'évolution majeure depuis : le 12 mars 2024, INP a officiellement remplacé FID dans le triptyque des Core Web Vitals. FID ne mesurait que la latence du premier input utilisateur. INP étend la mesure à l'ensemble des interactions de la session — clics, taps, saisies clavier — et retient le 75e percentile observé. Cette substitution a fait basculer 30 à 50 % des URL WordPress de "bon" à "à améliorer" sans modification de code, parce qu'INP révèle des blocages que FID masquait totalement après la première interaction.

Statut 2026 : les trois métriques sont intégrées au système Page Experience de Google et constituent un signal de classement secondaire. L'impact direct sur le ranking reste modéré comparé à la pertinence sémantique et au profil de backlinks, mais il agit indirectement via les métriques d'engagement — taux de rebond, durée de session, taux de conversion, et désormais durée d'utilisation effective (mesurée depuis Chrome). La documentation officielle Google sur les Core Web Vitals reste la source de référence sur le statut ranking factor.

LCP — Largest Contentful Paint

Le LCP (Largest Contentful Paint) mesure le délai entre le début du chargement de la page et le moment où le plus grand élément de contenu visible — image hero, bloc de texte principal, vidéo poster — est rendu dans la fenêtre. C'est l'indicateur le plus proche de la perception utilisateur du "la page est arrivée".

Sur un site WordPress moyen, l'élément LCP est l'image hero dans 65 à 75 % des cas, un titre H1 dans 15 % des cas, et un poster vidéo ou bloc texte dense dans le reste. Pour identifier précisément l'élément LCP de votre page : Chrome DevTools → Performance Insights → exécuter l'audit → l'élément est encadré en rouge dans la capture.

Ce qui pèse vraiment dans le LCP

Le LCP se décompose en quatre sous-phases mesurables :

1. TTFB (Time To First Byte) — délai serveur + réseau jusqu'au premier octet HTML. Représente 30 à 40 % du LCP final sur un site WordPress standard.
2. Resource load delay — temps entre la réception du HTML et le début du téléchargement de l'élément LCP (typiquement l'image hero).
3. Resource load duration — durée de téléchargement de la ressource LCP elle-même.
4. Element render delay — délai entre la fin du download et le rendu effectif (parsing, composition).

La règle simple : un TTFB élevé fixe un plancher infranchissable au LCP. Sur Apache mutualisé classique, le TTFB médian WordPress sans cache s'établit entre 200 et 500 ms — soit environ 10 % du budget LCP de 2,5 s consommé avant qu'un seul octet de contenu utile ne soit servi. Sur l'infrastructure LiteSpeed Tomco avec LSCache actif, le même WordPress descend à 20-50 ms de TTFB, libérant l'essentiel du budget pour le contenu. Cette corrélation hébergeur-LCP est sous-estimée dans la majorité des audits de performance.

Corrections LCP par ordre d'impact

Pattern de preload du hero recommandé depuis Chrome 73, à injecter via wp_head dans functions.php :

<link rel="preload" as="image"
      href="/wp-content/uploads/2026/hero.webp"
      imagesrcset="/wp-content/uploads/2026/hero-800.webp 800w,
                   /wp-content/uploads/2026/hero-1600.webp 1600w"
      imagesizes="100vw"
      fetchpriority="high">

L'attribut fetchpriority="high" (universellement supporté depuis 2023) demande au navigateur de traiter cette ressource avant tout autre asset non critique. Effet mesuré : -150 à -400 ms de LCP sur hero d'environ 200 KB.

Le guide pillar Optimiser un site WordPress en 2026 détaille la hiérarchie complète des leviers de performance (hébergement → cache → applicatif → CDN) et les commandes associées.

CLS — Cumulative Layout Shift

Le CLS quantifie la stabilité visuelle pendant le chargement. Il agrège les décalages de mise en page non provoqués par une interaction utilisateur, pondérés par leur surface et leur distance de déplacement. Contrairement à LCP et INP qui s'expriment en secondes ou millisecondes, CLS est un score sans unité.

Causes courantes sur WordPress

Les sources de CLS sur WordPress se concentrent sur cinq familles d'éléments :

• Images sans attributs width et height — le navigateur ne réserve aucune place avant le chargement. Quand l'image arrive, le contenu situé en dessous est repoussé. C'est la cause n°1 du CLS WordPress sur les thèmes anciens.
• Fonts custom — FOUT (Flash of Unstyled Text) — un texte initialement rendu avec une police système est repeint avec la police custom au chargement de cette dernière. Si les métriques diffèrent (chasse, hauteur de ligne), le contenu se redistribue verticalement.
• Bannières AdSense et widgets tiers chargés sans dimensions réservées — le bloc publicitaire apparaît a posteriori et pousse tout ce qui se trouve en dessous.
• Lazy load mal configuré — sans hauteur réservée, les images en lazy reproduisent le problème des images sans dimensions.
• Popups, notifications cookies, sliders dynamiques injectés dans le flux du document plutôt qu'en position absolue.

Corrections CLS

Code minimal pour éliminer 90 % du CLS WordPress — width/height explicites sur toute <img> et font-display: swap sur chaque @font-face :

<img src="/wp-content/uploads/photo.webp"
     width="1200" height="800"
     alt="..." loading="lazy">

@font-face {
  font-family: 'Inter';
  font-display: swap;          /* affiche fallback puis remplace, sans bloquer */
  src: url('/fonts/inter.woff2') format('woff2');
}

Sur les sites WordPress audités par l'équipe Tomco, l'activation seule de "Add Missing Dimensions" dans le plugin LiteSpeed Cache suffit à ramener un CLS de 0,18 à moins de 0,05 dans la majorité des cas observés. La procédure exacte est décrite dans le guide Configurer LiteSpeed Cache pour WordPress. Pour les blocs publicitaires ou widgets tiers, encadrer la zone d'injection d'un container CSS avec min-height fixe correspondant au format attendu (ex. min-height: 250px pour un slot AdSense 300×250).

INP — Interaction to Next Paint

Le INP mesure la latence entre une interaction utilisateur (clic, tap, saisie clavier) et le prochain rendu visible reflétant le résultat de cette interaction. Le navigateur calcule cette latence pour chaque interaction de la session, puis Google retient le 75e percentile observé sur la fenêtre de 28 jours.

Différence concrète avec FID

FID (First Input Delay) mesurait uniquement la première interaction et seulement son délai initial (input delay), sans tenir compte du temps de traitement ni du rendu. Sur un site avec un gros script JS bloquant chargé après la première interaction, FID restait excellent même si tout le reste de la session était lent.

INP corrige trois défauts de FID :

1. Il mesure toutes les interactions, pas seulement la première.
2. Il inclut input delay + processing time + presentation delay — la totalité du chemin entre l'event et le pixel.
3. Il retient un percentile élevé (75e) au lieu de la première occurrence.

C'est pourquoi 30 à 50 % des URL ont basculé de "bon" à "à améliorer" lors du changement, sans aucune modification applicative.

Causes INP élevé sur WordPress

• Scripts tiers : Google Analytics 4, Google Tag Manager, chats (Tidio, Crisp, Intercom), A/B testing (Optimizely, VWO) — chacun exécute du JS sur le main thread.
• Plugins lourds chargeant du JS sur toutes les pages au lieu de cibler uniquement les pages utilisatrices (formulaires Contact Form 7 sur tout le site, sliders Slider Revolution chargés partout).
• Theme builders (Elementor, Divi, WPBakery, Avada) générant des bundles JS volumineux et synchrones.
• Long tasks > 50 ms qui bloquent le main thread quand une interaction utilisateur arrive.

Corrections INP

Sur un site WooCommerce avec 35 plugins actifs et thème Elementor audité par l'équipe Tomco, l'INP a chuté de 480 ms à 180 ms en désactivant 8 plugins non utilisés et en différant 3 scripts tiers — sans aucune modification du thème. Outil de diagnostic recommandé : ouvrir Chrome DevTools → onglet Performance → enregistrer une session de 15 secondes en cliquant sur les éléments interactifs. Les "long tasks" apparaissent en rouge dans la timeline et identifient le script bloquant.

Mesurer ses Core Web Vitals

Quatre sources de données complémentaires existent. Comprendre quand utiliser chacune est plus utile que la donnée elle-même.

Field data vs lab data

CrUX est la source que Google utilise pour ses propres décisions de classement. Les données sont collectées via Chrome et les navigateurs Chromium dérivés, sur les utilisateurs ayant activé la remontée de statistiques. La documentation Chrome User Experience Report détaille les seuils minimum de trafic pour qu'une URL apparaisse (quelques centaines de visites mensuelles par origine).

Lighthouse en mode lab simule un Moto G Power sur Slow 4G. Le score Lighthouse global n'est pas un Core Web Vital — c'est une note synthétique pondérée. Utile pour itérer rapidement (audit en 30 secondes), inutile pour valider la perception réelle.

Outils par cas d'usage

• PageSpeed Insights — combine CrUX (si disponible) et Lighthouse sur la même URL. Premier réflexe pour un diagnostic ponctuel.
• Search Console — Core Web Vitals — vue agrégée par groupes d'URL similaires sur votre propriété vérifiée. Indispensable pour identifier les patterns problématiques.
• Web Vitals Chrome Extension — overlay temps réel des trois métriques pendant la navigation.
• Librairie web-vitals JS (github.com/GoogleChrome/web-vitals) — instrumenter votre site et envoyer les mesures vers Google Analytics, Matomo ou un endpoint maison.

Snippet d'instrumentation web-vitals minimaliste pour collecter ses propres données field :

import { onLCP, onCLS, onINP } from 'web-vitals';

function send(metric) {
  fetch('/api/web-vitals', {
    method: 'POST',
    body: JSON.stringify({
      name:  metric.name,
      value: metric.value,
      id:    metric.id,
      url:   location.pathname,
    }),
    keepalive: true,
  });
}

onLCP(send);
onCLS(send);
onINP(send);

Cette approche RUM (Real User Monitoring) fournit des données field indépendantes de CrUX, accessibles immédiatement et segmentables par page, géographie, type d'appareil ou parcours utilisateur.

Pourquoi PageSpeed et Search Console divergent

Question récurrente : "PageSpeed affiche un score de 95 sur ma page, mais Search Console signale des URL en échec." La divergence est attendue et s'explique par cinq facteurs.

1. Type de donnée affichée. PageSpeed expose deux blocs distincts : "Discover what your real users are experiencing" (CrUX, field) et "Diagnose performance issues" (Lighthouse, lab). Les jauges en haut de page reflètent CrUX — la même source que Search Console. Le score Lighthouse en bas est synthétique.

2. Fenêtre temporelle. PageSpeed CrUX agrège sur 28 jours glissants se terminant la veille. Search Console applique la même fenêtre mais avec 1 à 2 jours de latence supplémentaire dans son pipeline. Une correction déployée hier n'est pleinement visible qu'après 28 jours.

3. Granularité d'agrégation. PageSpeed mesure une URL exacte. Search Console regroupe les URL similaires en patterns ("groupes d'URL") puis calcule la métrique sur l'ensemble du pattern. Une URL peut passer en vert tandis que son pattern reste en rouge à cause d'autres URL du groupe.

4. Trafic minimum requis. Sous quelques centaines de visites Chrome mensuelles, CrUX ne dispose pas d'assez de données. PageSpeed affiche "Insufficient real-world data" et seule la lab data est visible. Search Console ne fait remonter cette URL dans aucun rapport.

5. Lab data ≠ utilisateurs réels. Lighthouse simule un Moto G Power sur 4G ralentie. Vos utilisateurs naviguent depuis iPhone 15 Pro en 5G, PC fibre, ou téléphone d'entrée de gamme en 3G urbaine. La distribution réelle influe lourdement sur le P75 CrUX.

Règle pratique : pour le classement SEO, seul Search Console compte. Pour itérer rapidement, PageSpeed Lighthouse fournit un feedback en 30 secondes. Pour valider en condition réelle sans attendre 28 jours, instrumenter en RUM avec web-vitals JS.

Plan d'action priorisé pour WordPress

L'ordre d'attaque proposé est calibré sur les sites WordPress audités en production. Les gains indiqués sont des médianes observées, à pondérer selon l'état initial.

Étape 1 — Hébergement (TTFB). Levier le plus impactant et le plus négligé. Migrer vers une infrastructure LiteSpeed Enterprise avec NVMe Gen4 réduit le TTFB de 80 à 90 % et libère 200 à 500 ms sur le LCP. L'hébergement web Tomco inclut LiteSpeed sans surcoût sur toutes les formules.

Étape 2 — Cache serveur (LSCache). Activer le plugin LiteSpeed Cache et configurer les exclusions critiques (/cart, /checkout, /wp-admin). Gain LCP : 2 à 4 secondes sur un site WordPress non caché.

Étape 3 — Image hero. Convertir en WebP, dimensions explicites, exclure du lazy load, ajouter <link rel="preload" as="image" fetchpriority="high">. Gain LCP : 300 à 800 ms.

Étape 4 — Fonts custom. Limiter à 2 fonts maximum, font-display: swap, preload des .woff2 critiques. Gain combiné LCP + CLS.

Étape 5 — Audit plugins. Désactiver les plugins sans usage explicite. Identifier ceux qui chargent du JS sur toutes les pages alors qu'ils ne servent qu'une fonctionnalité ponctuelle (formulaire, comparateur, slider non affiché). Gain INP : 100 à 300 ms.

Étape 6 — Scripts tiers. Charger analytics, chat et tag manager en defer ou async. Auditer Google Tag Manager — un seul GTM peut injecter 10 scripts à la suite et grever l'INP. Gain INP et LCP combinés.

Étape 7 — Monitoring continu. Instrumenter avec web-vitals JS et envoyer les métriques vers GA4 ou un endpoint custom. Détecter les régressions avant qu'elles n'apparaissent dans Search Console (gain de 28 jours sur le délai de feedback).

Tableau récapitulatif des gains cumulés observés sur un échantillon de 12 sites WordPress migrés vers l'infrastructure Tomco LiteSpeed :

La référence officielle Google sur les Core Web Vitals reste le guide web.dev/vitals, maintenu par l'équipe Chrome DevRel et synchronisé avec les évolutions du système Page Experience.