Core Web Vitals : définition, seuils, mesure et optimisation

Que sont les Core Web Vitals ?

Les Core Web Vitals, parfois appelés « Signaux Web essentiels » dans la documentation française de Google, sont le sous-ensemble des Web Vitals qui s'applique à toutes les pages web. Selon web.dev, chacune de ces métriques représente une facette distincte de l'expérience utilisateur et se mesure sur le terrain, lors de visites réelles :

• LCP (Largest Contentful Paint) : le temps d'affichage du plus grand élément visible, qu'il s'agisse d'une image, d'une vidéo ou d'un bloc de texte.
• INP (Interaction to Next Paint) : le délai de réaction de la page aux clics, aux appuis sur un écran tactile et aux touches du clavier.
• CLS (Cumulative Layout Shift) : l'ampleur des décalages inattendus de la mise en page.

Google indique que les Core Web Vitals sont utilisés par ses systèmes de classement, depuis la mise à jour de l'expérience sur la page déployée sur mobile entre juin et août 2021, puis sur ordinateur à partir de février 2022. Il précise toutefois que la recherche s'efforce toujours d'afficher le contenu le plus pertinent, même si l'expérience sur la page est décevante, et que de bons résultats dans le rapport Core Web Vitals ne garantissent pas une place en haut des résultats.

Les seuils du LCP, de l'INP et du CLS

Chaque métrique est classée en trois niveaux, avec les mêmes seuils dans PageSpeed Insights et dans la Search Console, qui les nomme « Bon », « Amélioration nécessaire » et « Médiocre ».

Le 75e centile, sur 28 jours

Les seuils s'appliquent à l'ensemble des visites, séparément sur mobile et sur ordinateur. La méthode de définition des seuils retient le 75e centile : une métrique est bonne si au moins 75 % des pages vues atteignent le seuil « bon », mauvaise si au moins 25 % atteignent le seuil « mauvais ». Un LCP de 2 secondes au 75e centile est donc bon, un LCP de 5 secondes mauvais. Dans PageSpeed Insights et la Search Console, les données de terrain portent sur les 28 derniers jours.

Réussir l'évaluation Core Web Vitals

Une page réussit l'évaluation lorsque ses trois métriques sont bonnes au 75e centile ; faute de données d'INP suffisantes, PageSpeed Insights la juge sur le LCP et le CLS. Dans la Search Console, un groupe d'URL prend l'état de sa métrique la moins performante : un CLS « Médiocre » suffit à le classer en « Médiocre ».

Ce que mesure chaque métrique

LCP : l'affichage du contenu principal

Le LCP mesure le délai d'affichage de la plus grande image, vidéo ou section de texte visible, à partir du moment où l'utilisateur a commencé à naviguer vers la page. Il inclut les redirections et le temps de réponse du serveur, ce qui explique une partie des écarts entre terrain et laboratoire. Selon l'Almanach Web 2024 de HTTP Archive, cité par web.dev, l'élément LCP est une image sur 73 % des pages mobiles.

INP : la réactivité aux interactions

L'INP observe la latence de toutes les interactions de la visite (clics, appuis sur un écran tactile, touches du clavier) et retient la plus lente, en écartant les valeurs aberrantes ; le survol et le défilement ne comptent pas. Chaque latence additionne le délai d'entrée, la durée de traitement du code et le délai de présentation de l'image suivante. L'INP a remplacé le FID dans les Core Web Vitals le 12 mars 2024.

CLS : la stabilité visuelle

Le CLS mesure les décalages inattendus de la mise en page, comme un bouton qui bouge au moment du clic. Chaque décalage est noté en multipliant la part de la fenêtre d'affichage touchée par la distance parcourue, rapportée à la plus grande dimension de cette fenêtre. Les décalages rapprochés forment une fenêtre de session (moins d'une seconde entre deux décalages, cinq secondes au plus), et le CLS retient 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 touche du clavier sont exclus.

Données de terrain et données de laboratoire

Les données de laboratoire sont obtenues en chargeant la page dans un environnement contrôlé, avec un appareil et un réseau prédéfinis : c'est le principe de Lighthouse. Les données de terrain viennent des visites réelles et reflètent les appareils, les réseaux et la localisation de vos visiteurs. Les outils de Google les tirent du rapport d'expérience utilisateur Chrome (CrUX), que la recherche Google utilise pour le facteur de classement lié à l'expérience sur la page.

Sans visiteur, Lighthouse ne peut pas mesurer l'INP et s'appuie sur le Total Blocking Time (TBT), un indicateur approchant ; il ignore aussi les décalages postérieurs au chargement, par exemple pendant le défilement. Quand vous disposez des deux, fixez vos priorités à partir des données de terrain et servez-vous du laboratoire pour reproduire un problème et tester une correction.

Le score sur 100 de PageSpeed Insights

Le score de performance sur 100 est calculé par Lighthouse dans un environnement simulé : 90 et plus est bon, de 50 à 89 à améliorer, moins de 50 médiocre. C'est une note de laboratoire, distincte de l'évaluation Core Web Vitals : un bon score ne garantit pas une bonne expérience pour les visiteurs réels, et Google estime que viser un score parfait uniquement pour le SEO n'est pas forcément pertinent.

Comment mesurer vos Core Web Vitals

PageSpeed Insights, pour une page

PageSpeed Insights affiche en haut les données de terrain de l'URL, ou de l'origine si l'URL n'en a pas assez : la répartition des visites par niveau et la valeur au 75e centile. Le diagnostic Lighthouse, en dessous, liste les pistes d'amélioration. Web.dev recommande de toujours commencer par les données réelles quand elles existent.

La Search Console, pour tout le site

Le rapport Core Web Vitals regroupe les URL indexées qui offrent une expérience similaire, sur mobile et sur ordinateur, à partir des données de CrUX. Après une correction, le bouton « Démarrer le suivi » lance une surveillance de 28 jours : si le problème n'apparaît plus sur aucune URL pendant cette période, il est considéré comme résolu.

Notre test gratuit

Pour obtenir les deux types de données en une analyse, mesurez vos Core Web Vitals avec notre test gratuit. Il interroge PageSpeed Insights sur mobile et sur ordinateur : le score s'affiche immédiatement, et le rapport détaillé (Core Web Vitals, données de terrain des 28 derniers jours, recommandations) se débloque en laissant vos coordonnées.

Causes et corrections les plus courantes

Améliorer le LCP

Web.dev découpe le LCP en quatre phases qui s'additionnent : le temps de réponse du serveur (TTFB), le délai avant le chargement de la ressource LCP, la durée de ce chargement et le délai d'affichage de l'élément. Les deux délais doivent tendre vers zéro. Mesurez cette répartition avant d'agir : selon les données réelles de Chrome, la majorité des origines au LCP médiocre passent moins de 10 % de leur LCP au 75e centile à télécharger l'image LCP, le temps se perd donc surtout ailleurs.

• Rendre l'image principale visible dans le HTML initial (img avec src ou srcset, pas de data-src qui attend le JavaScript).
• Lui donner la priorité avec fetchpriority="high" et ne jamais la charger en différé (loading="lazy").
• Alléger le CSS et différer le JavaScript qui bloquent le rendu.
• Servir des images compressées, en WebP ou AVIF, à la taille affichée.
• Réduire le TTFB : moins de redirections, mise en cache des pages, CDN proche des visiteurs.

Améliorer l'INP

• Découper les tâches longues (plus de 50 millisecondes), qui peuvent empêcher le navigateur de répondre rapidement, en lui rendant la main régulièrement.
• Supprimer le JavaScript inutile, notamment les anciennes balises d'un gestionnaire de balises.
• Limiter le travail de rendu : un DOM très volumineux ou du HTML généré en masse par JavaScript peut allonger le délai de présentation.

Améliorer le CLS

Les causes les plus courantes sont les images sans dimensions, les contenus injectés sans espace réservé (publicités, intégrations, iframes) et les polices web.

• Déclarer width et height, ou aspect-ratio, sur les images et les vidéos : selon web.dev, 66 % des pages ont au moins une image sans dimensions.
• Réserver l'espace des contenus chargés après coup, par exemple avec min-height, et afficher les bandeaux de cookies en superposition plutôt qu'en poussant le contenu.
• Précharger les polices essentielles et prévoir une police de repli proche ; font-display: optional peut éviter une nouvelle mise en page.
• Animer avec transform plutôt qu'avec top ou left, et rendre les pages éligibles au cache amélioré du navigateur (bfcache), qui restaure une page sans décalage lors d'un retour arrière.

Sur WordPress, notre guide site WordPress lent détaille six chantiers par ordre de rentabilité : hébergement et version de PHP, cache de pages, extensions, thème, images et base de données. Notre article pourquoi mon site est lent passe en revue les dix causes de lenteur les plus fréquentes, tous outils confondus.

Exemple chiffré : trois métriques, trois chantiers

Prenons un site de services dont les données de terrain mobiles affichent un LCP de 4,2 s, un CLS de 0,18 et un INP de 420 ms : le LCP est mauvais, le CLS et l'INP sont à améliorer, la page échoue à l'évaluation. La conversion des images en WebP et l'activation du cache serveur ramènent le LCP à 2,1 s. La déclaration des dimensions des visuels fait tomber le CLS à 0,05. Le retrait de deux scripts de suivi redondants abaisse l'INP à 180 ms. Les trois métriques repassent au vert et, les données de terrain couvrant 28 jours glissants, la page réussit l'évaluation en un mois environ.

Par où commencer

La Search Console recommande de corriger d'abord les URL à l'état « Médiocre », puis les problèmes qui touchent le plus d'URL ou vos pages les plus importantes. Travaillez par modèle de page (accueil, article, fiche produit) plutôt qu'URL par URL : Google part du principe que les pages d'un même groupe partagent un cadre commun et les mêmes causes. Notez les valeurs avant chaque correction, car les données de terrain n'en intègrent l'effet que progressivement.

C'est la démarche de notre audit gratuit : nous mesurons vos Core Web Vitals sur données réelles, hiérarchisons les correctifs par gain estimé et suivons leur validation dans la Search Console, en distinguant ce qui se corrige en une journée (compression, cache, dimensions d'images) de ce qui demande un chantier de fond (hébergement, thème, scripts tiers).

Questions fréquentes sur les Core Web Vitals