Core Web Vitals : que mesurent LCP, INP et CLS ?

On a tous vécu ça : vous ouvrez une page qui “a l’air” rapide, le contenu s’affiche, tout semble ok… puis vous cliquez sur un bouton et rien ne se passe pendant une demi-seconde. Le texte se met à bouger à cause d’une bannière qui arrive en retard. Et derrière, le site se demande pourquoi le panier et les leads s’écroulent.

Ce décalage entre ce que voit le propriétaire du site et ce que vit l’utilisateur, c’est le vrai sujet des Core Web Vitals. Google n’a pas inventé des métriques pour faire joli dans Search Console. LCP, INP et CLS sont la traduction chiffrée de trois sensations très concrètes :

• Largest Contentful Paint (LCP) : à quelle vitesse le contenu principal apparaît
• Interaction to Next Paint (INP) : à quelle vitesse la page réagit quand on clique ou qu’on tape au clavier
• Cumulative Layout Shift (CLS) : à quel point la mise en page bouge pendant le chargement

On va parler SEO, business, taux de conversion, mais sans perdre de vue la réalité : ces chiffres décrivent ce que ressent votre visiteur, pas ce que raconte votre hébergeur.

Core Web Vitals : la boussole de l’expérience utilisateur selon Google

Les Core Web Vitals, c’est le trio officiel de Google pour mesurer la qualité d’une page : LCP, INP et CLS. LCP pour le temps de chargement perçu, INP pour la réactivité des interactions, CLS pour la stabilité visuelle. On parle bien d’expérience utilisateur réelle, pas d’un score abstrait sorti d’un test technique isolé.

Google s’appuie sur les données du Chrome User Experience Report (CrUX) : ce sont des mesures prises sur des vraies visites, via le navigateur Chrome, et agrégées au 75e centile. Autrement dit, pour que votre page soit “bonne” sur une métrique, au moins 75 % des chargements doivent être dans le vert.

Côté SEO, Les Core Web Vitals ne vont pas pousser une page médiocre devant un contenu ultra pertinent. Mais entre deux pages de qualité comparable, celle qui charge vite, répond vite et reste stable prend l’avantage dans le Google ranking factor lié au Page Experience. En pratique, ça se voit sur :

• un site e‑commerce : moins de frictions sur les fiches produit, plus de paniers validés
• un média : plus de pages vues par session et moins de rage-quit après un saut de mise en page
• un SaaS : onboarding plus fluide, formulaires qui répondent vite, meilleure conversion sur les free trials

Ce que mesure vraiment le LCP : pas “la vitesse du site”, mais l’apparition de ce qui compte

Largest Contentful Paint, ce n’est pas “la vitesse globale du site”. C’est le temps nécessaire pour afficher le plus grand élément visible dans la zone au-dessus de la ligne de flottaison : image hero, bloc de titre principal, grosse vidéo, etc. Le LCP mesure le moment où l’utilisateur se dit : “ok, la page est là”.

Les seuils sont clairs :

• Bon LCP : ≤ 2,5 s
• À améliorer : entre 2,5 s et 4 s
• Mauvais : > 4 s

Exemple très classique : une page d’accueil dont le visuel principal est une image non compressée, servie par un serveur lent. Résultat : un LCP mobile largement au-delà du seuil. On compresse l’image en format WebP, on passe par un CDN, on active le cache, et on priorise le chargement de ce visuel dans le code. Le LCP passe alors dans le vert. Sur une fiche produit, c’est la différence entre un visuel qui s’affiche pendant que l’utilisateur décide et un visuel qui arrive après qu’il a renoncé.

Se focaliser sur un “score de vitesse global” sans regarder le LCP, c’est l’erreur SEO typique : on se rassure avec un bon score Lighthouse, alors que le bloc de contenu principal arrive bien trop tard pour les visiteurs. Personnellement, je vérifie toujours le LCP avant de parler “site rapide”.

INP : la métrique qui remplace FID et révèle si votre site répond vraiment quand on clique

Interaction to Next Paint (INP) est la nouvelle star de la réactivité chez Google. Elle a officiellement remplacé le First Input Delay (FID) en mars 2024 comme Core Web Vital. L’INP mesure le délai entre une interaction (clic, tap, frappe clavier) et la prochaine mise à jour visuelle significative sur la page. Et ça, sur l’ensemble de la session, pas seulement sur le premier clic.

Les seuils recommandés :

• Bon INP : ≤ 200 ms
• À améliorer : entre 200 et 500 ms
• Mauvais : > 500 ms

Pour vulgariser, on peut décomposer une interaction en trois phases :

• Input delay : le temps avant que le navigateur commence à traiter votre clic (bloqué si le thread principal digère une grosse tâche JS)
• Processing time : la durée d’exécution du code qui gère l’action (calcul, requête, logique métier)
• Presentation delay : le temps avant que l’écran se mette à jour (repaint, DOM mis à jour, animation)

Sur le terrain, un INP dans le rouge traduit souvent :

• un payload JavaScript massif qui occupe le thread principal
• des tâches longues (long tasks > 50 ms) qui bloquent l’interface
• des frameworks frontend mal configurés ou trop lourds pour des interactions simples
• des scripts tiers (tracking, chat, AB test) qui s’interposent partout

Cas ultra parlant : clic sur “Ajouter au panier” qui met 700 ms à réagir, car la page lance un gros script de recomposition du DOM, plus deux trackers et un script promotionnel. L’utilisateur a l’impression que le clic n’a pas marché, il recommence, voire il abandonne. L’INP, lui, ne pardonne pas. Pour retrouver une interface fluide, il faut découper les tâches JS, charger les scripts non critiques en différé, alléger les composants interactifs et limiter les scripts tiers au strict nécessaire.

CLS : quand votre mise en page joue à la chaise musicale avec vos utilisateurs

Cumulative Layout Shift (CLS) mesure la stabilité visuelle d’une page : à quel point les éléments se déplacent de manière inattendue pendant le chargement ou l’utilisation. On parle de “sauts de mise en page” qui provoquent clics ratés, frustration et perte de confiance.

Les seuils de Google sont simples :

• Bon CLS : ≤ 0,1
• À améliorer : entre 0,1 et 0,25
• Mauvais : > 0,25

Sans formule, comment ça se calcule ? Chaque fois qu’un bloc déjà affiché se déplace de façon inattendue, on mesure l’ampleur du déplacement et la portion d’écran impactée. La somme de ces “scores” donne le CLS. Exemple très concret :

• une pub se charge en retard en haut de la page, pousse tout le contenu vers le bas, votre bouton fuit au moment du clic
• une image sans dimensions qui se charge en plein milieu d’un article et fait descendre le paragraphe sous les yeux du lecteur

Les causes fréquentes :

• images sans attributs largeur/hauteur
• bannières publicitaires dynamiques qui s’insèrent sans réserver d’espace
• iframes et embeds (vidéos, widgets) ajoutés après coup
• polices web qui recassent la mise en page quand elles se chargent

Là, on touche à la confiance. Une page qui bouge au moment du clic, surtout sur mobile, donne l’impression d’un site mal maîtrisé, voire malhonnête. Le cas le plus fréquent sur un site média : des emplacements publicitaires injectés tardivement, sans hauteur réservée, qui repoussent les blocs de recommandation au moment précis où le lecteur allait cliquer.

Comment Google évalue vos scores : données de terrain, seuils et impact SEO

Google ne regarde pas votre dernière visite en local. Les Core Web Vitals sont évalués via le Chrome User Experience Report, à partir de données réelles sur les 28 derniers jours, segmentées mobile et desktop. Pour chaque métrique, la note se base sur le 75e percentile des visites : une page est considérée “bonne” si au moins 75 % des chargements sont dans le vert pour LCP, INP et CLS.

Dans le rapport Core Web Vitals de la Search Console, les URL sont regroupées et leur statut dépend de la métrique la moins performante du groupe. Si votre LCP est correct mais que votre CLS explose, le groupe passe en “moyen” ou “mauvais”. Ça a un impact direct sur les pages stratégiques : landing pages, fiches produit, pages de contact.

Côté SEO, je vois les Core Web Vitals comme un facteur de différenciation : ils ne sauveront pas un contenu médiocre, mais ils arbitrent le match entre deux résultats proches en pertinence, surtout sur mobile où la tolérance à la lenteur est très faible.

LCP, INP, CLS : trois mesures différentes, un même objectif

On peut résumer le trio comme une timeline du parcours utilisateur :

Métrique	Ce que Google mesure	Ce que ressent l’utilisateur
LCP	Moment où l’élément principal apparaît (≤ 2,5 s recommandé)	“La page se montre vite ou je poireaute ?”
INP	Réactivité à toutes les interactions pendant la visite (≤ 200 ms)	“Quand je clique, ça répond ou ça rame ?”
CLS	Amplitude cumulée des décalages visuels inattendus (≤ 0,1)	“La page est stable ou elle bouge tout le temps ?”

Une page rapide en LCP mais lente en INP donne une expérience très frustrante : le contenu arrive vite, mais les interactions sont molles, le menu met une plombe à s’ouvrir, le filtre produit bloque la page. À l’inverse, un mauvais CLS ruine une page rapide : vous scrolliez tranquillement, le texte se décale, le bouton change de place, vous perdez le fil.

C’est pour ça que je recommande une approche globale : on optimise la vitesse de chargement, la réactivité des interactions et la stabilité visuelle ensemble, sans chercher à gratter 100 ms sur le LCP si ça dégrade l’INP à cause de scripts supplémentaires mal gérés.

Les outils à utiliser pour analyser vos Core Web Vitals (sans devenir développeur)

Bonne nouvelle : vous n’avez pas besoin d’écrire une ligne de code pour auditer vos Core Web Vitals. Les principaux outils sont accessibles à un SEO, un UX designer ou un chef de projet.

• Google Search Console : rapport “Signaux Web essentiels” avec vision globale des URL, regroupées par état (bon, moyen, mauvais) sur LCP, INP, CLS, basé sur les données terrain
• PageSpeed Insights : analyse page par page avec double vue données terrain (CrUX) et données de laboratoire, plus des recommandations concrètes
• Lighthouse (dans Chrome ou via outils) : audit technique orienté performance, utile pour diagnostiquer des problèmes de LCP ou CLS, moins adapté pour mesurer l’INP en mode labo
• Chrome DevTools : onglets Performance et Sources pour voir les long tasks, le thread principal et les sauts de mise en page en détail

Dans PageSpeed Insights, vous retrouvez clairement les indicateurs LCP, INP, CLS avec codes couleur vert / orange / rouge, et la possibilité de filtrer par mobile ou desktop. Le rapport Search Console permet d’exporter les données et de les partager à votre développeur, ce qui est très pratique pour prioriser les corrections. Après chaque mise en production, on devrait idéalement refaire un test PSI, vérifier Search Console quelques jours plus tard et suivre l’évolution dans le temps via analytics ou CrUX.

Ce qui dégrade le plus souvent le LCP (et comment y remédier concrètement)

Les coupables habituels d’un LCP mauvais sont assez récurrents :

• temps de réponse serveur trop long (backend lent, hébergement bas de gamme)
• images lourdes et non optimisées
• ressources bloquantes : CSS rendu synchronement, JavaScript non critique chargé trop tôt
• absence de mise en cache et CDN

Les pistes de correction, très actionnables pour un non-dev :

• convertir les gros visuels en WebP, compresser et adapter la taille, utiliser du lazy loading pour les images sous la ligne de flottaison
• passer par un CDN fiable pour servir les assets statiques
• réduire les scripts inutiles, charger les JS non critiques en différé, optimiser les CSS pour que le contenu au-dessus de la ligne de flottaison arrive en premier
• améliorer l’infrastructure serveur (cache côté serveur, configuration HTTP/2, éventuellement changement d’hébergeur)

Séquence type sur une page d’accueil dont le LCP est au rouge : on compresse et on redimensionne le visuel principal, on passe les scripts marketing non critiques en defer, on met en place un CDN et un cache serveur, puis on laisse passer la fenêtre de mesure du terrain avant de conclure. C’est ce dernier point qui est le plus souvent escamoté : les données de terrain sont agrégées sur plusieurs semaines, un déploiement du jour ne se lit donc pas dans le rapport du lendemain.

Pourquoi votre INP explose et comment retrouver une interface fluide

Quand l’INP explose, la grande majorité du temps, c’est la couche JavaScript qui fait souffrir votre interface. Les causes récurrentes :

• bundle JS massif chargé sur toutes les pages, quelle que soit la complexité de l’écran
• tâches longues qui monopolisent le thread principal (calculs complexes, manipulations DOM lourdes)
• écouteurs d’événements surchargés qui déclenchent trop de logique à chaque clic
• interactions mal pensées : on attend que tout soit calculé avant de montrer un feedback visuel

Les leviers pour rendre l’INP plus sain, même si vous n’êtes pas développeur :

• demander le découpage des tâches JS (utiliser des micro-tâches, des web workers, ou simplement revoir la logique pour éviter les gros blocs)
• charger en différé les scripts non essentiels (AB tests, heatmaps, chats) après le premier rendu
• alléger les frameworks front et supprimer les composants surdimensionnés pour des interactions simples
• limiter les scripts tiers au strict nécessaire, surtout sur les pages transactionnelles

Je conseille toujours d’ouvrir Chrome DevTools, onglet Performance, de déclencher un clic problématique et de regarder les long tasks mises en évidence. Même sans toucher au code, vous pouvez identifier clairement : “À ce clic, il y a une tâche de 250 ms liée à tel script”. Derrière, la discussion avec le dev devient beaucoup plus concrète.

Stabiliser votre mise en page : comment réduire un CLS trop élevé

Pour un CLS trop élevé, les causes sont rarement mystérieuses. Si le contenu “saute”, c’est qu’on n’a pas réservé d’espace pour des éléments qui arrivent plus tard. Les facteurs classiques :

• images et vidéos sans dimensions fixées dans le HTML/CSS
• blocs publicitaires injectés dynamiquement
• iframes et widgets externes qui apparaissent après coup
• polices exotiques qui reformatent des blocs entiers à leur chargement

Les bonnes pratiques simples :

• toujours définir largeur et hauteur des médias, ou réserver un conteneur avec des proportions stables
• prévoir un espace pour les publicités et les composants dynamiques, même avant qu’ils soient remplis
• utiliser des placeholders (squelettes, blocs vides) pour les contenus qui se chargent plus tard
• gérer les polices web de façon intelligente (font-display, préchargement) pour limiter les reflows violents

Imaginez un article de blog : vous commencez à lire, puis un bloc d’images “best of” se charge trois secondes après, pousse le texte vers le bas, vous perdez la ligne que vous suiviez. Ce simple comportement peut suffire à faire fuir un lecteur pressé. En stabilisant cette zone avec un placeholder, on réduit le CLS et on évite de casser la lecture.

Prioriser ses actions : par quelles pages et quelles métriques commencer ?

On ne corrige pas tout en même temps, et ce n’est pas grave. La démarche pragmatique :

• identifier les pages qui génèrent le plus de trafic SEO ou de revenus via Search Console et votre outil d’analytique web
• regarder sur ces pages quelle métrique est la plus dans le rouge : LCP, INP ou CLS
• construire un plan d’actions ciblé sur ces couples page / problème
• mettre en production, mesurer à nouveau, puis étendre les optimisations aux autres URL

En pratique, un site d’actualité va souvent commencer par le LCP, car la vitesse d’apparition du contenu est décisive pour les lecteurs qui scannent rapidement les titres. Un SaaS ou une appli web va clairement miser sur l’INP, pour éviter les interfaces “collantes” qui sabotent l’onboarding. Un média très chargé en pubs va surveiller le CLS de près, car c’est là que les revenus publicitaires peuvent entrer en collision avec l’expérience de lecture.

Mon avis personnel : commencez par une seule famille de pages (par exemple, toutes les fiches produit phare), fixez-vous un objectif raisonnable (passer LCP et INP dans le vert sur mobile), et utilisez les Core Web Vitals comme un indicateur d’optimisation continue. Vous verrez vite lesquelles de vos actions ont un vrai impact, et lesquelles ne sont que du bruit marketing.