Performance

Core Web Vitals en 2026 : ce qui a changé et comment réussir

Les trois Core Web Vitals — LCP, INP et CLS — expliqués avec leurs seuils 2026, pourquoi l'INP fait échouer la plupart des sites, et les correctifs qui comptent.

SeoraMis à jour le 22 juin 20263 min de lecture

Les Core Web Vitals sont trois mesures de terrain que Google utilise pour évaluer l'expérience réelle d'une page : le Largest Contentful Paint (chargement), l'Interaction to Next Paint (réactivité) et le Cumulative Layout Shift (stabilité visuelle). Une page réussit lorsque les trois se situent dans la plage « bonne » au 75e centile des visites réelles — LCP sous 2,5 s, INP sous 200 ms et CLS sous 0,1. C'est un signal de classement léger, mais surtout le reflet des frictions qui font fuir les visiteurs.

Les trois mesures qui comptent

LCP (Largest Contentful Paint) — le temps avant l'affichage du plus grand élément visible. Bon : ≤ 2,5 s.

INP (Interaction to Next Paint) — la vitesse de réaction de la page aux clics, touchers et frappes, sur toute la visite. Bon : ≤ 200 ms.

CLS (Cumulative Layout Shift) — l'ampleur des sauts de mise en page pendant le chargement. Bon : ≤ 0,1.

Le grand changement, c'est l'INP. Le 12 mars 2024, il a remplacé le First Input Delay parmi les Core Web Vitals, et c'est désormais la mesure que la plupart des sites échouent — environ deux URL sur cinq dépassent encore la barre des 200 ms. Là où le FID ne mesurait que le délai avant la première interaction, l'INP surveille chaque interaction et rapporte une latence proche du pire cas : menus, filtres et formulaires lents n'ont plus où se cacher.

Comment Google vous note réellement

Deux points surprennent. D'abord, la note vient de données de terrain, pas d'un test en laboratoire : elle provient du Chrome User Experience Report — de vrais utilisateurs Chrome, sur de vrais appareils et réseaux —, si bien qu'un portable rapide peut réussir une page que les téléphones réels échouent. Ensuite, un groupe d'URL n'obtient le statut « bon » que si au moins 75 % des visites atteignent le bon seuil pour les trois mesures à la fois. Visez votre quartile le plus lent, sur le matériel qu'utilise vraiment votre audience.

Corriger l'INP — la mesure que la plupart des sites échouent

Fractionnez les tâches longues. Tout ce qui dépasse 50 ms sur le fil principal bloque l'interaction — découpez le travail et rendez la main au navigateur entre les blocs.

Expédiez moins de JavaScript. Fractionnez le code, différez les scripts non critiques et supprimez les balises tierces inutilisées ; chaque kilo-octet analysé est du temps où le fil principal ne peut répondre.

Gardez les gestionnaires d'événements légers. Faites d'abord la mise à jour visuelle, puis différez le travail lourd (analytique, appels réseau) après le prochain affichage.

Évitez les rendus synchrones massifs. Mémoïsez les composants coûteux et virtualisez les longues listes pour qu'un seul clic ne réaffiche pas toute la page.

Gains rapides pour le LCP et le CLS

Préchargez l'image ou la police du LCP, servez des formats modernes (AVIF/WebP) et assurez-vous que l'élément principal n'attend pas derrière du CSS ou du JS bloquant le rendu.

Donnez aux images et intégrations une largeur/hauteur explicite (ou une boîte à ratio d'aspect) pour que rien ne se décale au chargement.

Réservez l'espace des publicités, bannières et éléments injectés tardivement au lieu de les laisser pousser le contenu vers le bas.

Là où Seora intervient

L'audit de Seora lit vos Core Web Vitals réels, repère l'élément exact qui plombe le LCP ou le script qui dévore votre budget INP, et rédige le correctif pour vous. Voyez-le du côté performance d'un audit ou commencez gratuitement.

Traitez les Core Web Vitals comme une habitude de qualité produit, pas un nettoyage ponctuel. Mesurez sur le terrain, corrigez vos 25 % les plus lents et revérifiez après chaque livraison — la boucle qui vous garde rapide vous garde aussi bien classé. Ensuite, rendez ces pages rapides faciles à trouver grâce à une structure de liens internes réfléchie.