Core Web Vitals en 2026 : comprendre et corriger LCP, INP et CLS

Sur le terrain, pas en labo : la distinction qui change tout

C’est l’erreur la plus fréquente qu’on croise en audit : un site « validé » sur un score Lighthouse de 95, alors que ses utilisateurs réels vivent autre chose.

Lighthouse simule une visite dans des conditions fixées ; c’est un outil de diagnostic. Le classement, lui, s’appuie sur le rapport d’expérience utilisateur de Chrome (CrUX) : les mesures remontées par les vrais navigateurs de vrais visiteurs. Le seuil se juge au 75e percentile, ce qui veut dire qu’il faut que trois visites sur quatre passent, pas la moyenne.

Quand labo et terrain divergent, le terrain a raison. Et quand une page n’a pas assez de trafic pour figurer dans CrUX, Google se replie sur les données de l’origine entière ; faites pareil dans vos audits.

LCP : la plus grande chose visible doit arriver en 2,5 secondes

Le Largest Contentful Paint mesure le moment où le plus gros élément visible (image de héros, bloc de titre) finit de s’afficher. Bon : sous 2,5 s. À améliorer : jusqu’à 4 s. Mauvais : au-delà.

Dans les audits que nous voyons passer, trois causes reviennent sans cesse :

1. Une image de héros non optimisée. Format ancien, dimensions excessives, pas de priorité de chargement. Servir du WebP ou de l’AVIF correctement dimensionné, avec fetchpriority="high" sur l’élément LCP, règle une majorité de cas.
2. Un TTFB déjà lent. Si le serveur met 1,2 s à répondre, le budget est consommé avant le premier octet d’image. Cache HTML, CDN, ou tout simplement un hébergement à la hauteur.
3. Des polices web bloquantes. Une police chargée sans font-display: swap peut retenir le texte du héros. Préchargez la police du titre, affichez avec repli.

INP : la métrique qui a remplacé FID, et qui échoue le plus

L’Interaction to Next Paint a remplacé le First Input Delay en mars 2024. La différence n’est pas cosmétique : FID ne mesurait que le délai de la première interaction ; l’INP évalue toutes les interactions de la page (clics, taps, saisies) et retient globalement la pire. Bon : sous 200 ms. Mauvais : au-delà de 500 ms.

C’est aujourd’hui la vital le plus souvent en échec, et de loin. La cause dominante est presque toujours la même : trop de JavaScript qui s’exécute sur le fil principal au moment où l’utilisateur interagit. Les scripts tiers (tags marketing, chats, A/B testing) sont les suspects habituels ; chaque tag ajouté est une taxe sur l’INP de toutes les pages qui le portent.

Les corrections efficaces, dans l’ordre où nous les recommandons : inventorier et retirer les scripts tiers dont personne ne se souvient (il y en a toujours), découper les longues tâches JavaScript (yield au navigateur toutes les 50 ms), différer ce qui n’est pas nécessaire à l’interaction, et rendre les réponses visuelles immédiates même quand le traitement prend du temps.

CLS : rien ne doit bouger sous le doigt de l'utilisateur

Le Cumulative Layout Shift additionne les déplacements inattendus de mise en page. Bon : sous 0,1. Le classique : vous allez cliquer un bouton, une bannière se charge au-dessus, le bouton descend, vous cliquez autre chose.

Les remèdes sont connus et peu coûteux : des dimensions déclarées sur toutes les images et iframes, de l’espace réservé pour les publicités et les embeds, et jamais d’insertion de contenu au-dessus de ce que l’utilisateur est en train de lire. Les polices jouent aussi : un swap de police mal géré fait sauter tout un paragraphe.

Les Core Web Vitals font-elles vraiment classer ?

Oui, mais gardons la mesure : c’est un signal parmi des centaines, et un contenu supérieur avec des vitals moyennes bat un contenu creux ultra-rapide. Google le répète depuis 2021 et les tests SEO le confirment.

La bonne façon de le voir : les vitals sont rarement ce qui vous fera gagner, souvent ce qui vous empêche de perdre. Un INP à 800 ms dégrade le taux de conversion bien avant de dégrader le classement. Et pour un professionnel qui vend des refontes, un site client aux vitals rouges est un argument commercial chiffrable en trois captures d’écran.

Comment les vérifier en pratique

Trois niveaux, du plus rapide au plus complet :

1. PageSpeed Insights (pagespeed.web.dev) : entre l’URL, lisez d’abord le bloc « Découvrez ce que vivent vos utilisateurs » (terrain), ensuite seulement le score labo.
2. La Search Console, rapport Signaux Web essentiels : la liste des URLs de votre site classées bon / à améliorer / médiocre, regroupées par gabarit.
3. Un audit combiné : le rapport PimpSEO interroge l’API CrUX (les données terrain de Google, au niveau page avec repli origine) et croise ces mesures avec le reste de l’analyse : si le terrain est bon, les heuristiques labo alarmistes sont neutralisées ; s’il est mauvais, les causes probables remontent dans le plan d’action. L’audit d’une page est gratuit, sans compte.

Dernier conseil : mesurez avant de corriger, re-mesurez 28 jours après. La fenêtre glissante de CrUX impose ce délai ; les correctifs d’aujourd’hui ne se verront en entier dans les données que le mois prochain. C’est frustrant, c’est aussi ce qui rend la métrique honnête.