Les Core Web Vitals expliqués : LCP, INP et CLS (et comment les améliorer)

Les Core Web Vitals sont trois métriques que Google utilise pour mesurer l’expérience réelle d’une page : la vitesse de chargement, la rapidité de réaction et la stabilité pendant le chargement. Elles font partie des signaux d’expérience de page que Google prend en compte dans le classement et – surtout – elles reflètent ce que les visiteurs ressentent réellement sur votre site.

Les trois Core Web Vitals

Une page réussit quand au moins 75 % des visites réelles (le 75e percentile) atteignent le seuil « bon » pour les trois métriques.

L’INP a remplacé le First Input Delay (FID) comme Core Web Vital en mars 2024. L’INP est plus exigeant : il tient compte de la réactivité des interactions pendant toute la visite, pas seulement de la première.

Données terrain et données de laboratoire

Les données terrain proviennent de vrais utilisateurs de Chrome et sont collectées dans le Chrome UX Report (CrUX) sur une fenêtre glissante de 28 jours. C’est ce que Google utilise pour l’expérience de page. Vous pouvez les consulter dans le rapport Core Web Vitals de Search Console et dans PageSpeed Insights.

Les données de laboratoire proviennent d’un test simulé, comme Lighthouse, sur un appareil et un réseau fixes. Elles sont idéales pour déboguer et tester des changements, mais ce n’est pas ce que Google utilise pour le classement – et elles ne peuvent pas mesurer directement l’INP (le Total Blocking Time en est l’indicateur de laboratoire le plus proche).

Les pages à faible trafic peuvent manquer de données terrain ; Google peut alors utiliser les données de pages similaires ou de l’ensemble du site (l’« origine »).

Largest Contentful Paint (LCP)

Le LCP marque le moment où l’image ou le bloc de texte le plus grand de la fenêtre visible a fini de s’afficher – généralement l’image d’en-tête, un grand titre ou l’affiche d’une vidéo mise en avant.

Le LCP se décompose en quatre parties, qui orientent la correction :

1. Time to First Byte – le temps de réponse du serveur
2. Délai de chargement de la ressource – le temps avant que le navigateur commence à télécharger la ressource LCP
3. Durée de chargement de la ressource – la durée du téléchargement
4. Délai d’affichage de l’élément – le temps entre le téléchargement et l’affichage

Comment améliorer le LCP

• Accélérez le serveur : cache de pages, CDN, hébergement plus rapide et moins de requêtes en base de données
• Rendez l’image LCP découvrable tôt : utilisez une balise <img> classique dans le HTML (pas un arrière-plan CSS ni une image insérée en JavaScript) et ajoutez fetchpriority="high"
• Ne chargez jamais l’image LCP en différé
• Optimisez l’image : bonnes dimensions, WebP ou AVIF, bonne compression
• Réduisez les ressources bloquant l’affichage : intégrez le CSS critique, différez le JavaScript non critique
• Utilisez preconnect vers les origines tierces nécessaires, comme un CDN d’images

Interaction to Next Paint (INP)

L’INP mesure le délai entre une interaction de l’utilisateur – un clic, un toucher ou une frappe – et la mise à jour visuelle suivante à l’écran. Il retient l’une des interactions les plus lentes de la visite.

Un mauvais INP vient généralement de trop de JavaScript exécuté sur le thread principal, qui empêche le navigateur de réagir rapidement.

Comment améliorer l’INP

• Réduisez et découpez le JavaScript : supprimez les bibliothèques inutilisées, découpez le code et ne chargez les fonctionnalités qu’au besoin
• Fractionnez les tâches longues : les tâches de plus de 50 ms bloquent le thread principal ; rendez la main au navigateur entre les blocs de travail
• Auditez les scripts tiers : gestionnaires de balises, widgets de chat, outils d’A/B testing et scripts publicitaires sont des coupables fréquents
• Gardez un DOM léger : les très grandes pages ralentissent chaque mise à jour
• Donnez un retour visuel immédiat à l’interaction, puis effectuez le travail lourd ensuite

Cumulative Layout Shift (CLS)

Le CLS mesure les déplacements inattendus de la mise en page – l’expérience agaçante d’un bouton qui se dérobe juste au moment où l’on tape dessus. Il évalue la quantité de contenu qui bouge et la distance parcourue.

Comment améliorer le CLS

• Indiquez largeur et hauteur des images et vidéos, ou utilisez aspect-ratio en CSS, pour réserver l’espace
• Réservez de l’espace pour les publicités, contenus intégrés et iframes avec des conteneurs de taille fixe
• Évitez d’insérer du contenu au-dessus du contenu existant, comme des bannières qui repoussent la page après le chargement
• Utilisez font-display: swap avec prudence et préchargez les polices web clés, ou utilisez des métriques de polices de repli pour éviter que le texte ne se réorganise
• Animez avec transform, pas avec des propriétés comme top ou height qui déclenchent un recalcul de la mise en page

Une méthode pratique

1. Consultez le rapport Core Web Vitals de Search Console pour voir quels groupes d’URL échouent et sur quelle métrique
2. Choisissez une URL représentative de chaque groupe en échec
3. Lancez un test de laboratoire pour diagnostiquer ce qui est lent
4. Corrigez au niveau du modèle – la plupart des problèmes touchent toutes les pages utilisant la même mise en page
5. Validez : dans Search Console, lancez la validation après le déploiement ; les données terrain mettent jusqu’à 28 jours à refléter les améliorations

Quel est le poids des Core Web Vitals dans le classement ?

Google a clairement indiqué que l’expérience de page est un signal parmi d’autres, et que la pertinence et l’utilité du contenu comptent davantage. Une page rapide au contenu faible ne dépassera pas une excellente page. Mais à pertinence égale, une meilleure expérience peut aider – et les pages plus rapides convertissent systématiquement mieux, ce qui compte indépendamment du classement.

Conseils par plateforme

WordPress

• Utilisez une extension de cache ou un cache côté hébergeur pour réduire le temps de réponse du serveur
• Choisissez un thème léger ; les constructeurs de pages lourds ajoutent souvent beaucoup de CSS et de JavaScript
• Auditez les extensions : chacune peut ajouter des scripts à toutes les pages et dégrader l’INP
• Utilisez une extension d’optimisation d’images qui sert du WebP ou de l’AVIF et ajoute les attributs de largeur et hauteur
• Retardez ou supprimez les scripts tiers inutiles sur la plupart des pages

Shopify

• Passez en revue les applications installées – beaucoup injectent des scripts sur toutes les pages même inutilisées
• Utilisez les fonctions d’images responsives intégrées au thème
• Limitez le nombre de sections et de carrousels sur l’accueil
• Compressez et redimensionnez les images avant de les téléverser

Sites sur mesure et riches en JavaScript

• Utilisez le rendu côté serveur ou la génération statique pour que le contenu s’affiche sans attendre le JavaScript
• Découpez le code par route et chargez les composants à la demande
• Mesurez l’INP réel avec la bibliothèque JavaScript web-vitals et envoyez-le à votre analytics, pour voir quelles interactions sont lentes

Mesurer vous-même les données des vrais utilisateurs

Search Console et PageSpeed Insights affichent des données Chrome agrégées, mais seulement pour les pages ayant assez de trafic et avec un décalage. Pour voir les Core Web Vitals de chaque page et de chaque visiteur, ajoutez un suivi des utilisateurs réels (RUM). La bibliothèque open source web-vitals remonte le LCP, l’INP et le CLS depuis les navigateurs des visiteurs ; vous pouvez envoyer ces valeurs à Google Analytics 4 ou à un autre outil. Le RUM enregistre aussi quel élément constituait le LCP et quelle interaction était la plus lente – exactement ce qu’il faut pour corriger le problème.

Un mot sur le Total Blocking Time et le Speed Index

Lighthouse remonte d’autres métriques que les Core Web Vitals. Le Total Blocking Time (TBT) mesure la durée de blocage du thread principal pendant le chargement et est corrélé à l’INP. Le First Contentful Paint (FCP) marque le moment où quelque chose apparaît pour la première fois. Le Speed Index mesure la rapidité avec laquelle la zone visible se remplit. Ce sont des diagnostics utiles, mais pas des Core Web Vitals.

Idées reçues

• « Il faut un score PageSpeed de 100 pour se classer. » Non. Pour l’expérience de page, ce qui compte est de passer les seuils des Core Web Vitals dans les données terrain, et la pertinence compte bien davantage.
• « Les Core Web Vitals ne comptent que pour Google. » Des pages plus rapides et plus stables améliorent les conversions et la satisfaction de tous les visiteurs, quelle que soit leur provenance.
• « Ajouter des extensions de cache aide. » Cumuler plusieurs extensions de cache ou d’optimisation provoque souvent des conflits. Utilisez une seule solution bien configurée.

À retenir

• Les Core Web Vitals mesurent le chargement (LCP), la réactivité (INP) et la stabilité visuelle (CLS).
• Les bons seuils sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1 au 75e percentile des visites réelles.
• Ce sont les données terrain des vrais utilisateurs de Chrome qui comptent ; les tests de laboratoire servent au diagnostic.
• Le LCP s’améliore généralement avec des serveurs plus rapides et des images d’en-tête mieux optimisées.
• L’INP s’améliore en réduisant et en découpant le JavaScript, surtout les scripts tiers.
• Le CLS s’améliore en réservant de l’espace pour les images, publicités et contenus intégrés.

Questions fréquentes

Pourquoi mes scores de laboratoire et terrain diffèrent-ils ?

Les tests de laboratoire simulent un seul appareil et un seul réseau. Les données terrain reflètent les appareils, réseaux et comportements de vos vrais visiteurs, y compris des interactions que les tests de laboratoire n’effectuent pas.

Combien de temps avant que les améliorations apparaissent dans Search Console ?

Les données terrain couvrent les 28 derniers jours : il faut donc jusqu’à quatre semaines pour qu’une correction soit pleinement prise en compte.

Les Core Web Vitals comptent-ils sur ordinateur ?

Oui. Google évalue séparément le mobile et l’ordinateur. Le mobile est généralement plus difficile à valider, car les appareils et les réseaux sont plus lents.

Qu’est-ce qu’un bon score PageSpeed ?

90 ou plus est un bon score. Mais ce score est un résumé de laboratoire ; pour l’expérience de page, ce qui compte est de passer les Core Web Vitals dans les données terrain.