Core Web Vitals : comprendre LCP, INP et CLS avant de corriger

Accessibilité et performance web · 6 min de lecture

Avant de corriger vos Core Web Vitals, identifiez ce que mesure chaque indicateur et d’où viennent les données. Le LCP mesure l’apparition du plus grand contenu éligible visible, l’INP la réactivité aux interactions et le CLS la stabilité visuelle. Une mauvaise valeur ne désigne pas automatiquement sa cause. Il faut relier le rapport à une page, un appareil et un comportement observable avant de choisir une intervention.

À retenir

• LCP, INP et CLS décrivent des problèmes différents.
• Les mesures des visiteurs et les tests de laboratoire se complètent.
• Une note globale ne remplace pas la lecture de chaque indicateur.
• Corrigez une cause documentée, puis vérifiez aussi le parcours utilisateur.

Comprendre les trois indicateurs

LCP : quand le contenu principal apparaît

Le Largest Contentful Paint mesure le moment où le plus grand élément de contenu éligible devient visible dans la zone affichée. Il peut s’agir d’une image, d’un bloc de texte ou d’un contenu vidéo, selon la définition de web.dev. Ce n’est ni le premier élément visible ni la fin du chargement de toute la page.

Commencez donc par identifier l’élément mesuré sur mobile et ordinateur. Ne supposez pas que la bannière est responsable : le candidat peut changer avec la mise en page.

INP : la réponse visuelle à une interaction

L’Interaction to Next Paint observe la latence des clics, appuis et interactions clavier pendant la visite. Il mesure le délai jusqu’à la prochaine mise à jour visuelle et retient une interaction parmi les plus lentes, avec un traitement des valeurs extrêmes. La documentation INP précise qu’il ne mesure pas tous les effets ultérieurs d’une action, notamment les opérations réseau asynchrones.

Un bouton qui affiche rapidement un état d’attente peut donc être réactif, alors que le résultat serveur arrive plus tard. Examinez les actions réellement utiles : ouvrir un filtre, changer une variante ou ajouter au panier.

CLS : les déplacements inattendus

Le Cumulative Layout Shift évalue les déplacements inattendus d’éléments visibles. Son score, sans unité de temps, retient la plus importante séquence de déplacements selon des fenêtres de mesure, comme l’explique web.dev sur le CLS. Ce n’est pas une durée de chargement ni l’addition de tous les mouvements possibles.

Une image sans espace réservé, une police ou un module inséré tardivement sont des pistes à examiner, pas des causes démontrées par le score seul.

Lire les seuils sans les transformer en promesse

La référence Web Vitals définit les seuils suivants pour une expérience classée bonne :

Ces seuils s’apprécient au 75e percentile, séparément sur mobile et ordinateur. Cela signifie que trois quarts des expériences mesurées ont une valeur inférieure ou égale à celle retenue. Ce n’est pas une moyenne. Les trois indicateurs doivent respecter leurs seuils pour que l’évaluation globale soit bonne. Une absence d’INP, par exemple faute d’interactions mesurées, ne doit pas être transformée en valeur nulle. Cela ne garantit ni des ventes supplémentaires ni une position dans les résultats de recherche.

Distinguer données réelles et laboratoire

Dans PageSpeed Insights, les données réelles issues de CrUX couvrent les 28 derniers jours. Si la page manque de données, le rapport peut utiliser celles de l’origine, qui regroupent les pages de la même origine, c’est-à-dire du même protocole, nom d’hôte et port. Cela ne regroupe pas automatiquement tous les sous-domaines. Si elles sont aussi insuffisantes, aucune mesure réelle n’est affichée. La documentation PageSpeed Insights explique ces cas : vérifiez toujours le périmètre avant d’interpréter une valeur.

Le laboratoire examine une page dans des conditions contrôlées. Il aide à reproduire un problème et tester une correction. Un chargement Lighthouse sans interaction ne mesure pas l’INP ; le Total Blocking Time aide au diagnostic, mais ne le remplace pas. Le guide sur les écarts entre laboratoire et terrain rappelle aussi que des déplacements peuvent apparaître plus tard dans la visite, hors du test initial.

Exemple illustratif : ne pas corriger le mauvais problème

Dans cet exemple fictif, une boutique constate un INP à améliorer sur mobile, tandis que son image principale s’affiche correctement. Réduire encore cette image n’est pas une réponse suffisante. L’équipe reproduit d’abord l’ouverture d’un filtre après chargement, puis demande d’examiner le travail exécuté au moment de cet appui.

Une correction du composant est testée dans les mêmes conditions. Le filtre doit rester utilisable et donner un retour visuel compréhensible. Aucun gain chiffré n’est supposé : les nouvelles observations et mesures servent à vérifier l’hypothèse.

Checklist avant toute correction

• Choisir des pages représentatives : catégorie, produit, panier ou demande.
• Noter appareil, URL, périmètre des données et indicateur concerné.
• Identifier l’élément LCP ou l’action associée au problème.
• Conserver un rapport initial et les étapes de reproduction.
• Formuler une hypothèse technique à vérifier avec le développeur.
• Tester une modification isolée, puis les fonctions concernées.
• Suivre ensuite les données réelles, lorsqu’elles sont disponibles.

Limites et erreurs fréquentes

Comparer des tests réalisés sur des appareils ou réglages différents peut brouiller le diagnostic. Modifier plusieurs extensions simultanément empêche d’attribuer l’effet à une cause. Enfin, ces indicateurs ne contrôlent ni l’accessibilité, ni la justesse du panier, ni la clarté des informations. Une amélioration technique doit préserver le fonctionnement du site.

Questions fréquentes

Une bonne note Lighthouse suffit-elle ?

Non. Elle décrit un test de laboratoire. Consultez les indicateurs réels disponibles et essayez les interactions importantes, plutôt que de retenir uniquement la note.

L’absence de données signifie-t-elle que le site est rapide ?

Non. Elle indique que le rapport ne dispose pas d’un échantillon suffisant. Les tests contrôlés restent utiles, sans être présentés comme des mesures de vos visiteurs.

Pourquoi les données réelles ne changent-elles pas immédiatement ?

La fenêtre de 28 jours contient encore des visites antérieures à la correction. Vérifiez d’abord le changement en laboratoire, puis observez l’évolution sans attendre un basculement immédiat.

Prochaine étape

Préparez une fiche avec une URL, un indicateur problématique et une action reproductible. Si vous sollicitez 4SYSTEM, joignez le rapport et ses conditions de mesure. Cette base permet de discuter d’une correction précise plutôt que d’une vague demande de vitesse.

Sources et ressources

• web.dev : Web Vitals et seuils.
• web.dev : définition du LCP.
• web.dev : définition de l’INP.
• web.dev : définition du CLS.
• web.dev : laboratoire et terrain.
• Google : lire PageSpeed Insights.