Qu’est-ce que les Core Web Vitals ?
Les Core Web Vitals, ou Signaux Web essentiels, sont trois métriques définies par Google pour mesurer l’expérience réelle des internautes sur une page. Le LCP mesure la vitesse de chargement, l’INP la réactivité aux interactions et le CLS la stabilité visuelle. Google les évalue sur des visites réelles, au 75e percentile des chargements.
Google les définit comme « un ensemble de métriques qui évaluent l’expérience utilisateur réelle en fonction des performances de chargement, de l’interactivité et de la stabilité visuelle de la page ». Elles s’appliquent « à toutes les pages Web », précise web.dev. Source : Google Search Central et web.dev.
La liste a déjà changé une fois. À leur présentation sur web.dev, le 4 mai 2020, elles réunissaient le LCP, le FID et le CLS. L’INP a remplacé le FID le 12 mars 2024.
Pour la recherche, Google s’appuie sur les données de terrain du Chrome User Experience Report (CrUX), recueillies auprès d’utilisateurs réels de Chrome. PageSpeed Insights les présente sur les 28 derniers jours.
Mobile et ordinateur sont évalués séparément : une page peut être « Bon » sur ordinateur et « Médiocre » sur mobile. Suivez les deux, en commençant par le mobile. Avec l’indexation orientée mobile, Google indexe et classe la version mobile du contenu.
Le rapport Core Web Vitals de la Search Console classe les URL par groupes de pages similaires, sous trois états : « Bon », « Amélioration nécessaire » et « Médiocre ». L’état d’un groupe suit sa métrique la moins performante. Un CLS « Médiocre » suffit donc à classer le groupe « Médiocre », même avec un INP « Bon ».
LCP (Largest Contentful Paint) : ce qui ralentit votre page.
Le LCP mesure le temps écoulé entre le début du chargement de la page et l’affichage du plus grand élément visible dans la fenêtre. Selon web.dev, cet élément peut être une image, l’image d’affiche ou la première image d’une vidéo, une image de fond chargée en CSS ou un bloc de texte.
Si cet élément est le lecteur d’une vidéo que vous voulez voir indexée, ne le remplacez pas par une image à cliquer : Google risque de ne pas indexer la vidéo. La Search Console signale ce cas par l’erreur « Impossible de déterminer la position et la taille de la vidéo » (voir notre guide du référencement vidéo).
Largest Contentful Paint
Web.dev découpe le LCP en quatre sous-parties : temps de latence du premier octet (TTFB), délai de chargement de la ressource, durée de ce chargement et délai d’affichage de l’élément. Le même guide vise, à titre indicatif, moins de 10 % du LCP pour chacun des deux délais. S’ils pèsent davantage, commencez par eux.
Ce qui peut dégrader le LCP :
- Image héros lourde, non compressée, sans format moderne (AVIF, WebP)
- Police web bloquante chargée sans
font-display: swap - JavaScript critique placé en tête de page sans
deferouasync - Hébergement lent ou absence de CDN sur les ressources statiques
- Site React, Vue ou Angular rendu côté client, sans rendu serveur
Dans l’étude d’Advanced Web Ranking de 2022, détaillée en section 08, le LCP est la seule des trois métriques à montrer une corrélation nette avec la position.
INP (Interaction to Next Paint) : la métrique qui a remplacé le FID.
Le FID ne mesurait que le délai d’entrée de la première interaction. Or les données d’utilisation de Chrome, publiées par web.dev, montrent que 90 % du temps passé sur une page se déroule après son chargement. L’INP observe toutes les interactions de la visite et retient la plus longue, hors valeurs aberrantes.
Interaction to Next Paint
La latence de chaque interaction additionne trois durées : le délai d’entrée, la durée de traitement et le délai de présentation. Avant de corriger une interaction lente, identifiez le segment qui la ralentit.
Ce qui peut dégrader l’INP :
- Tâches JavaScript qui bloquent le thread principal plus de 50 ms
- DOM trop volumineux qui ralentit les recalculs de mise en page
- Gestionnaires d’événements synchrones lourds, non découpés avec
setTimeoutouscheduler.yield() - Scripts tiers (mesure d’audience, tests A/B, chat) qui s’exécutent à chaque interaction
- Hydratation React ou Vue trop volumineuse au premier rendu
Le FID ignorait le traitement et l’affichage qui suivent l’interaction ; l’INP les compte. Un site qui passait le FID peut donc obtenir un INP « Médiocre » sans avoir changé une ligne de code.
CLS (Cumulative Layout Shift) : éviter les sauts visuels.
Le CLS est un score sans unité qui mesure la plus forte rafale de décalages de mise en page inattendus pendant la vie de la page. Une bannière insérée au-dessus du texte ou une image dont la hauteur n’est connue qu’après chargement suffit à déplacer le contenu sous les yeux du lecteur.
Cumulative Layout Shift
Le CLS regroupe les décalages en fenêtres de session : des décalages espacés de moins d’une seconde, sur cinq secondes au plus. Sa valeur est celle de la fenêtre au score cumulé le plus élevé. Les décalages survenus dans les 500 millisecondes qui suivent un clic, un appui ou une frappe au clavier sont exclus.
Ce qui peut dégrader le CLS :
- Images sans attribut
widthetheightou sansaspect-ratioCSS - Bannières publicitaires injectées sans réservation d’espace
- Police web plus large ou plus haute que la police de repli, qui décale le texte en s’affichant
- Carrousels et widgets tiers chargés en JavaScript avec du contenu de hauteur variable
- Bandeaux cookies insérés dans la page, qui poussent le contenu vers le bas
Les corrections de base tiennent dans le HTML et le CSS : taille déclarée des médias, place réservée aux annonces et aux bandeaux, polices chargées sans saut de taille. Contrôlez le CLS après chaque mise en production, car un widget ajouté sans place réservée peut le dégrader sans que l’équipe le remarque.
Seuils Google officiels en un tableau.
Une page réussit l’évaluation quand ses trois métriques atteignent le seuil « Bon » au 75e percentile des chargements, sur mobile et sur ordinateur séparément. Si les données d’INP manquent, PageSpeed Insights se contente du LCP et du CLS.
| Métrique | Bon | À améliorer | Médiocre | Source officielle |
|---|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5 à 4 s | > 4 s | web.dev/lcp |
| INP | ≤ 200 ms | 200 à 500 ms | > 500 ms | web.dev/inp |
| CLS | ≤ 0,1 | 0,1 à 0,25 | > 0,25 | web.dev/cls |
Comment mesurer ses Core Web Vitals correctement.
Distinguez d’abord deux types de données. Les données de terrain viennent d’utilisateurs réels : celles du Chrome User Experience Report forment, selon l’équipe Chrome, « l’ensemble de données officiel du programme Web Vitals ». Les données de laboratoire, produites par Lighthouse dans des conditions simulées, servent au diagnostic mais peuvent ne pas refléter l’expérience de vos visiteurs.
Trois outils gratuits couvrent la mesure, du suivi du site au diagnostic d’une URL.
Search Console
Le rapport dédié aux trois métriques regroupe les données de terrain par groupes d’URL similaires, mobile et ordinateur séparés. Seules les URL indexées y figurent, et il n’en présente qu’un échantillon.
PageSpeed Insights
Croise les données CrUX des 28 derniers jours et un audit Lighthouse lancé à la demande, URL par URL. L’audit nomme l’élément LCP, détaille le temps de ses quatre sous-parties et suggère des améliorations.
web-vitals.js + RUM
La bibliothèque publiée par l’équipe Chrome sur GitHub mesure le LCP, l’INP et le CLS chez vos propres visiteurs (RUM, Real User Monitoring). Vous envoyez ensuite ces mesures vers votre outil d’analyse (Google Analytics, par exemple) ou un service de suivi des performances.
Première erreur : lancer Lighthouse, obtenir un bon score de performance et conclure que tout va bien. Lighthouse simule un seul chargement, sur un appareil et un réseau émulés, alors que vos visiteurs ont leurs propres téléphones et connexions. Croisez avec les données de terrain de la Search Console ou de PageSpeed Insights.
Lighthouse ne voit pas tout. Sur notre page d’accueil, le trait animé sous « Scroll » animait aussi transform-origin. Le compositeur de Chrome n’anime pas cette propriété. Page immobile, l’animation relançait le thread principal 60 fois par seconde, sans alerte de Lighthouse. Réécrite avec transform seul, elle rend la même chose sans ce coût.
Deuxième erreur : juger une correction trop tôt. PageSpeed Insights présente les 28 derniers jours de données, si bien qu’une correction déployée aujourd’hui ne s’y lit en entier que 28 jours plus tard. Dans la Search Console, l’action « Démarrer le suivi » lance de même une surveillance de 28 jours.
Dix leviers techniques pour améliorer le LCP, l’INP et le CLS.
Chaque levier indique la métrique qu’il vise. Commencez par celle qui classe vos groupes d’URL en « Médiocre » dans la Search Console : un levier LCP ne corrigera pas un INP lent.
Charger l’image LCP en priorité
Repérez l’élément LCP dans PageSpeed Insights. Si c’est une image présente dans le HTML, ajoutez fetchpriority="high" à sa balise <img>. Si elle n’est appelée que depuis un fichier CSS ou JavaScript, préchargez-la avec <link rel="preload" as="image" fetchpriority="high">. Web.dev déconseille de la charger en différé (loading="lazy"), ce qui ajoute toujours un retard inutile.
Servir les images en AVIF ou WebP
Selon la documentation de Lighthouse, ces formats « offrent une compression et une qualité supérieures à celles des formats JPEG et PNG ». La balise <picture> sert un format de repli aux navigateurs qui ne les lisent pas.
Découper les longues tâches JS
Toute tâche de plus de 50 ms est une « tâche longue », et le navigateur bloque les interactions pendant qu’elle s’exécute. Découpez-la avec scheduler.yield() ou setTimeout pour rendre la main au navigateur.
Déclarer width et height sur toutes les images
Sans dimensions explicites ou aspect-ratio CSS, le navigateur ne réserve pas l’espace. Le contenu sous l’image saute au moment du chargement.
Activer un CDN sur les statiques
Un CDN sert les fichiers statiques depuis un serveur proche de l’internaute. Le temps de récupération baisse pour les visiteurs éloignés du serveur d’origine.
Différer les scripts tiers
Balises marketing, mesure d’audience et outils de chat : leur code s’exécute sur le thread principal, celui qui répond aussi aux clics. Chargez-les après l’événement load ou à la première interaction.
Réserver la place des annonces et du bandeau cookies
Donnez une hauteur minimale en CSS à l’emplacement, avant le chargement de l’annonce. Un bandeau cookies superposé en bas de l’écran ne pousse pas le contenu ; inséré en haut de la page, il le décale.
Héberger les polices sur votre domaine
Une police servie par un domaine tiers demande une connexion supplémentaire. Hébergez-la en WOFF2, préchargez-la et déclarez font-display: swap : le texte s’affiche sans attendre la police. Une police de repli aux dimensions proches limite le décalage au changement.
Réduire la taille du DOM
Un DOM volumineux alourdit chaque recalcul de style et de mise en page après une interaction. Supprimez les conteneurs imbriqués inutiles et les longues listes cachées générées d’avance, comme certains menus.
Activer le rendu côté serveur
Sur un site React, Vue ou Angular rendu côté client, le contenu n’apparaît qu’après l’exécution du JavaScript. Un rendu serveur ou une génération statique (Next.js, Nuxt, Astro ou SvelteKit) envoie une page HTML déjà remplie.
Core Web Vitals et SEO : impact réel, données sourcées.
Ces métriques comptent-elles pour le classement ? Oui : Google écrit que « les Core Web Vitals sont utilisées par nos systèmes de classement ». Elles ne priment pas pour autant sur la pertinence : la recherche Google « s’efforce de toujours afficher le contenu le plus pertinent, même si l’expérience sur la page est décevante ».
Il n’existe pas non plus de signal unique d’expérience sur la page. Google le précise dans sa documentation : « Il n’y a pas qu’un seul signal. Nos principaux systèmes de classement tiennent compte de différents signaux qui coïncident avec l’expérience globale sur la page. »
Selon la même page, il existe pour de nombreuses requêtes beaucoup de contenus utiles : dans ce cas, « offrir une bonne expérience sur la page peut contribuer à votre réussite ».
L’étude de Backlinko (208 085 pages) compare le LCP, le FID et le CLS au taux de rebond, aux pages vues et au temps passé. Le LCP et le CLS n’y montrent pas de lien net. Seul le FID, remplacé depuis par l’INP, montre des indices de corrélation avec les pages vues par session.
L’étude d’Advanced Web Ranking (mai 2022) a analysé 3 millions de pages du top 20 de Google : plus la position est haute, plus le LCP est bas. Le FID et le CLS n’y montrent pas de corrélation nette, et l’auteur rappelle qu’une corrélation ne prouve pas une cause.
Visez donc le seuil « Bon » sur les groupes d’URL qui portent votre trafic, sans chercher la note parfaite. Google prévient qu’un bon rapport dans la Search Console ne garantit pas une place en haut des résultats. Il ajoute qu’« essayer d’obtenir un score parfait uniquement pour des raisons de SEO n’est pas forcément pertinent ».
Sources externes citées dans ce guide
- web.dev, « Web Vitals » (Philip Walton, publié le 4 mai 2020, mis à jour le 31 octobre 2024). Définition des trois métriques, seuils et 75e percentile.
- Google Search Central, « Comprendre les signaux Web essentiels et les résultats de recherche Google » (mise à jour du 18 décembre 2025). Définition officielle et seuils côté recherche.
- Google Search Central, « Comprendre l’expérience sur la page dans les résultats de recherche Google » (mise à jour du 25 septembre 2026). Rôle des trois métriques dans le classement, absence de signal unique et de garantie de position.
- web.dev, « Interaction to Next Paint devient Core Web Vitals le 12 mars » (Jeremy Wagner et Rick Viscomi, mis à jour le 31 janvier 2024). Remplacement du FID par l’INP et calendrier de retrait du FID.
- web.dev, « Interaction to Next Paint (INP) ». Calcul de l’INP, différence avec le FID et part du temps passé après le chargement.
- web.dev, « Cumulative Layout Shift (CLS) ». Fenêtres de session et décalages exclus du calcul.
- web.dev, « Optimiser le Largest Contentful Paint ». Les quatre sous-parties du LCP.
- web.dev, « Optimiser les longues tâches ». Seuil de 50 ms d’une tâche longue.
- Google, « À propos de PageSpeed Insights ». Période de 28 jours et règle de réussite de l’évaluation.
- Aide de la Search Console, « Rapport Core Web Vitals ». États du rapport et suivi de validation sur 28 jours.
- Aide de la Search Console, « Rapport d’indexation des vidéos ». Erreur « Impossible de déterminer la position et la taille de la vidéo ».
- Chrome for Developers, « Présentation de CrUX ». Données de terrain du Chrome User Experience Report et usage par la recherche Google.
- Google Search Central, « Indexation orientée mobile : bonnes pratiques » (mise à jour du 20 février 2026). Version mobile utilisée pour l’indexation et le classement.
- Chrome for Developers, « Diffuser des images dans des formats modernes ». Compression des formats AVIF et WebP.
- GoogleChrome/web-vitals sur GitHub. Bibliothèque open source pour mesurer le LCP, l’INP et le CLS chez ses visiteurs.
- Backlinko, « We Analyzed 208K Webpages. Here’s What We Learned About Core Web Vitals and UX » (Brian Dean, mise à jour du 14 avril 2025). Lien entre le LCP, le FID, le CLS et le comportement des visiteurs, mesuré sur des données de la Search Console et de Google Analytics.
- Advanced Web Ranking, « Core Web Vitals Study 2022 » (Philip Petrescu, 10 mai 2022). Lien entre LCP, FID, CLS et position dans le top 20 de Google.