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

Les Core Web Vitals sont les trois métriques terrain que Google utilise pour mesurer l'expérience réelle des utilisateurs : Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Pour réussir en 2026, vous devez atteindre un LCP sous 2,5 secondes, un INP sous 200 millisecondes et un CLS sous 0,1 — mesurés au 75e centile de vos visiteurs réels, et non en laboratoire.

Ce sont un véritable signal de classement Google (quoique modeste), et au-delà du classement, ils reflètent la rapidité, la réactivité et la stabilité ressenties d'une page. Ce guide décompose chaque métrique, son seuil exact en 2026 et l'unique correctif le plus efficace pour faire bouger le chiffre.

Les trois Core Web Vitals et leurs objectifs pour 2026

Les Core Web Vitals sont trois métriques terrain, chacune ayant un seuil « bon » que vous devez dépasser au 75e centile de votre trafic :

• LCP (Largest Contentful Paint) — le temps nécessaire pour que le plus grand élément visible (une image principale, un bloc de titre ou l'affiche d'une vidéo) s'affiche. Bon : sous 2,5 secondes.
• INP (Interaction to Next Paint) — la rapidité avec laquelle la page réagit visuellement aux appuis, clics et frappes clavier. Bon : sous 200 millisecondes.
• CLS (Cumulative Layout Shift) — l'ampleur avec laquelle le contenu visible saute de manière inattendue pendant le chargement. Bon : sous 0,1.

Le piège, c'est le 75e centile : il reflète le quart le plus lent de vos visites, et non la moyenne, et le mobile et l'ordinateur de bureau sont évalués séparément. Chaque métrique possède aussi des plages « à améliorer » et « médiocre » — par exemple, un LCP entre 2,5 s et 4 s est à améliorer, et au-delà de 4 s il est médiocre — si bien qu'un seul modèle lent ou une seule catégorie d'appareils peut faire sortir du vert un site par ailleurs rapide.

LCP sous 2,5 s : chargez votre contenu principal rapidement

Le LCP marque le moment où votre contenu principal devient visible. Sur la plupart des pages, l'élément LCP est une image principale, un grand titre ou une image d'arrière-plan. Il se décompose en quatre parties : le temps jusqu'au premier octet (TTFB), le délai de chargement de la ressource, le temps de chargement de la ressource et le délai de rendu de l'élément. Sur les sites réels, le plus grand coupable est généralement le délai de chargement — le navigateur découvre trop tard l'image importante parce qu'elle est en chargement différé ou dissimulée dans le CSS.

Le correctif le plus efficace

Rendez la ressource LCP détectable et prioritaire. Ne mettez jamais en chargement différé l'élément visible au premier affichage. Préchargez-le plutôt, ajoutez fetchpriority="high" à l'image, servez-la dans un format moderne (WebP ou AVIF) depuis un CDN, et supprimez le CSS et le JavaScript bloquant le rendu qui retardent l'affichage. Ensemble, ces mesures permettent régulièrement de gagner une seconde ou plus sans aucune modification serveur.

INP sous 200 ms : gardez la page réactive

L'INP a remplacé le First Input Delay (FID) comme Core Web Vital en mars 2024, et il est bien plus exigeant. Le FID ne mesurait que le délai avant le traitement de la première interaction ; l'INP surveille presque chaque appui, clic et frappe clavier sur toute la visite et rapporte une valeur proche de votre pire réponse. Chaque interaction comporte trois phases : le délai d'entrée, le temps de traitement et le délai de présentation.

Le correctif le plus efficace

Fractionnez les longues tâches JavaScript afin que le thread principal reste libre de répondre. Toute tâche de plus de 50 ms bloque l'interaction, alors divisez le travail lourd et rendez la main au navigateur avec scheduler.yield() ou un timeout, différez les scripts non critiques, et auditez les balises tierces — widgets de chat, analytics et scripts publicitaires — qui accaparent le thread principal. Moins de JavaScript, exécuté en plus petits morceaux, est presque toujours la solution.

CLS sous 0,1 : empêchez la page de sauter

Le CLS évalue les mouvements inattendus. Chaque décalage est pondéré selon la proportion de l'écran qui a bougé et la distance parcourue, puis additionné sur le pire groupe de décalages durant la visite. Les causes habituelles sont les images, vidéos, iframes et publicités sans espace réservé, le contenu injecté au-dessus de ce que le lecteur consulte déjà, et les polices web qui recomposent le texte lorsqu'elles se substituent.

Le correctif le plus efficace

Réservez l'espace avant que le contenu n'arrive. Définissez des attributs explicites de width et de height (ou un aspect-ratio CSS) sur chaque image, vidéo et contenu intégré, donnez aux emplacements de publicités et de widgets une min-height fixe, et maîtrisez les substitutions de polices avec font-display et size-adjust. Comme les dimensions de mise en page sont statiques, ces correctifs sont peu coûteux et régressent rarement — le CLS est généralement la métrique la plus rapide à faire passer au vert.

Données terrain contre données de laboratoire

Les classements utilisent les données terrain — des mesures réelles provenant d'utilisateurs de Chrome, agrégées dans le Chrome User Experience Report (CrUX) sur une fenêtre glissante de 28 jours. Les outils de laboratoire comme Lighthouse et l'onglet laboratoire de PageSpeed Insights simulent un seul chargement sur un seul appareil ; ils sont excellents pour le diagnostic mais ne décident pas si vous réussissez.

Cela déroute surtout les gens avec l'INP et le CLS, qui n'apparaissent que lorsque de vrais utilisateurs interagissent et défilent. Une page peut obtenir un parfait 100 dans Lighthouse et échouer tout de même à l'INP sur le terrain, parce qu'un test synthétique ne clique jamais sur rien. Confirmez toujours avec le rapport Core Web Vitals de la Google Search Console, qui lit depuis CrUX et montre exactement quelles URL et quels modèles échouent.

Comment les Core Web Vitals influencent les classements

Les Core Web Vitals sont un facteur de classement réel mais modeste, faisant partie des signaux d'expérience de page de Google. Ils se comportent davantage comme un critère de départage entre des pages de pertinence similaire que comme un raccourci vers le sommet — un contenu solide sur une page légèrement lente surclasse toujours un contenu pauvre sur une page rapide. Le gain le plus important est comportemental : des pages plus rapides et plus stables retiennent l'attention et convertissent mieux.

La performance se cumule aussi avec la confiance envers la marque. Un site qui se charge vite et ne saute jamais paraît professionnel, et il s'associe naturellement à un nom de domaine mémorable et brandable. Des places de marché sélectionnées comme Atom.com se spécialisent dans les noms premium et brandables et livrent chaque annonce avec une évaluation IA gratuite, une vérification de marque USPTO, un séquestre sécurisé et un logo conçu sur mesure — un site rapide portant un nom dont les gens se souviennent vraiment renforce la même crédibilité.

Corrigez-les dans le bon ordre

1. Commencez par les données terrain. Ouvrez le rapport Core Web Vitals dans la Search Console pour voir quelle métrique échoue et sur quels modèles.
2. Corrigez ensuite le LCP. Il apporte généralement le gain le plus important et le plus visible — préchargez et priorisez l'élément principal et réduisez le TTFB avec la mise en cache et un CDN.
3. Puis le CLS. Ajouter des dimensions et réserver de l'espace présente peu de risques et ne prend souvent qu'une journée sur l'ensemble des modèles.
4. Puis l'INP. La métrique la plus difficile — élaguez, différez et fractionnez le JavaScript, et abandonnez les scripts tiers dont vous n'avez pas besoin.
5. Mesurez à nouveau. Les données terrain se mettent à jour sur 28 jours, vérifiez donc les améliorations après environ un mois plutôt que d'attendre un mouvement instantané.

Questions fréquentes

L'INP est-il la même chose que le FID ?

Non. L'INP a remplacé le FID comme Core Web Vital le 12 mars 2024. Le FID ne mesurait que le délai avant le traitement de la première interaction ; l'INP évalue la réactivité de presque chaque interaction durant une visite et rapporte une valeur proche de votre pire, ce qui en fait un test bien plus strict de la réactivité réelle.

Les Core Web Vitals augmentent-ils directement les classements ?

Ce sont un signal de classement réel mais faible au sein de l'expérience de page — plus proche d'un critère de départage que d'un facteur majeur. Un contenu pertinent et utile compte bien davantage, mais de bons vitals améliorent l'engagement et les conversions, ce qui vous aide indirectement et protège le trafic que vous avez déjà acquis.

Quel centile dois-je atteindre ?

Le 75e centile des visites réelles, évalué séparément pour le mobile et l'ordinateur de bureau. Cela signifie qu'au moins 75 % des chargements doivent respecter chaque seuil, de sorte que ce sont vos visiteurs les plus lents, et non votre moyenne, qui décident si la page réussit.

Mon score Lighthouse est excellent mais j'échoue tout de même. Pourquoi ?

Lighthouse fournit des données de laboratoire — un seul chargement simulé qui n'interagit jamais. Les classements utilisent les données terrain de vrais utilisateurs de Chrome (CrUX). L'INP et le CLS en particulier n'apparaissent qu'avec de véritables clics et défilements, alors fiez-vous au rapport terrain de la Search Console plutôt qu'à un unique passage en laboratoire.