Core Web Vitals : comprendre et améliorer vos scores LCP, INP et CLS

Les Core Web Vitals, appelés Signaux Web essentiels dans la Search Console en français, sont les trois mesures que Google utilise pour juger l'expérience réelle d'une page : sa vitesse d'affichage, sa réactivité et sa stabilité. Ce guide est le volet technique de notre article sur la vitesse de chargement, qui explique ce qu'un site lent vous coûte. Ici, nous détaillons chaque métrique, la façon dont Google la mesure et les corrections qui la font progresser.

Les trois métriques et leurs seuils

L'INP a remplacé l'ancien indicateur FID (First Input Delay) le 12 mars 2024. Il observe la latence de toutes les interactions de la visite et retient une valeur sous laquelle se situent toutes, ou presque toutes, ces interactions. Les articles qui parlent encore du FID comme d'un Core Web Vital sont antérieurs à ce changement.

Comment Google mesure : vos vrais visiteurs, sur 28 jours

Google ne juge pas vos Core Web Vitals sur un test ponctuel, mais sur les visites réelles d'utilisateurs de Chrome, réunies dans le rapport d'expérience utilisateur de Chrome (CrUX). Trois règles en découlent.

• Le 75e centile. Une page est jugée bonne si au moins trois visites sur quatre atteignent le seuil. Les visites les plus lentes, souvent sur des téléphones modestes ou des réseaux faibles, comptent donc beaucoup.
• Mobile et ordinateur séparés. Chaque appareil a son verdict. Le mobile est presque toujours le plus difficile.
• 28 jours glissants. Les données couvrent les 28 derniers jours. Une correction met donc environ quatre semaines à se refléter entièrement.

Il faut aussi assez de visites. Si une page manque de données, PageSpeed Insights affiche celles de l'ensemble du site ; si le site entier en manque, il n'affiche aucune donnée réelle. C'est fréquent pour un site neuf ou peu visité : vous ne pouvez alors vous fier qu'aux tests de laboratoire.

Pourquoi PageSpeed Insights et la Search Console ne disent pas la même chose

C'est la question la plus fréquente. Les deux outils ne mesurent pas la même chose.

• PageSpeed Insights affiche deux blocs. En haut, les données réelles de vos visiteurs sur 28 jours, quand elles existent. En bas, un test de laboratoire Lighthouse, lancé à l'instant dans un environnement simulé, avec une note sur 100. Cette note n'est pas un Core Web Vital : c'est un outil de diagnostic.
• Le rapport Core Web Vitals de la Search Console regroupe vos pages par familles semblables (articles, fiches produits, pages de service) et leur donne un statut : « Bon », « Amélioration nécessaire » ou « Médiocre ». Un groupe prend le statut de sa plus mauvaise métrique : un CLS médiocre suffit à classer tout le groupe en « Médiocre », même si le reste est bon.

Un test de laboratoire peut donc être excellent pendant que vos visiteurs vivent une page lente, par exemple parce qu'un script publicitaire ou une bannière ne se charge qu'en situation réelle. Et à l'inverse. Pour le classement, ce sont les données réelles qui comptent ; le laboratoire sert à trouver et vérifier les corrections.

Les Core Web Vitals comptent-ils pour le classement Google ?

Oui, sans être décisifs. Google recommande vivement d'obtenir de bons Core Web Vitals, et indique que cette recommandation rejoint ce que ses principaux systèmes de classement cherchent à récompenser. Mais il précise aussi qu'il affiche toujours le contenu le plus pertinent, même si l'expérience de la page est décevante. Quand de nombreuses pages répondent aussi bien à une requête, une bonne expérience peut faire la différence.

Google ajoute qu'essayer d'obtenir un score parfait uniquement pour le référencement n'est pas forcément pertinent. Visez le vert pour vos visiteurs, puis concentrez vos efforts sur le contenu.

LCP : causes et corrections

Le LCP se décompose en quatre temps : la réponse du serveur (TTFB), le délai avant que le navigateur commence à télécharger l'élément principal, la durée de ce téléchargement, puis le délai avant son affichage. Repérez lequel pèse le plus : Lighthouse et le panneau Performances de Chrome le montrent.

• Un serveur lent à répondre. Hébergement saturé, page reconstruite à chaque visite, serveur loin des visiteurs. Servez des pages générées à l'avance ou mises en cache, idéalement par un réseau de diffusion (CDN).
• Une image principale découverte trop tard. Si elle est chargée par un script ou en image de fond CSS, le navigateur la trouve tardivement. Placez-la dans le HTML, donnez-lui l'attribut fetchpriority="high", et ne lui appliquez jamais le chargement différé (loading="lazy"), que web.dev déconseille pour l'élément principal.
• Une image trop lourde. Redimensionnez-la à sa taille d'affichage réelle et servez-la en WebP ou AVIF.
• Un affichage bloqué par des feuilles de style, des polices ou des scripts chargés avant le contenu. Allégez ce qui est indispensable au premier affichage et différez le reste.
• Un contenu construit seulement par JavaScript. Si le titre et l'image n'existent qu'après l'exécution des scripts, le LCP attend tout le chargement de l'application. Un rendu côté serveur ou un prérendu règle le problème à la source.

INP : causes et corrections

Une interaction se décompose en trois temps : le délai avant que la page commence à traiter le clic, la durée du traitement, puis le délai avant que le résultat s'affiche. Un INP médiocre vient presque toujours d'un processeur occupé par du JavaScript.

• Des scripts tiers accumulés : outils de suivi, chat, widgets d'avis, pixels publicitaires. Faites l'inventaire, retirez ce qui ne sert plus, chargez le reste après l'affichage.
• Des tâches longues. Un traitement qui monopolise le processeur bloque toutes les interactions. Les développeurs le découpent en tâches plus courtes, ou le déplacent dans un Web Worker.
• Un traitement trop lourd au clic. Affichez d'abord un retour visuel (bouton enfoncé, indicateur de chargement), puis faites le calcul.
• Une page très chargée. Un très grand nombre d'éléments HTML rend chaque mise à jour de l'affichage plus coûteuse : sur les longues listes, n'affichez que ce qui est visible.

L'INP se mesure surtout sur le terrain : un test de laboratoire ne clique pas comme vos visiteurs. Le panneau Performances de Chrome permet de reproduire une interaction lente et de voir quel script la ralentit.

CLS : causes et corrections

Le CLS mesure ces moments où le texte saute au moment où vous alliez cliquer. Web.dev en cite quatre causes principales.

• Des images et des vidéos sans dimensions. Indiquez leur largeur et leur hauteur (ou un rapport d'aspect en CSS) pour que le navigateur réserve la place avant le chargement.
• Des publicités, cartes, vidéos intégrées ou iframes sans place réservée. Donnez à leur conteneur une hauteur minimale.
• Du contenu injecté au-dessus de ce qui est déjà affiché : bandeau promotionnel, bannière de cookies insérée en haut de page, message qui pousse le texte. Affichez ces éléments en superposition ou réservez leur place dès le départ.
• Les polices web, qui changent la taille du texte en arrivant. Limitez le nombre de fichiers de police, hébergez-les avec le site et choisissez une police de secours aux proportions proches.

Les animations comptent aussi : animez la transformation et l'opacité des éléments, pas leur position ou leur taille dans la mise en page. Enfin, une page compatible avec le cache de navigation du navigateur (bfcache) se réaffiche instantanément au retour arrière, sans décalage.

Mesurer vos Core Web Vitals

• Le rapport Core Web Vitals de la Search Console : la vue d'ensemble du site, par groupes de pages, sur données réelles. C'est le point de départ.
• PageSpeed Insights : le détail d'une adresse, avec les données réelles en haut et un diagnostic Lighthouse en bas.
• Les outils de développement de Chrome : le panneau Performances affiche vos propres mesures en direct, à côté des données réelles de la page quand elles existent.
• La bibliothèque web-vitals, publiée par Google : quelques lignes de code envoient les mesures de vos vrais visiteurs à votre outil d'analyse. C'est la solution pour un site qui n'a pas assez de trafic pour figurer dans les données de Chrome.

Plan d'action pas à pas

1. 1 Ouvrez le rapport Core Web Vitals de la Search Console, en commençant par le mobile, et notez les groupes « Médiocre ».
2. 2 Pour chaque groupe, prenez une adresse représentative et analysez-la dans PageSpeed Insights.
3. 3 Identifiez la métrique en défaut et sa cause, avec le détail du diagnostic Lighthouse.
4. 4 Corrigez sur le modèle de page plutôt que page par page : une correction du gabarit des articles règle tous les articles.
5. 5 Vérifiez en laboratoire que la correction fonctionne, puis mettez-la en ligne.
6. 6 Dans le rapport Core Web Vitals de la Search Console, lancez le suivi du problème corrigé (« Démarrer le suivi ») : l'outil le surveille pendant 28 jours avant de le déclarer résolu.

Ce que nous appliquons sur notre propre site

Les Core Web Vitals se règlent plus facilement à la construction qu'après coup. Sur le site de DMA Digital, chaque page est générée à l'avance en HTML et servie par un CDN, sans base de données à interroger à chaque visite. Les polices sont hébergées avec le site, les images sont en WebP ou en AVIF, et les vidéos ne se chargent qu'à l'approche de l'écran. Les éléments animés sont dessinés à leur taille définitive dès le premier affichage, pour que rien ne bouge quand les scripts prennent le relais.

Sur un site existant, quand les mauvais scores viennent d'un thème lourd, d'un constructeur de pages ou d'une pile d'extensions, les corrections ont des limites. Notre page refonte de site explique quand reprendre la base devient plus raisonnable, et notre guide de l'hébergement web aide à choisir un serveur qui répond vite.

Pour savoir où en est votre site, notre audit gratuit analyse à la main sa vitesse, son affichage mobile, son référencement et sa sécurité, puis vous envoie les priorités par e-mail sous deux jours ouvrés.