Core Web Vitals (LCP, CLS, INP) : les métriques Google qui impactent votre SEO

LCP, CLS, INP : ces trois métriques Google déterminent si votre site sera bien classé ou pénalisé dans les résultats de recherche. Les Core Web Vitals mesurent la vitesse de chargement, la stabilité visuelle et la réactivité de votre site. Un mauvais score impacte directement votre SEO, votre taux de conversion et votre image de marque. Comprendre ces indicateurs et savoir les optimiser peut faire basculer votre site de la page 3 à la page 1 de Google. Besoin d'un site rapide dès le départ ? Découvrez notre service de création de site web optimisé Core Web Vitals.

Pourquoi Google mesure-t-il les Core Web Vitals de votre site ?

Depuis 2021, Google utilise les Core Web Vitals (LCP, CLS, INP) comme facteur de classement. Ces métriques mesurent l'expérience utilisateur réelle : vitesse de chargement, stabilité visuelle et réactivité. Un site qui échoue sur ces indicateurs perd des positions dans les résultats de recherche.

À contenu et autorité équivalents, ces métriques départagent deux pages concurrentes. Elles ne compensent jamais un contenu faible, mais elles font basculer un match serré, et c'est exactement la situation dans laquelle se trouve la plupart des sites de PME sur leurs requêtes cibles.

Quelles sont les trois métriques essentielles des Core Web Vitals ?

Les trois métriques sont le LCP (vitesse d'affichage, seuil 2,5 secondes), le CLS (stabilité visuelle, seuil 0,1) et l'INP (réactivité aux interactions, seuil 200 ms).

LCP : Largest Contentful Paint

Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible de la page, généralement une image hero ou un bloc de texte principal. C'est la perception de vitesse : quand le LCP est rapide, l'utilisateur sent que la page "charge vite", même si d'autres éléments continuent de charger.

Les seuils sont les suivants : moins de 2,5 secondes est bon (vert), entre 2,5 et 4 secondes nécessite une amélioration (orange), plus de 4 secondes est mauvais (rouge). Précision qui change tout dans l'interprétation : Google ne regarde pas la moyenne mais le 75e centile. Autrement dit, 75 % de vos visiteurs doivent passer sous 2,5 s. Une moyenne flatteuse peut parfaitement masquer un quart d'utilisateurs à 6 secondes.

Les causes fréquentes d'un mauvais LCP incluent les images hero non optimisées (trop lourdes, mauvais format), un serveur lent à répondre (TTFB élevé), du CSS ou JavaScript bloquant le rendu, des polices web lentes à charger, et trop de redirections.

Le réflexe qui fait gagner des heures : depuis 2023, Google découpe officiellement le LCP en quatre sous-parties, visibles dans PageSpeed Insights et dans le panneau Performance de Chrome DevTools.

Sur les audits que nous menons chez KreaRise, le TTFB pèse presque toujours plus lourd que le poids de l'image. Un hébergement mutualisé qui répond en 1,2 s condamne le LCP avant même que l'image soit demandée : voyez notre analyse de l'impact de l'hébergement sur la vitesse et le SEO.

Comment améliorer le LCP ? Pour les images, utilisez des formats modernes (WebP, AVIF), dimensionnez correctement (pas d'image 4000px pour un affichage 800px), ajoutez l'attribut loading="eager" sur l'image LCP, et utilisez un CDN. Pour le serveur, passez à un hébergement plus rapide, activez la compression (gzip, brotli), utilisez un CDN pour le HTML, et cachez agressivement les ressources statiques. Pour éliminer les ressources bloquantes, différez le JavaScript non critique (defer, async), inlinéz le CSS critique, et préchargez les ressources importantes (<link rel="preload">).

CLS : Cumulative Layout Shift

Le CLS mesure la stabilité visuelle, c'est-à-dire combien la page "saute" pendant le chargement. Ces décalages inattendus frustrent les utilisateurs : vous cliquez sur un bouton, et hop, une pub apparaît et vous cliquez dessus par erreur. Un CLS élevé crée une expérience désagréable et les utilisateurs perdent confiance.

Les seuils sont : moins de 0,1 est bon, entre 0,1 et 0,25 nécessite une amélioration, plus de 0,25 est mauvais.

Les causes fréquentes incluent les images sans dimensions spécifiées, les publicités/embeds qui s'insèrent après coup, les polices web qui changent la taille du texte, le contenu injecté dynamiquement en haut de page, et les animations qui déplacent du contenu.

Comment améliorer le CLS ? Réservez l'espace des images en spécifiant toujours les dimensions :

<!-- Mauvais : pas de dimensions -->
<img src="photo.jpg" alt="Photo">

<!-- Bon : dimensions explicites -->
<img src="photo.jpg" alt="Photo" width="800" height="600">

<!-- Mieux : ratio aspect -->
<img src="photo.jpg" alt="Photo" style="aspect-ratio: 4/3">

Définissez des conteneurs de taille fixe pour les pubs et embeds qui chargent après coup. Gérez les polices avec font-display: swap ou optional pour éliminer le décalage. Ne jamais injecter de contenu au-dessus du viewport : le contenu ajouté dynamiquement doit toujours apparaître en dessous de ce que l'utilisateur regarde.

INP : Interaction to Next Paint

L'INP mesure la réactivité. Quand l'utilisateur clique, tape ou touche, combien de temps avant que la page réagisse visuellement ? L'INP a remplacé le FID (First Input Delay) le 12 mars 2024, et Google a retiré le FID de l'ensemble de ses outils en septembre 2024. Le changement n'est pas cosmétique : le FID ne mesurait que le délai avant traitement de la première interaction, ce qui donnait de bons scores à des pages pourtant pénibles à utiliser. L'INP mesure la latence de toutes les interactions, jusqu'à l'affichage du résultat.

Conséquence pratique : si un article ou un prestataire vous parle encore de FID et d'un seuil de 100 ms, ses références ont plus de deux ans.

Les seuils sont : moins de 200ms est bon, entre 200ms et 500ms nécessite une amélioration, plus de 500ms est mauvais.

Les causes fréquentes incluent le JavaScript bloquant le thread principal, les écouteurs d'événements lourds, trop de work pendant les interactions, l'hydration lente des frameworks JavaScript, et les third-party scripts abusifs.

Comment améliorer l'INP ? Divisez les tâches longues :

// Mauvais : tâche bloquante de 500ms
function traitementLourd() {
  // ... traitement long
}

// Mieux : découpage en chunks
async function traitementLourd() {
  for (const item of items) {
    await processItem(item);
    // Laisse le navigateur respirer
    await new Promise(r => setTimeout(r, 0));
  }
}

Les gestionnaires de clics doivent être légers. Déplacez le travail lourd dans des Web Workers ou différez-le. Réduisez le JavaScript en éliminant le code mort, différant les scripts non critiques, utilisant le tree-shaking, et lazy-loadant les modules lourds. Attention aux third-party : scripts de chat, analytics, pubs, pixels de tracking... chacun ajoute du JavaScript. Auditez régulièrement et supprimez les inutiles.

Comment mesurer vos Core Web Vitals ?

Deux types d'outils existent : les données terrain (Google Search Console, CrUX) qui reflètent l'expérience réelle des utilisateurs et servent au classement, et les données laboratoire (Lighthouse, WebPageTest) qui servent au diagnostic. Fiez-vous aux données terrain pour le verdict final.

Outils de mesure terrain (données réelles)

Google Search Console est la référence avec des données basées sur les vrais utilisateurs de Chrome (Menu Expérience > Core Web Vitals). Chrome UX Report (CrUX) fournit les données brutes utilisées par Search Console, accessibles via BigQuery ou l'API. PageSpeed Insights affiche les données terrain (si disponibles) ET les données de laboratoire.

Une limite à connaître avant de vous inquiéter pour rien : CrUX n'expose des données que si votre page reçoit un volume de visites suffisant. Un site de PME récent affichera très souvent « Données insuffisantes » dans PageSpeed Insights. Ce n'est pas un défaut de votre site, et dans ce cas Google se rabat sur les données agrégées au niveau de l'origine (le domaine entier). Pour piloter malgré tout, il faut alors instrumenter vos propres mesures avec la bibliothèque web-vitals. La marche à suivre pour lire ces rapports est détaillée dans notre guide Google Search Console.

Outils de mesure laboratoire (tests)

Lighthouse dans les DevTools (clic droit > Inspecter > onglet Lighthouse) simule un utilisateur sur un appareil moyen. PageSpeed Insights offre une section "Diagnostics" avec des recommandations détaillées. WebPageTest permet des tests avancés avec choix du lieu, navigateur et connexion.

Quelle mesure croire ?

Les données terrain (CrUX, Search Console) reflètent l'expérience réelle et sont celles que Google utilise pour le classement. Les données laboratoire (Lighthouse) sont utiles pour diagnostiquer et tester des améliorations, mais peuvent différer de la réalité.

Quelle stratégie d'optimisation adopter ?

La démarche se déroule en quatre étapes : diagnostiquer via Search Console, prioriser les pages à fort trafic, itérer en mesurant l'impact de chaque changement, puis surveiller en continu. Les optimisations de performance sont incrémentales et les résultats terrain mettent quelques jours à apparaître.

Diagnostiquer : vérifiez vos Core Web Vitals dans Search Console, identifiez les pages problématiques, lancez Lighthouse pour comprendre les causes.

Prioriser : concentrez-vous d'abord sur les pages à fort trafic, la métrique la plus problématique, et les quick wins (gains faciles).

Itérer : les optimisations de performance sont incrémentales. Implémentez un changement, mesurez l'impact (attendez quelques jours pour les données terrain), puis passez au suivant.

Surveiller : les performances peuvent se dégrader avec le temps (nouvelles features, nouveaux scripts). Mettez en place un monitoring continu.

Quelles erreurs courantes faut-il éviter ?

Se fier uniquement à Lighthouse, optimiser sans mesurer avant et après, ignorer le mobile et accumuler les scripts tiers sont les quatre erreurs les plus fréquentes. Google utilise l'index mobile-first : les Core Web Vitals mobiles comptent davantage que les scores desktop.

Se fier uniquement à Lighthouse : l'outil simule une connexion bridée depuis une seule machine et ne mesure pas l'INP, qui suppose de vraies interactions. Les données terrain reposent sur une fenêtre glissante de 28 jours de sessions Chrome réelles : un correctif déployé aujourd'hui n'y apparaît pleinement qu'un mois plus tard.

Optimiser sans mesurer : certaines optimisations se retournent contre vous, comme précharger dix ressources « prioritaires » qui se disputent la bande passante et retardent l'image LCP. Notez la valeur de départ de chaque métrique avant d'y toucher, sinon vous ne saurez pas quel changement a produit quel effet.

Ignorer le mobile : testez sur un appareil d'entrée de gamme en 4G, pas sur un iPhone récent en Wi-Fi. L'écart de puissance processeur entre un smartphone à 150 euros et un modèle haut de gamme change radicalement le temps d'exécution du JavaScript, donc l'INP.

Trop de third-party : le widget de chat, le bandeau de consentement et les pixels publicitaires sont les suspects habituels. Chacun impose une résolution DNS et une négociation TLS avant même de télécharger son code : chargez-les après le premier rendu, ou au clic quand c'est possible.

Quel est l'impact SEO réel des Core Web Vitals ?

Les Core Web Vitals sont un signal parmi des centaines. Un contenu médiocre avec d'excellents CWV ne sera pas premier. Mais à contenu équivalent, les performances peuvent faire la différence.

Plus important : les performances impactent directement le taux de rebond (site lent = départ), le taux de conversion (frustration = pas d'achat), et la perception de marque (site rapide = professionnel).

Notre approche performance

Chez KreaRise, les Core Web Vitals sont intégrés dès la conception. Notre architecture optimisée pour chaque projet de création de site web utilise Next.js avec SSR/SSG et l'optimisation automatique des images. Nous utilisons un hébergement performant sur Vercel avec CDN mondial. Le monitoring continu génère des alertes si les métriques se dégradent, et nous effectuons des audits réguliers avec recommandations d'optimisation. Les sites livrés depuis notre agence web à Marne-la-Vallée passent tous ce contrôle avant mise en production.

Notre service de création de site web optimisé inclut une analyse complète des Core Web Vitals avec plan d'action priorisé.

---

Vos Core Web Vitals sont dans le rouge ? Demandez un devis gratuit : on identifie les gains LCP, INP et CLS à plus fort impact SEO et on chiffre l'intervention.

Conclusion

Les Core Web Vitals ne sont pas que des métriques techniques. Google les utilise pour classer les sites, et les utilisateurs les ressentent directement. Un LCP lent fait fuir vos visiteurs avant même qu'ils aient vu votre contenu.

Vous voulez un avis expert ? Demandez votre devis gratuit. On analyse votre projet et on vous répond sous 48h. Sans engagement.

Le Conseil KreaRise : Décomposez toujours votre LCP en quatre sous-parties (TTFB, délai avant chargement de la ressource, durée de chargement, délai de rendu) avant de toucher à quoi que ce soit. Dans la majorité des cas que nous auditons, le coupable est le TTFB de l'hébergement, pas le poids de l'image : compresser davantage ne changera rien.