Core Web Vitals pour débutants : mesurer et améliorer LCP, INP et CLS

Les Core Web Vitals mesurent trois aspects d’une visite : la rapidité d’affichage du plus grand contenu visible, la réactivité aux interactions et les déplacements inattendus de la mise en page. Les métriques actuelles sont Largest Contentful Paint (LCP), Interaction to Next Paint (INP) et Cumulative Layout Shift (CLS). Examinez d’abord les résultats des utilisateurs réels, puis enregistrez une session contrôlée dans le navigateur pour identifier l’élément, l’interaction ou le déplacement responsable.

Une page peut sembler terminée et mal répondre à un appui. Elle peut aussi réagir immédiatement pendant qu’une publicité pousse vers le bas le paragraphe que vous lisez. Ces problèmes sont différents. Les traiter comme un unique score de vitesse complique inutilement l’optimisation.

La question utile ne consiste donc pas seulement à savoir si votre site est rapide. Il faut déterminer quelle partie de la visite pose problème, pour quels visiteurs et quelles observations permettraient de vérifier l’effet d’une modification.

Examinez les trois métriques avant le score global

La méthodologie des seuils Core Web Vitals de Google distingue chargement, réactivité et stabilité visuelle. Les seuils suivants s’appliquent aux mesures elles-mêmes, et non au score de performance coloré de Lighthouse.

LCP suit la plus grande image ou le plus grand contenu textuel admissible dans la zone visible pendant le chargement. Il peut s’agir d’une photo de produit, du titre d’un article ou d’un bloc de texte important. Ce n’est pas le moment où toutes les images de la page ont fini de télécharger. Un petit logo affiché rapidement ne compense pas l’arrivée tardive du contenu principal.

INP décrit le délai entre une interaction prise en compte et la mise à jour visuelle suivante. Les clics, appuis et interactions au clavier comptent ; le simple défilement ne correspond pas à cette mesure. La valeur représente généralement l’interaction la plus lente de la visite, avec un traitement des valeurs extrêmes pour les pages très sollicitées. Elle comprend l’attente du thread principal, l’exécution des gestionnaires d’événements et la préparation de l’image suivante.

CLS est un score sans unité. Il décrit les mouvements inattendus des contenus visibles en tenant compte de la surface affectée et de la distance parcourue. La métrique retient la plus grande séquence admissible de déplacements, au lieu d’additionner tous les mouvements d’une visite indéfiniment longue. Certains déplacements suivant une saisie récente sont exclus, mais toute modification déclenchée par une interaction n’est pas pour autant sans conséquence.

Ces distinctions expliquent pourquoi une seule intervention résout rarement tout. Compresser l’image principale peut accélérer le chargement sans supprimer le JavaScript coûteux d’un filtre. Réserver l’espace d’un élément intégré peut stabiliser la page sans accélérer son script.

Comprenez ce que représente le 75e centile

Les évaluations Core Web Vitals utilisent le 75e centile, généralement noté p75. Si vous classez les valeurs de la plus rapide à la plus lente, environ trois quarts des expériences mesurées se situent à cette valeur ou en dessous. Ce n’est ni la moyenne ni la mesure de votre dernière visite personnelle.

Prenez un exemple purement illustratif : la plupart des personnes voient rapidement la page, mais une minorité importante attend beaucoup plus longtemps. La moyenne peut masquer cette inégalité. Un centile permet de vérifier si une large part des visiteurs atteint l’objectif, sans faire dépendre tout le jugement de quelques cas extrêmes.

Évaluez séparément les populations mobiles et celles sur ordinateur. Une conception adaptative peut conserver la même URL tout en servant d’autres images, en présentant des commandes différentes et en fonctionnant sur un matériel distinct. Un bon résultat sur ordinateur ne prouve pas une expérience équivalente sur mobile.

Une évaluation complète des trois métriques nécessite que les valeurs p75 correspondantes respectent les trois seuils « bon ». Les mesures absentes doivent être traitées séparément. Une visite sans interaction admissible ne produit notamment aucune valeur INP. Ne remplacez pas cette absence par zéro dans un tableur : cela signifierait qu’une réponse instantanée a réellement été mesurée.

Les outils de Google ont également leurs propres règles de suffisance des données. PageSpeed Insights peut évaluer LCP et CLS lorsque les données INP sont insuffisantes. Lisez l’évaluation effectivement affichée et sa couverture, sans inventer la valeur manquante ni supposer que tous les outils utilisent les mêmes règles d’affichage.

Distinguez les données réelles d’un test contrôlé

Les données de terrain décrivent des visites enregistrées. Les données de laboratoire décrivent un test contrôlé. Les deux sont utiles, mais ne répondent pas aux mêmes questions.

Le Chrome User Experience Report, ou CrUX, agrège les expériences Chrome admissibles. Son API présente une période de collecte glissante de 28 jours. PageSpeed Insights utilise CrUX dans sa partie consacrée aux utilisateurs réels, tandis que sa partie laboratoire exécute Lighthouse dans des conditions définies. Les deux sections peuvent légitimement donner des résultats différents.

Un test de laboratoire peut charger l’accueil sans choix de consentement, sans connexion à un compte et sans interaction. Vos visiteurs peuvent fermer un bandeau, ouvrir le menu, filtrer des produits, faire défiler la page jusqu’à une vidéo intégrée et revenir sur une page en cache. Ces parcours activent des traitements qu’un test limité au chargement n’exerce jamais.

L’inverse est également possible. Un laboratoire aux ressources limitées peut produire un résultat moins bon que celui vécu par une grande partie du public. Cela invite à examiner les conditions du test, pas à écarter le résultat. Celui-ci peut révéler un véritable obstacle sur du matériel ou des connexions plus lents.

CrUX ne représente pas non plus chaque navigateur ni chaque visiteur. Les pages doivent disposer d’un trafic admissible suffisant et remplir les critères d’inclusion. Un rapport absent indique une indisponibilité des données, pas une page rapide ou lente. Google ne publie aucun nombre universel de visiteurs garantissant l’inclusion.

Consultez notre guide des données de terrain et de laboratoire lorsque les rapports divergent. Avant de comparer des valeurs, notez l’URL, la catégorie d’appareil, la période et le périmètre : URL individuelle ou origine entière.

Choisissez le rapport adapté à votre question

PageSpeed Insights constitue un point de départ utile pour une URL publique. Examinez d’abord la section des utilisateurs réels lorsqu’elle existe. Vérifiez si elle décrit la page demandée ou utilise l’origine. Une origine regroupe les pages partageant protocole, nom d’hôte et port ; elle ne diagnostique pas individuellement chaque modèle de page.

Passez ensuite au laboratoire. Ses diagnostics et indications proposent des causes à examiner. Il ne s’agit pas d’une liste de pénalités indépendantes sur le score. N’additionnez pas les économies estimées comme une amélioration promise : plusieurs recommandations peuvent viser le même délai sous-jacent.

Search Console aide à trouver des groupes d’URL présentant des problèmes d’expérience similaires. C’est particulièrement utile lorsqu’un modèle commun affecte de nombreux articles ou produits. Ouvrez des URL représentatives et examinez leur implémentation partagée, sans supposer que modifier un seul exemple corrige tout le groupe.

Chrome DevTools permet d’étudier la séquence réelle. Enregistrez le chargement pour LCP et les interactions pour la réactivité. Observez les événements de déplacement pendant la reproduction des contenus tardifs, bandeaux ou éléments intégrés. Conservez les conditions d’enregistrement avec vos notes pour qu’une autre personne puisse reproduire le constat.

Votre propre suivi des utilisateurs réels, souvent appelé RUM, apporte des détails absents des rapports agrégés. Il peut relier une régression à un déploiement ou à un modèle, selon la couverture et les choix de confidentialité de l’implémentation. Ne présumez pas d’une correspondance exacte avec CrUX : les populations, API du navigateur et détails de mesure peuvent différer.

Diagnostiquez un LCP lent en suivant la ressource

Identifiez d’abord l’élément LCP dans l’enregistrement, à la taille de fenêtre pertinente. Une grande image sur ordinateur peut devenir une petite image ou un bloc de texte sur mobile. La ressource optimisée doit réellement déterminer la métrique.

Pour un LCP fondé sur une image, examinez quatre étapes : l’attente du premier octet HTML, le délai avant la requête d’image, son téléchargement et l’intervalle entre la fin du transfert et l’affichage. Un petit fichier peut arriver tard si JavaScript n’insère son URL qu’après l’initialisation de l’application.

Les premières vérifications sont concrètes. L’image est-elle découvrable dans le HTML initial ? Est-elle chargée paresseusement à tort ? Sa configuration adaptative sélectionne-t-elle un fichier trop volumineux ? Une feuille de style ou un script empêche-t-il son affichage après réception ?

Ce balisage illustratif donne des dimensions et une priorité de récupération élevée à une image importante. Les fichiers indiqués doivent exister dans votre projet.

<img
  src="/images/article-hero-960.webp"
  srcset="/images/article-hero-960.webp 960w,
          /images/article-hero-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A request moving from a browser to a server"
>

L’absence de loading="lazy" est volontaire. fetchpriority est une indication de planification, pas une instruction annulant toutes les décisions du navigateur. Réservez-la aux ressources réellement importantes, au lieu de donner la priorité haute à toute une galerie.

Si le HTML arrive lui-même tard, l’optimisation des images ne supprime pas l’attente précédant la découverte de la page. Examinez le temps de réponse du serveur et le TTFB, notamment les redirections, absences en cache et traitements applicatifs. Si l’image arrive rapidement mais reste invisible, examinez plutôt le rendu et le thread principal.

Diagnostiquez un mauvais INP avec une interaction réelle

Choisissez une action précise : ouvrir le menu, sélectionner une variante de produit, lancer une recherche ou développer une longue section. Enregistrez-la après le chargement, avec les scripts habituels actifs en arrière-plan. Un enregistrement sans interaction n’explique pas la lenteur d’une interaction réelle.

Le délai peut survenir avant votre gestionnaire, lorsqu’un autre script occupe le thread principal. Il peut se produire dans le gestionnaire, par exemple si un filtre recalcule une grande collection. Il peut aussi apparaître ensuite, lorsque le navigateur doit calculer les styles, la disposition et l’affichage d’une mise à jour importante.

Traitez ces phases séparément. Supprimer un rappel d’analyse redondant ne corrige pas une opération de mise en page coûteuse. Raccourcir un gestionnaire ne supprime pas la tâche qui bloque son démarrage. Votre trace doit identifier la phase dominante avant le choix du correctif.

Réduisez d’abord les traitements inutiles. Découpez ensuite ceux qui n’ont pas besoin de se terminer avant le retour visuel. Céder la main entre les fragments donne au navigateur l’occasion d’autres traitements. Les calculs adaptés qui n’utilisent pas le DOM peuvent être déplacés vers un worker. Aucune de ces techniques ne justifie de retraiter inutilement les mêmes données.

Un test classique de navigation Lighthouse utilise Total Blocking Time comme indicateur de laboratoire du blocage du thread principal. TBT n’est pas INP et ne doit pas être saisi dans le champ INP d’un vérificateur. Des enregistrements interactifs contrôlés peuvent mesurer la latence d’interaction : la limite concerne le test de chargement seul, pas tout le laboratoire.

Diagnostiquez CLS en recherchant la cause du déplacement

L’élément déplacé peut subir le problème plutôt que le provoquer. Si un paragraphe descend, regardez ce qui est apparu au-dessus. Un nouveau bandeau ou une image sans dimensions réservées peut avoir modifié l’espace disponible.

Commencez par les images et vidéos. Leurs dimensions ou un rapport d’aspect approprié permettent de réserver la place avant leur arrivée. Examinez ensuite publicités, lecteurs intégrés, recommandations et autres contenus asynchrones. Un espace réservé doit avoir une taille réaliste à chaque point de rupture, et pas seulement une animation décorative.

Les polices méritent aussi votre attention. La police de remplacement et la police web téléchargée peuvent avoir des largeurs de caractères et métriques verticales différentes. Le changement peut modifier les retours à la ligne et déplacer les contenus voisins. Choisissez un comportement de chargement adapté et envisagez d’aligner les métriques de remplacement. Afficher le texte immédiatement n’élimine pas tout risque.

Ne corrigez pas un déplacement en rendant la page inaccessible. Les éléments fixes superposés peuvent masquer du contenu ou des commandes, surtout avec une fenêtre étroite ou du texte agrandi. Après modification d’un bandeau ou d’un emplacement, testez le clavier, le zoom et la place restante pour la tâche principale.

Un enregistrement limité au rechargement peut manquer les déplacements ultérieurs. Laissez-le tourner pendant le défilement, l’ouverture des commandes concernées et l’arrivée du contenu tardif. Comparez les mouvements observés au problème de terrain avant de considérer le correctif terminé.

Construisez une routine de mesure simple et reproductible

Choisissez des pages représentatives plutôt que le seul accueil. Incluez un article, une catégorie, une fiche produit ou un autre modèle important. Notez leurs composants communs : navigation, polices, espaces publicitaires et contrôles de consentement.

Conservez une référence pour chaque catégorie d’appareil pertinente. Enregistrez le rapport, la date, la version testée et les principales mesures. Répétez les tests comparables dans les mêmes conditions. Un résultat isolé favorable ne distingue pas une amélioration d’une variation normale.

Pour un projet intégrant déjà le paquet web-vitals, ce petit module de diagnostic journalise les métriques signalées par le navigateur. Il s’agit d’un exemple de débogage local, pas d’un système d’analyse complet.

import { onCLS, onINP, onLCP } from 'web-vitals';

function logMetric(metric) {
  console.log({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id
  });
}

onLCP(logMetric);
onINP(logMetric);
onCLS(logMetric);

Certains rappels dépendent du cycle de vie de la page ou des interactions effectuées. N’attendez pas trois valeurs significatives dès l’ouverture d’un onglet inactif. Une collecte en production nécessite un point de réception, une agrégation, des choix d’échantillonnage et des contrôles de confidentialité appropriés. La console ne fournit aucun de ces éléments.

Après le déploiement, surveillez les régressions et laissez la fenêtre de collecte intégrer les nouvelles visites. Une fenêtre glissante contient des expériences antérieures et ultérieures jusqu’à ce qu’un délai suffisant se soit écoulé. Répéter Lighthouse n’accélère pas ce processus et ne crée pas le trafic CrUX manquant.

Replacez Core Web Vitals dans le contexte du référencement

Google Search Central indique que ses systèmes de classement utilisent Core Web Vitals, tout en précisant que de bons rapports ne garantissent pas de bonnes positions. La pertinence, l’utilité du contenu et d’autres dimensions de l’expérience restent importantes. Aucune conversion documentée ne relie une hausse du score Lighthouse à un gain de positions.

Cela rend les priorités plus concrètes. Si les visiteurs ne peuvent pas utiliser un filtre, corrigez-le parce qu’il bloque leur tâche. Si une image importante arrive tard dans un modèle très utilisé, traitez la cause commune. Évitez de consacrer tout le budget à un point synthétique supplémentaire alors que le contenu essentiel reste difficile à trouver ou à utiliser.

Transformez le premier constat en modification précise

Choisissez une URL représentative et une métrique problématique. Notez la cause observée, le changement proposé et les preuves à comparer ensuite. Vous obtenez ainsi une tâche délimitée qu’un développeur peut réaliser et qu’une autre personne peut évaluer.

Utilisez le vérificateur Core Web Vitals pour classer les valeurs mesurées, en conservant leurs sources et unités. Suivez l’implémentation avec la liste de contrôle des performances. Les autres guides Core Web Vitals indiquent la prochaine piste lorsque vous connaissez la partie de la visite à améliorer.