Les Core Web Vitals sont trois métriques définies par Google qui mesurent l’expérience réelle de chargement et d’interaction d’une page : le LCP (Largest Contentful Paint) mesure le temps avant que le contenu principal soit visible, l’INP (Interaction to Next Paint) mesure le temps de réponse de la page aux interactions de l’utilisateur et le CLS (Cumulative Layout Shift) mesure à quel point le contenu bouge de façon inattendue. Une page réussit l’évaluation quand 75 % de ses visites réelles sont dans les seuils « bons » : LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1.
Cet article explique ce que mesure chacune, d’où viennent les données et ce qui les dégrade habituellement, sans promesses de positionnement que Google ne fait pas.
Les trois métriques et leurs seuils
| Métrique | Ce qu’elle mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP | Temps avant l’affichage du plus grand élément de contenu visible | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| INP | Latence des interactions (clics, touchers, touches) sur toute la visite | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Somme des déplacements inattendus de la mise en page | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Les seuils s’appliquent au 75e percentile des visites : la page réussit une métrique si au moins trois expériences utilisateur sur quatre sont dans la plage « bon ». C’est une mesure volontairement exigeante pour qu’il ne suffise pas que la page soit rapide sur un ordinateur puissant avec une bonne connexion.
LCP : quand l’essentiel apparaît
Le LCP marque le moment où le navigateur peint le plus grand élément dans la zone visible : généralement une image à la une, une vidéo avec affiche ou un grand bloc de texte. Ce qui le retarde le plus :
- Des images principales lourdes ou sans priorité (voir lazy loading et fetchpriority).
- Une réponse lente du serveur (TTFB élevé).
- Du CSS ou du JavaScript bloquant le rendu.
- Des polices web qui retardent l’apparition du texte.
INP : comment la page répond
L’INP a remplacé le FID (First Input Delay) comme Core Web Vital en mars 2024. Contrairement au FID, qui ne mesurait que la première interaction, l’INP observe toutes les interactions de la visite et rapporte l’une des pires (en pratique la plus lente, en ignorant quelques valeurs aberrantes sur les pages très interactives). Il mesure depuis l’interaction de l’utilisateur jusqu’au moment où le navigateur peint la frame suivante.
Ce qui le dégrade est presque toujours du JavaScript : tâches longues sur le thread principal, gestionnaires d’événements lourds, frameworks qui hydratent toute la page avant de répondre, scripts tiers (publicité, analyse, chats) en concurrence pour le CPU.
CLS : que rien ne saute
Le CLS additionne les déplacements d’éléments visibles qui surviennent sans que l’utilisateur les ait provoqués. Les causes classiques :
- Images, vidéos ou iframes sans
widthetheight. - Publicités ou intégrations insérées sans espace réservé.
- Polices web qui changent la taille du texte à leur chargement.
- Contenu inséré dynamiquement au-dessus de ce qui est déjà visible (avis, bandeaux).
Si un site va afficher de la publicité, réserver la hauteur de chaque bloc publicitaire avant son chargement est la mesure la plus efficace contre le CLS.
D’où viennent les données : terrain et laboratoire
Il existe deux types de mesure, à ne pas confondre :
- Données de terrain (réelles). Elles proviennent d’utilisateurs réels de Chrome ayant accepté de partager des statistiques, collectées dans le Chrome UX Report (CrUX). Ce sont celles qu’utilise Google Search Console dans son rapport Core Web Vitals et celles qui comptent pour l’évaluation. Elles n’existent que si la page a assez de trafic.
- Données de laboratoire (simulées). Produites par un outil comme Lighthouse ou PageSpeed Insights dans un environnement contrôlé. Utiles pour diagnostiquer et reproduire des problèmes, mais elles ne reflètent pas la variété des appareils et connexions réels. L’INP, de plus, ne peut pas être mesuré en laboratoire car il dépend des interactions de l’utilisateur (Lighthouse propose le TBT, Total Blocking Time, comme approximation).
PageSpeed Insights montre les deux : en haut les données de terrain de CrUX (s’il y en a) et en bas l’analyse de laboratoire.
Comment les mesurer sur votre site
- PageSpeed Insights (pagespeed.web.dev) : saisissez l’URL et regardez d’abord la section des données réelles.
- Google Search Console, rapport « Core Web Vitals » : regroupe les URL du site par état (bonnes, à améliorer, mauvaises) à partir de CrUX.
- Chrome DevTools, panneau Performance : affiche LCP, INP et CLS en direct pendant la navigation et signale l’élément responsable de chacun.
- La bibliothèque web-vitals (
npm install web-vitals) : permet de collecter les métriques de vos propres utilisateurs et de les envoyer à votre outil d’analyse.
Quel lien avec le positionnement
Google indique dans sa documentation pour Search que les Core Web Vitals font partie des signaux d’expérience de page et recommande aux propriétaires d’obtenir de bons résultats, mais précise aussi qu’un contenu pertinent et de qualité reste l’essentiel et que d’excellents Vitals ne compensent pas un contenu pauvre. Il est raisonnable de les traiter pour ce qu’ils sont : une mesure de qualité pour les utilisateurs, qui évite en outre un désavantage face à des concurrents aux pages aussi pertinentes mais plus rapides.
Erreurs fréquentes en optimisant
- Optimiser seulement pour Lighthouse. Un score de 100 en laboratoire ne garantit pas de bonnes données de terrain si vos utilisateurs réels ont des mobiles modestes.
- Différer l’image du LCP. Appliquer
loading="lazy"à l’image principale dégrade le LCP. - Charger des scripts tiers sans contrôle. C’est la cause la plus fréquente d’INP élevé. Chargez seulement l’indispensable et, quand cela dépend du consentement de l’utilisateur, ne chargez rien avant de l’avoir.
- Ignorer le CLS des publicités. Réservez l’espace avec
min-heightsur chaque bloc publicitaire.
Conclusion
LCP, INP et CLS résument en trois nombres si une page s’affiche vite, répond rapidement et ne saute pas. Ils sont évalués avec des données d’utilisateurs réels au 75e percentile, et s’améliorent par des décisions concrètes : prioriser l’image principale, minimiser et reporter le JavaScript, déclarer les dimensions et réserver l’espace pour tout ce qui s’insère tard. Avant d’optimiser, mesurez sur le terrain ; ensuite, utilisez le laboratoire pour trouver la cause.