Core Web Vitals : c’est quoi et comment les améliorer

Les Core Web Vitals sont trois mesures créées par Google pour dire si une page se charge vite, répond vite et reste stable pendant qu’on la lit. Elles s’appellent LCP, INP et CLS. Si votre site est lent, ou si les boutons bougent au moment où l’on clique, ces mesures le montrent avec des chiffres. Voici ce qu’elles veulent dire, comment les lire et comment les corriger, sans promettre de miracle sur votre classement.

Core Web Vitals : c’est quoi ?

Ce sont trois indicateurs qui mesurent l’expérience réelle d’un visiteur sur une page. Ils ont été choisis par Google parce qu’ils traduisent des gênes concrètes : attendre devant un écran vide, cliquer sans effet, voir le texte sauter.

Selon web.dev, une page est considérée comme « bonne » seulement si elle atteint les trois objectifs en même temps, au 75e centile. Le 75e centile veut dire ceci : sur 100 visites, on regarde le résultat qui sépare les 75 meilleures des 25 moins bonnes. Si ce résultat est bon, la page passe. Cela évite de juger un site sur ses meilleurs cas seulement.

LCP : la vitesse d’affichage du contenu principal

Le LCP (Largest Contentful Paint) mesure le moment où le plus grand élément visible de la page est affiché. En général, c’est une grande image, une vidéo ou un gros bloc de texte.

Seuils de web.dev :

• Bon : 2,5 secondes ou moins.
• À améliorer : entre 2,5 et 4 secondes.
• Mauvais : plus de 4 secondes.

Pour un cabinet, le LCP est souvent la photo en haut de l’accueil. Pour un restaurant, c’est la grande image du plat ou de la salle. Si cette image pèse 3 Mo, tout le reste attend.

INP : la réactivité quand on clique

L’INP (Interaction to Next Paint) mesure le temps entre un clic, un toucher ou une touche du clavier, et le moment où l’écran réagit visuellement. Selon web.dev, la valeur retenue représente la pire interaction de la visite, en ignorant une valeur extrême tous les 50 gestes. Le défilement, le survol et le zoom ne comptent pas.

Seuils de web.dev :

• Bon : 200 millisecondes ou moins.
• À améliorer : de 200 à 500 millisecondes.
• Mauvais : plus de 500 millisecondes.

INP a remplacé FID, l’ancienne mesure du délai avant la première interaction. web.dev indique qu’INP est devenu une mesure stable des Core Web Vitals en 2024. Si un outil ou un prestataire vous parle encore de FID, l’information est dépassée.

CLS : la stabilité de la mise en page

Le CLS (Cumulative Layout Shift) mesure les déplacements inattendus des éléments pendant que la page est affichée. Vous l’avez déjà vécu : vous allez appuyer sur un bouton, une bannière apparaît, le bouton descend et vous cliquez au mauvais endroit.

Seuils de web.dev :

• Bon : 0,1 ou moins.
• Mauvais : plus de 0,25.
• Entre les deux : à améliorer.

Le CLS n’a pas d’unité : c’est un score. Les décalages qui suivent de peu un clic ou une touche de l’utilisateur ne sont pas comptés.

Comment mesurer son score

Vous avez trois outils gratuits.

• PageSpeed Insights, de Google : il affiche les données de vrais utilisateurs quand elles existent, et un test en laboratoire fait avec Lighthouse.
• Search Console, de Google : son rapport Core Web Vitals montre comment vos pages se comportent, page par page. Google le recommande dans sa documentation.
• Notre analyse gratuite : elle lance Google Lighthouse sur votre page en version mobile et vous donne des corrections concrètes, avec le détail de l’élément qui fixe votre LCP.

Données de terrain et données de laboratoire

Les données de terrain viennent de vraies personnes, avec leurs téléphones, leurs réseaux et leurs habitudes. Les données de laboratoire viennent d’un test contrôlé : un seul appareil simulé, un seul réseau, un seul lieu. web.dev explique que les deux peuvent différer, par exemple parce qu’un test en laboratoire part d’un cache vide, ou parce que le CLS réel inclut les décalages qui arrivent plus tard pendant le défilement.

Notre règle : utilisez le terrain pour savoir si vous avez un problème, et le laboratoire pour chercher la cause. Un petit site peut n’avoir aucune donnée de terrain faute de visites. Dans ce cas, seul le laboratoire vous donne une indication.

Causes fréquentes et corrections concrètes

Ces correctifs sont des pratiques courantes. Leur effet dépend de chaque site, il faut mesurer avant et après.

LCP trop lent

• Image d’accueil trop lourde. Compressez-la, choisissez un format moderne (WebP ou AVIF) et servez une taille adaptée à l’écran. Une photo de 4 000 pixels de large n’a pas sa place sur un téléphone.
• Image principale chargée trop tard. Ne la chargez pas en différé : web.dev note qu’un élément qui arrive tard remplace le candidat actuel et repousse le LCP.
• Serveur lent. Le LCP inclut le temps de réponse du serveur. Un hébergement bas de gamme ou une page générée à chaque visite pèse sur tout.
• Polices. Selon web.dev, un texte en police web n’est pas compté comme affiché pendant la période de blocage de la police. Limitez le nombre de polices et de graisses.

INP trop élevé

• Scripts tiers (chat, suivi, widgets d’avis, pixels publicitaires) : chacun occupe le navigateur. Retirez ceux qui ne servent à rien et chargez les autres après le contenu.
• Trop de JavaScript : un site bâti sur un grand ensemble de code réagit plus lentement sur un téléphone d’entrée de gamme.
• Menus et formulaires lourds : si un clic déclenche un long calcul, l’écran se fige. Allégez ce que fait le clic.

CLS trop haut

• Images et vidéos sans dimensions. Indiquez largeur et hauteur, pour que la place soit réservée avant l’arrivée du fichier.
• Polices qui changent la taille du texte au moment où elles s’affichent : choisissez une police de repli de taille proche.
• Bannières, publicités et widgets qui s’insèrent au-dessus du texte : réservez leur emplacement dès le départ.
• Contenu inséré après coup : web.dev recommande de réserver l’espace tout de suite et d’afficher un indicateur de chargement.

L’impact réel sur le classement

Google ne dit pas que les Core Web Vitals font monter un site. Sa documentation dit que de bons résultats sont recommandés pour réussir dans la recherche et pour l’expérience de l’utilisateur, et que cela, avec les autres aspects de l’expérience de page, « s’aligne avec ce que nos systèmes de classement principaux cherchent à récompenser ».

Notre avis de studio : c’est un signal parmi beaucoup d’autres. Un contenu qui répond mal à la question ne sera pas sauvé par un LCP à 1,8 seconde. L’inverse est vrai aussi : un site très lent fait fuir des visiteurs, quel que soit son classement, et ceux qui partent ne vous appellent pas. Nous traitons donc la vitesse comme une qualité de service, pas comme une astuce de SEO. Elle compte aussi pour les assistants IA, puisque Google range une bonne expérience de page parmi ses conseils pour apparaître dans ses fonctions IA (voir notre article sur le référencement ChatGPT).

Si vous préparez une refonte, mettez ces seuils dans le cahier des charges : notre guide de refonte de site explique comment les demander. Pour aller plus loin sur le diagnostic, voyez aussi l'audit SEO gratuit en 5 minutes.

Questions fréquentes

Quel est le bon score Core Web Vitals ?

Il n’y a pas de note sur 100 pour les Core Web Vitals : il y a trois seuils. Selon web.dev, une page est bonne avec un LCP de 2,5 secondes ou moins, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins, au 75e centile. Le score de performance de Lighthouse, lui, est une autre note.

Mon site est rapide chez moi mais mauvais dans l’outil, pourquoi ?

Votre ordinateur et votre connexion sont probablement meilleurs que ceux de vos visiteurs. Les outils simulent un téléphone moyen sur un réseau moyen, et les données de terrain reflètent les vrais appareils. Testez sur mobile, pas sur votre poste.

Faut-il viser 100 partout ?

Non. Atteindre les seuils « bon » suffit pour les Core Web Vitals. Au-delà, chaque gain coûte plus de travail pour un bénéfice plus faible. Mieux vaut passer ce temps sur le contenu.