Core Web Vitals en 2026 : diagnostiquer LCP, INP et CLS avec des données réelles

Réponse directe

Les Core Web Vitals actuels sont le Largest Contentful Paint, l'Interaction to Next Paint et le Cumulative Layout Shift. Une bonne expérience au 75e centile correspond à un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes, et un CLS inférieur ou égal à 0,1, évalués séparément pour le mobile et le desktop.

Utilisez des données de terrain comme le Chrome UX Report ou votre propre suivi des utilisateurs réels pour déterminer si vos visiteurs réels rencontrent un problème. Utilisez Lighthouse et les traces de performance pour expliquer un problème reproductible dans un environnement contrôlé. Un score Lighthouse de 100 ne prouve pas que la cohorte mobile de terrain est conforme, et une cohorte CrUX en échec ne vous dit pas quelle ligne de code en est la cause.

Corrigez le composant de métrique réellement lent, protégez le résultat avec un budget anti-régression, et ne promettez jamais que réussir les Core Web Vitals produira une hausse de classement ou de revenu.

Ce que vous saurez faire

À la fin de cette leçon, vous serez capable de :

• définir LCP, INP et CLS en termes d'expérience utilisateur ;
• classer les seuils bon, à améliorer et médiocre ;
• distinguer données de terrain, données de laboratoire, données au niveau page et au niveau origine ;
• décomposer le LCP et l'INP en composants diagnostiques ;
• prioriser le premier correctif pour une cohorte en échec ;
• définir un budget de performance et une méthode de vérification sans courir après un score de vanité.

Les trois Core Web Vitals

Les recommandations Web Vitals de Google identifient trois Core Web Vitals stables.

Largest Contentful Paint, ou LCP

Le LCP mesure la performance de chargement via le temps de rendu du plus grand élément de contenu visible qualifié dans la fenêtre d'affichage.

La question de l'utilisateur est :

Quand ai-je l'impression que le contenu principal visible est chargé ?

Bon : inférieur ou égal à 2,5 secondes. À améliorer : supérieur à 2,5 et inférieur ou égal à 4,0 secondes. Médiocre : supérieur à 4,0 secondes.

Interaction to Next Paint, ou INP

L'INP mesure la réactivité en observant la latence des interactions utilisateur et en rapportant une interaction représentative à latence élevée pour la visite de la page.

La question de l'utilisateur est :

Après avoir cliqué, tapoté ou saisi du texte, combien de temps avant que la page réponde visiblement ?

Bon : inférieur ou égal à 200 millisecondes. À améliorer : supérieur à 200 et inférieur ou égal à 500 millisecondes. Médiocre : supérieur à 500 millisecondes.

Sur les pages très interactives, l'INP ignore généralement une interaction sur 50, la plus mauvaise, pour réduire l'effet des valeurs aberrantes rares. Lisez la définition officielle actuelle dans le guide INP de web.dev.

Cumulative Layout Shift, ou CLS

Le CLS mesure l'instabilité visuelle inattendue à l'aide de scores de décalage de mise en page regroupés en fenêtres de session.

La question de l'utilisateur est :

Le contenu a-t-il bougé de façon inattendue pendant que j'essayais de lire ou d'agir ?

Bon : inférieur ou égal à 0,1. À améliorer : supérieur à 0,1 et inférieur ou égal à 0,25. Médiocre : supérieur à 0,25.

Les changements attendus initiés par l'utilisateur sont traités différemment des décalages inattendus. Réservez de l'espace et gérez le contenu dynamique plutôt que de masquer tout mouvement.

Tableau des seuils et du diagnostic

Les seuils sont des repères d'expérience. Ce ne sont pas des promesses de classement ou de conversion.

Pourquoi le 75e centile compte

Une moyenne peut masquer la cohorte d'utilisateurs la plus lente qui compte réellement. Google recommande d'évaluer le 75e centile des chargements de page, segmenté par mobile et desktop.

Si 75 % des visites mesurées ont un LCP inférieur ou égal à 2,5 secondes, le LCP p75 atteint le seuil bon. Si la moyenne est de 2,0 secondes mais que le p75 est de 3,1 secondes, un groupe important vit tout de même une expérience plus lente.

Segmentez davantage lorsque vous le pouvez :

• pays ou région ;
• connexion effective ;
• capacité de l'appareil ;
• gabarit de page (template) ;
• état de connexion (connecté ou non) ;
• version de mise en production.

Ne découpez pas si agressivement que l'échantillon devienne instable ou sensible du point de vue de la confidentialité.

Données de terrain versus données de laboratoire

Données de terrain

Les données de terrain proviennent de visites d'utilisateurs réels et éligibles, avec de vrais appareils, réseaux, caches, extensions et comportements.

Exemples :

• Chrome UX Report, ou CrUX ;
• la section de terrain de PageSpeed Insights ;
• les groupes Core Web Vitals de Search Console ;
• votre propre suivi des utilisateurs réels.

La documentation de l'API CrUX indique que ses enregistrements utilisent une période de collecte glissante de 28 jours et sont mis à jour quotidiennement. Les données sont agrégées pour les pages ou origines éligibles.

Limites :

• toutes les pages ne disposent pas de suffisamment de données éligibles ;
• le repli sur l'origine peut masquer les différences entre pages ;
• les utilisateurs de Chrome ne représentent pas tous les utilisateurs ;
• la fenêtre réagit lentement à une mise en production ;
• les données de terrain identifient l'expérience affectée, pas la cause exacte dans le code.

Données de laboratoire

Les données de laboratoire font tourner une page dans un environnement contrôlé.

Exemples :

• Lighthouse ;
• le panneau Performance de Chrome DevTools ;
• WebPageTest ;
• des traces d'interaction locales.

Avantages :

• conditions reproductibles ;
• preuves détaillées de waterfall et de thread principal ;
• débogage rapide avant la mise en production.

Limites :

• un seul profil d'appareil et de réseau ;
• navigation synthétique ;
• couverture limitée des interactions réelles ;
• le cache et la localisation diffèrent du terrain ;
• l'INP peut être indisponible sans interactions.

Pourquoi Lighthouse et CrUX ne sont pas d'accord

Ils répondent à des questions différentes.

Lighthouse demande :

Que s'est-il passé lors de cette exécution contrôlée ?

CrUX demande :

Qu'ont vécu les utilisateurs Chrome réels éligibles sur la fenêtre de terrain glissante ?

Une page Astro statique peut obtenir 100 dans un laboratoire desktop et avoir malgré tout un INP mobile de terrain médiocre si les utilisateurs réels ouvrent un gestionnaire de consentement lourd, interagissent avec un calculateur, ou utilisent des appareils plus lents.

Données au niveau page versus au niveau origine

CrUX peut rapporter une URL spécifique lorsque suffisamment de données existent. Sinon, les outils peuvent afficher des données au niveau de l'origine.

Les données au niveau de l'origine combinent différents gabarits et parcours. Une page de documentation rapide peut masquer un tunnel de paiement lent. Une application lente peut faire paraître coupable une page éditoriale.

Indiquez toujours :

• page ou origine ;
• mobile ou desktop ;
• terrain ou laboratoire ;
• fenêtre de dates ;
• p75 ou un autre centile ;
• éligibilité de l'échantillon.

Diagnostiquer le LCP par composants

Traitez le LCP comme une chaîne.

délai avant premier octet
  + délai de découverte de la ressource
  + durée de chargement de la ressource
  + délai de rendu de l'élément
  = LCP observé

Délai avant premier octet (time to first byte)

La réponse du document est lente.

À investiguer :

• travail serveur ;
• absence de cache ;
• redirection ;
• géographie ;
• dépendance backend ;
• démarrage à froid.

Délai de découverte de la ressource

Le navigateur découvre tardivement la ressource du LCP.

À investiguer :

• images de fond CSS ;
• images injectées côté client ;
• préchargement (preload) manquant pour une ressource véritablement critique ;
• styles ou scripts bloquants ;
• chargement différé appliqué à l'image LCP au-dessus de la ligne de flottaison.

Durée de chargement de la ressource

La ressource met trop de temps à être transférée.

À investiguer :

• image surdimensionnée ;
• mauvais format ou mauvaises dimensions ;
• CDN lent ;
• compression ;
• requêtes concurrentes.

Délai de rendu de l'élément

La ressource est prête mais ne peut pas s'afficher.

À investiguer :

• CSS bloquant le rendu ;
• travail sur le thread principal ;
• élément caché ;
• hydratation ;
• état de la police ;
• délai d'animation.

N'optimisez pas le serveur si le délai réel du LCP provient d'une image rendue côté client et découverte tardivement.

Diagnostiquer l'INP par phases

Chaque interaction lente peut être décomposée en :

délai d'entrée
  + traitement du gestionnaire d'événement
  + délai de présentation
  = latence d'interaction

Délai d'entrée

L'interaction attend parce que le thread principal est occupé.

Causes typiques :

• tâches de script longues ;
• code tiers ;
• hydratation ;
• analyse d'une charge utile volumineuse ;
• stockage synchrone.

Durée de traitement

Les gestionnaires d'événements eux-mêmes sont coûteux.

Causes typiques :

• filtrage synchrone de milliers de lignes ;
• lectures et écritures répétées de la mise en page ;
• mise à jour d'état volumineuse ;
• validation lourde ;
• travail inutile à chaque frappe de touche.

Délai de présentation

Le travail du gestionnaire se termine, mais la frame suivante est retardée.

Causes typiques :

• style et mise en page coûteux ;
• rendu d'un arbre de composants énorme ;
• tâches synchrones subséquentes ;
• peinture complexe.

Découpez les tâches longues, réduisez le travail, cédez la main au navigateur lorsque c'est pertinent, et n'affichez que ce dont l'utilisateur a besoin. Ne supprimez pas de fonctionnalité utile dans le seul but d'améliorer un score.

Diagnostiquer le CLS

Utilisez la piste des décalages de mise en page pour identifier l'élément qui bouge et ce qui l'a provoqué.

Causes fréquentes :

• images ou intégrations sans dimensions ;
• bannière de cookies insérée au-dessus du contenu ;
• emplacement publicitaire sans espace réservé ;
• changement tardif de police web ;
• accordéon ou alerte inséré de façon inattendue ;
• hydratation côté client remplaçant le balisage serveur par une taille différente.

Réservez de l'espace, utilisez des espaces réservés stables, coordonnez les polices, et insérez l'interface dynamique dans des zones prévisibles.

Une procédure CWV reproductible

1. Confirmez le problème de terrain

Notez la métrique, le seuil, le centile, l'appareil, la page ou l'origine, la fenêtre de dates et le groupe de gabarit affecté.

2. Vérifiez l'éligibilité des données

Ne qualifiez pas une nouvelle page de « conforme CrUX » si elle n'a aucun enregistrement de terrain au niveau de la page.

3. Reproduisez un cas représentatif

Utilisez un profil mobile approprié, une localisation, un état à froid ou à chaud, et une interaction réelle. Une seule exécution desktop optimale n'est pas représentative.

4. Décomposez la métrique

Pour le LCP, identifiez l'élément et les quatre composants temporels. Pour l'INP, identifiez l'interaction réelle et les trois phases. Pour le CLS, identifiez le groupe de décalages et son déclencheur.

5. Classez les causes racines

Choisissez la cause qui explique le délai observé le plus important et qui peut être corrigée sans casser la tâche.

6. Ajoutez des budgets avant la mise en production

Exemples :

• JavaScript maximal par route ;
• durée maximale des tâches longues ;
• poids maximal de l'image LCP en octets ;
• dimensions de mise en page réservées ;
• seuil d'alerte RUM au p75.

7. Validez en laboratoire

Confirmez que le composant ciblé s'est amélioré et qu'aucune régression d'accessibilité ou de fonctionnalité n'est apparue.

8. Publiez en toute sécurité

Utilisez un déploiement par cohorte ou progressif lorsque le risque le justifie. Annotez la mise en production.

9. Vérifiez dans les données de terrain

Utilisez le RUM pour un retour directionnel plus rapide et attendez la fenêtre glissante CrUX pertinente. Comparez la même cohorte et les mêmes définitions.

Exemple travaillé : le desktop réussit, l'INP mobile échoue

Un gabarit de leçon présente :

• interaction de type INP en laboratoire desktop : 90 ms ;
• interaction en laboratoire mobile : 260 ms ;
• INP p75 mobile de terrain : 420 ms ;
• INP p75 desktop de terrain : 150 ms.

L'équipe souhaite mettre à niveau le serveur.

Tracer l'interaction

Sur mobile, l'ouverture du filtre de tableau produit :

• délai d'entrée : 170 ms ;
• traitement du gestionnaire : 110 ms ;
• délai de présentation : 140 ms ;
• total : 420 ms.

Le principal délai d'entrée provient d'une tâche d'analytics et d'hydratation de 190 ms déjà en cours lorsque l'utilisateur tapote. Le gestionnaire filtre ensuite et rend l'intégralité du tableau synthétique de 4 000 lignes.

Correctif priorisé

1. différer l'initialisation des analytics non essentiels ;
2. découper le travail d'hydratation en tâches plus petites ;
3. déplacer le filtrage vers une structure de données efficace ou un worker lorsque cela se justifie ;
4. rendre un ensemble de résultats visibles virtualisé ;
5. préserver l'accès clavier et lecteur d'écran au tableau ;
6. ajouter un budget pour les tâches longues et l'interaction mobile.

Mettre à niveau le serveur pourrait améliorer la réponse initiale du document, mais cela ne traite pas les phases d'interaction mesurées.

Vérification

La trace de laboratoire tombe à 160 ms sur le profil mobile représentatif. Le RUM de la cohorte mise en production affiche une tendance à la baisse. Le p75 CrUX est examiné après que la fenêtre de terrain glissante a accumulé suffisamment d'exposition post-publication.

Pourquoi cela peut échouer

Si le nouveau tableau virtualisé supprime des relations sémantiques ou l'accès clavier, la performance s'est améliorée pendant que le produit régressait. Les garde-fous doivent inclure l'achèvement de la tâche et l'accessibilité.

Core Web Vitals et Google Search

La documentation Google sur les Core Web Vitals et les résultats de recherche explique que les Core Web Vitals sont utilisés par les systèmes de classement dans le cadre de l'expérience de page.

Ne surestimez pas ce fait :

• de bons CWV ne garantissent pas les meilleurs classements ;
• des CWV médiocres ne rendent pas à eux seuls un contenu pertinent invisible ;
• la pertinence et l'utilité restent essentielles ;
• un correctif de performance peut améliorer l'expérience des utilisateurs sans créer de changement de classement mesurable.

Priorisez les défaillances d'utilisabilité catastrophiques, l'indexabilité, la sécurité et l'achèvement de la tâche avant de courir après un score de laboratoire parfait.

Planificateur de budget de performance SEOryon

Téléchargez le planificateur de seuils CWV et de budget de performance.

Pour chaque gabarit, consignez :

• l'appareil ;
• si les données de terrain au niveau de la page sont éligibles ;
• le p75 du LCP, de l'INP et du CLS ;
• le statut actuel ;
• le premier diagnostic ;
• le budget de mise en production ;
• le responsable et la date de revue.

Les lignes incluses sont des exemples synthétiques. Remplacez-les par de vrais agrégats validés. N'incluez jamais de données de navigation personnelles ou propres à un client (tenant).

Exercice : prioriser quatre gabarits

Pour chacun, choisissez la première intervention et la méthode de vérification.

Corrigé

• Academy : corriger la découverte tardive de la ressource LCP, vérifier via une trace de laboratoire représentative, puis la cohorte de terrain mobile.
• Calculateur : instrumenter des interactions réelles et recueillir du RUM avant de déclarer l'INP bon ou mauvais.
• Comparateur : prioriser la tâche longue mesurée et les phases d'interaction, puis vérifier l'achèvement de la tâche et le p75 mobile.
• Tarifs : ne pas supposer que la page est conforme à partir de données au niveau origine. Ajouter du RUM au niveau page et examiner des preuves de laboratoire représentatives.

Pénalisez toute réponse qui choisit uniquement en fonction du score Lighthouse le plus élevé ou qui traite l'absence de données comme un bon signe.

Erreurs fréquentes

Utiliser le FID comme Core Web Vital actuel

L'INP a remplacé le FID comme Core Web Vital de réactivité.

Optimiser des moyennes

Utilisez le p75 et des cohortes significatives.

Confondre Lighthouse et CrUX

L'un est une exécution contrôlée. L'autre est une expérience de terrain agrégée.

Courir après le 100 avant de corriger un contenu cassé

La performance soutient la tâche. Elle ne la remplace pas.

Améliorer le temps serveur pour un problème d'interaction

Décomposez d'abord les phases réelles de l'INP.

Affirmer une causalité sur le revenu à partir d'un seul avant-après

Performance et revenu peuvent évoluer ensemble pour de nombreuses raisons. Utilisez une expérimentation appropriée et préservez l'incertitude.

Checklist finale

• La métrique concernée est le LCP, l'INP ou le CLS selon la définition actuelle.
• Les seuils bon, à améliorer et médiocre sont corrects.
• Les données sont étiquetées terrain ou laboratoire.
• La portée page versus origine est visible.
• Mobile et desktop sont traités séparément.
• Le centile et la fenêtre de dates sont consignés.
• L'éligibilité des données de terrain est vérifiée.
• Le LCP est décomposé en réponse, découverte, chargement et délai de rendu.
• L'INP est décomposé en délai d'entrée, traitement et délai de présentation.
• Les décalages du CLS ont un déclencheur visible.
• Le premier correctif traite la cause racine mesurée.
• La fonctionnalité et l'accessibilité sont des garde-fous.
• Un budget anti-régression existe.
• Les annotations de mise en production et le suivi RUM sont configurés.
• Les résultats de classement et de revenu ne sont pas garantis.

Questions fréquentes

Pourquoi Lighthouse est-il vert alors que Search Console échoue ?

Lighthouse est un seul test contrôlé. Search Console utilise les données de terrain CrUX sur des utilisateurs réels éligibles et une fenêtre glissante. L'appareil, le réseau, l'interaction, la route et la période peuvent différer.

À quelle vitesse CrUX montrera-t-il mon correctif ?

CrUX utilise une période de collecte glissante de 28 jours mise à jour quotidiennement. Les changements directionnels peuvent apparaître progressivement. Votre propre RUM peut fournir une preuve plus rapide.

Réussir les Core Web Vitals améliore-t-il le classement ?

Les Core Web Vitals contribuent à l'expérience de page, mais les réussir ne garantit pas de gains de classement. Corrigez-les pour les utilisateurs et mesurez les résultats de recherche séparément.

Quel est le meilleur outil pour l'INP ?

Utilisez les données de terrain pour identifier les cohortes affectées et le RUM pour capturer les interactions réelles. Utilisez les traces de performance Chrome pour diagnostiquer l'interaction lente spécifique et ses phases.

Faut-il supprimer du JavaScript pour améliorer l'INP ?

Supprimez le travail inutile, pas la fonctionnalité utile par défaut. Découpez les tâches longues, réduisez le coût des gestionnaires et du rendu, et préservez l'accessibilité.

Sources et méthodologie

Les recherches communautaires ont fait ressortir deux questions récurrentes : pourquoi CrUX peut être pire qu'un score Lighthouse de 90 à 100, et quel outil peut révéler les problèmes d'INP. Ces questions ont façonné la distinction, formulée en réponse directe, entre les données de décision de terrain et le diagnostic de laboratoire. Les affirmations communautaires n'ont pas été utilisées comme preuve.

1. web.dev, Web Vitals, mis à jour le 31 octobre 2024 et vérifié le 28 juillet 2026. Définitions officielles des métriques, seuils et recommandations sur le p75.
2. web.dev, Interaction to Next Paint, mis à jour le 2 septembre 2025 et vérifié le 28 juillet 2026. Définition officielle de l'INP, seuils et modèle d'interaction.
3. Chrome for Developers, API CrUX, mis à jour le 11 février 2025 et vérifié le 28 juillet 2026. Modèle officiel de données utilisateur réelles agrégées sur 28 jours.
4. Google Search Central, Core Web Vitals et la recherche Google, mis à jour le 10 décembre 2025 et vérifié le 28 juillet 2026. Contexte officiel sur la pertinence de recherche et l'expérience de page.

Précédent : SEO JavaScript et interfaces lisibles par les agents Suite : /academy/structured-data-schema/ est la route prévue pour l'étape 11 et doit rester non publiée tant que la leçon complète n'existe pas.