Quels sont les trois indicateurs des Core Web Vitals ?

Le LCP (Largest Contentful Paint) mesure la vitesse d'affichage du contenu principal, visant sous 2,5 secondes. L'INP (Interaction to Next Paint) mesure la réactivité aux clics, visant sous 200 millisecondes. Le CLS (Cumulative Layout Shift) mesure les mouvements inattendus de mise en page, visant sous 0,1.

Les Core Web Vitals affectent-ils vraiment le classement Google ?

Oui. Les Core Web Vitals sont un signal de classement confirmé par Google. Plus important encore, ils sont directement liés au taux de rebond et à la conversion — une page plus rapide génère plus de revenus, rendant ces métriques précieuses au-delà du seul classement.

Comment corriger un mauvais score CLS ?

Réservez l'espace pour les images, annonces et contenus dynamiques avant leur chargement en définissant des attributs de largeur et hauteur explicites. Évitez d'insérer du contenu au-dessus des éléments existants après le rendu. La plupart des problèmes de CLS viennent de médias qui décalent la mise en page à l'arrivée.

SEO et GEO · Par Arav Sahni · FutureSource

20 mars 2026

Core Web Vitals : le SEO technique qui fait bouger les classements

En bref : LCP, INP et CLS sont de vrais facteurs de classement et la première chose que ressentent les utilisateurs. Une liste pratique pour passer au vert.

Les Core Web Vitals transforment la plainte vague « le site semble lent » en trois chiffres corrigeables. C'est un signal de classement confirmé, mais surtout ils sont liés au taux de rebond et à la conversion — une page plus rapide rapporte simplement plus.

Ce que mesurent les trois métriques

Trois métriques comptent. Le LCP (Largest Contentful Paint) mesure la vitesse d'affichage du contenu principal, cible sous 2,5 secondes. L'INP (Interaction to Next Paint) mesure la réactivité aux clics, cible sous 200 millisecondes. Le CLS (Cumulative Layout Shift) mesure les mouvements inattendus au chargement, cible sous 0,1.

Corriger le LCP

La plupart des problèmes de LCP viennent d'une réponse serveur lente ou d'un élément principal lourd. Diffusez depuis un CDN de périphérie, compressez et dimensionnez correctement les images, préchargez l'élément principal et réduisez le JavaScript bloquant pour que le plus grand élément soit dans le HTML initial.

Préchargez l'image ou la police au-dessus de la ligne de flottaison.
Compressez les images et servez des formats modernes (WebP/AVIF).
Réduisez et différez les scripts bloquants.

Corriger l'INP

L'INP souffre quand de longues tâches JavaScript bloquent le fil principal et rendent un clic lent. Fractionnez les longues tâches, différez les scripts non essentiels après l'interaction et retirez le code tiers inutilisé qui vole de la réactivité à chaque clic.

Corriger le CLS

Le décalage survient quand le navigateur ignore l'espace requis par un élément avant son chargement. Réservez l'espace à l'avance et rien ne sautera sous le doigt de l'utilisateur.

Définissez largeur et hauteur explicites sur images et intégrations.
Réservez l'espace des publicités, bannières et contenus dynamiques.
N'insérez pas de nouveau contenu au-dessus du contenu existant.

Mesurer les vrais utilisateurs

Les outils de laboratoire comme Lighthouse n'estiment la performance que sur un appareil simulé. Les données de terrain (Search Console, CrUX) montrent l'expérience réelle sur de vrais téléphones et réseaux. Optimisez selon les données de terrain, car c'est exactement le signal que Google utilise.

Construire votre suite de mesure

Trois outils donnent une image complète. Commencez par Google Search Console, qui regroupe les pages par modèle d'URL dans le rapport Core Web Vitals — un gabarit de page produit défaillant apparaît comme un groupe de centaines de pages, facilitant la priorisation par impact. Envoyez ces gabarits dans PageSpeed Insights pour la vue combinée complète : données réelles CrUX avec les diagnostics de laboratoire Lighthouse qui nomment l'élément LCP spécifique et identifient les scripts contribuant au délai INP. Utilisez WebPageTest quand vous avez besoin d'une analyse en cascade pour identifier quelle requête tierce bloque le chemin critique sur un vrai appareil et un vrai réseau.

Diagnostiquer le LCP : quatre causes profondes

Chaque échec LCP remonte à l'une de quatre origines. Un Time to First Byte lent — tout ce qui dépasse 600 millisecondes — retarde toute la chaîne de ressources. Une feuille de style bloquant le rendu ou un script synchrone immobilise la séquence de peinture même quand le serveur répond vite. Une image principale non préchargée est découverte tardivement par le navigateur, attendant dans une file derrière des ressources moins prioritaires. Des images surdimensionnées arrivent dans le bon ordre mais prennent trop de temps à transmettre. Utilisez le panneau diagnostics de Lighthouse pour identifier la cause avant de toucher au code — le diagnostic détermine le correctif.

Vérifiez d'abord le TTFB dans WebPageTest — une réponse serveur lente ne se corrige pas uniquement par le travail front-end.
Ajoutez <link rel="preload" as="image"> avec fetchpriority="high" pour l'image principale.
Convertissez toutes les images en WebP ou AVIF et servez des tailles adaptées via srcset et sizes.

L'INP : les longues tâches sont l'ennemi

L'INP a remplacé le FID parce que ce dernier ne capturait que le premier clic, permettant à une page de réussir le FID tout en rendant chaque clic suivant lent. L'INP échantillonne chaque interaction sur toute la session et rapporte la pire, ce qui en fait un signal bien plus précis de la réactivité perçue. La cause profonde est presque toujours une longue tâche JavaScript bloquant le fil principal : un gestionnaire de balises qui déclenche plusieurs scripts à chaque chargement, une rafale d'hydratation React pendant les premières secondes critiques, ou une bibliothèque d'analytique traitant des événements en file. Profilez le fil principal avec le panneau Performance de Chrome DevTools, filtrez les tâches dépassant 50 ms et priorisez les plus grandes.

Le CLS au-delà des bases

Définir des dimensions explicites sur les images et réserver l'espace des emplacements publicitaires couvre la plupart des problèmes CLS. Les sources moins évidentes ramènent les scores en bas après qu'une équipe croit l'avoir résolu. Les bannières de consentement aux cookies injectées tardivement qui repoussent le contenu, les composants de carrousel qui s'initialisent à une hauteur par défaut puis s'étendent au chargement, et les tests A/B côté serveur qui échangent des variantes de code après le rendu initial produisent tous du décalage qu'un test Lighthouse standard ne détecte pas. Enregistrez une vraie session dans WebPageTest avec la capture vidéo activée, rejouez-la image par image, et l'élément coupable devient évident.

Séquencer les correctifs quand plusieurs métriques échouent

Quand LCP, INP et CLS sont tous au rouge, priorisez selon le ratio effort-impact. Les correctifs LCP — compression d'images, configuration CDN, préchargement — sont autonomes et font souvent passer les scores de Mauvais à À améliorer sans modifier le code de l'application. Les correctifs CLS nécessitent la définition de dimensions sur les gabarits — un changement structurel ponctuel par type de gabarit. Les correctifs INP exigent un profilage et une refactorisation JavaScript impliquant une capacité développeur dédiée aux performances. Un calendrier réaliste exécute les correctifs LCP en semaine un, CLS en semaines deux et trois, et commence l'investigation INP en semaine quatre.

Présenter les résultats en revenus

Chaque amélioration Core Web Vitals vaut plus quand elle est présentée en langage commercial. Une amélioration d'une seconde du LCP se corrèle à une hausse de deux à cinq pour cent du taux de conversion sur les pages e-commerce, selon les études de cas publiées de Google. Une correction CLS sur une page de paiement mobile supprime les clics accidentels et les soumissions incorrectes — une réduction directe des commandes abandonnées. Associez votre rapport CrUX avant-après à la métrique de conversion ou de revenus qui a bougé dans la même fenêtre de trois mois. Cette preuve maintient les futurs budgets de performance justifiés et respectés.

Foire aux questions

Quels sont les trois indicateurs des Core Web Vitals ?: Le LCP (Largest Contentful Paint) mesure la vitesse d'affichage du contenu principal, visant sous 2,5 secondes. L'INP (Interaction to Next Paint) mesure la réactivité aux clics, visant sous 200 millisecondes. Le CLS (Cumulative Layout Shift) mesure les mouvements inattendus de mise en page, visant sous 0,1.
Les Core Web Vitals affectent-ils vraiment le classement Google ?: Oui. Les Core Web Vitals sont un signal de classement confirmé par Google. Plus important encore, ils sont directement liés au taux de rebond et à la conversion — une page plus rapide génère plus de revenus, rendant ces métriques précieuses au-delà du seul classement.
Comment corriger un mauvais score CLS ?: Réservez l'espace pour les images, annonces et contenus dynamiques avant leur chargement en définissant des attributs de largeur et hauteur explicites. Évitez d'insérer du contenu au-dessus des éléments existants après le rendu. La plupart des problèmes de CLS viennent de médias qui décalent la mise en page à l'arrivée.