Ressources · 39
Diagnostiquer les Core Web Vitals observés sur le terrain
Relier LCP, INP et CLS à des éléments et interactions réels avant de corriger.
· 8 min
Ce que ce guide permet
- Choisir les bons segments
- Localiser l’élément ou l’action
- Reproduire
- Vérifier le changement
Contrôle express
- Le signal vient-il du terrain ou du laboratoire ?
- Quels appareils et pages composent la mesure ?
- Quel élément est le LCP ?
- Quelle action contribue à l’INP ?
- Quels ajouts déplacent la page ?
Méthode pas à pas
- 01
Définir la population
Séparer page, modèle, appareil, période et type de parcours avant de comparer. Noter la couverture et les changements de trafic ou de contenu.
Livrable : périmètre de mesure et limites.
- 02
Identifier le symptôme dominant
Lire LCP, INP et CLS comme trois expériences différentes. Observer leur distribution plutôt qu’une seule moyenne globale.
Livrable : liste priorisée des segments affectés.
- 03
Relier au contenu réel
Pour LCP, relever l’élément et les délais réseau ou rendu. Pour CLS, relever les déplacements. Pour INP, retrouver les interactions et le travail du fil principal.
Livrable : éléments et actions avec traces.
- 04
Reproduire en laboratoire
Construire un scénario proche des conditions du segment touché. Utiliser les outils de développement pour tester une hypothèse, sans confondre ce résultat avec le terrain.
Livrable : reproduction et cause probable.
- 05
Corriger la cause
Prioriser les ressources, réserver les dimensions ou réduire le travail bloquant selon la preuve. Tester aussi les régressions fonctionnelles et l’accessibilité.
Livrable : changement ciblé et comparaison locale.
- 06
Suivre après publication
Comparer les mêmes pages, appareils et périodes appropriées. Documenter les limites d’échantillon et les changements de population.
Livrable : suivi terrain et décision suivante.
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| LCP | Affichage de l’élément principal sur parcours réel | Examiner chargement et rendu |
| INP | Réponse aux interactions réelles | Réduire le travail bloquant |
| CLS | Stabilité de la mise en page | Réserver les espaces |
| Couverture | Segments avec assez de données interprétables | Compléter la mesure |
Erreurs fréquentes
- Déduire l’expérience réelle d’un seul score Lighthouse
- Mélanger mobile et ordinateur
- Optimiser une moyenne sans localiser l’élément
- Attribuer un gain à un correctif malgré un changement de trafic
Questions fréquentes
Pourquoi le laboratoire diffère-t-il du terrain ?
Réseau, appareil, cache, contenu et comportements réels peuvent différer du scénario de test.
Un bon LCP garantit-il un bon INP ?
Non. Chargement et réactivité des interactions mesurent des moments différents.
Quand conclure qu’un correctif fonctionne ?
Après une comparaison suffisante sur des segments équivalents, en tenant compte du volume et des autres changements.
Références : données, usages et limites
Documentation consultée le .
| Source et objet | Donnée ou repère vérifié | Comment l’utiliser | Limite à conserver |
|---|---|---|---|
| Google · Core Web Vitals Distinguer vitesse d’affichage, réactivité et stabilité visuelle. |
Les repères « bon » sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1, au 75e percentile, avec segmentation mobile et ordinateur. | Séparez mesures de terrain et tests de laboratoire. Relevez période, URL, appareil, population et taille d’échantillon avant de comparer une évolution. | Ces seuils ne sont pas des résultats mesurés de ce site. Un bon score de laboratoire ne prouve pas à lui seul l’expérience des visiteurs. |
Core Web Vitals : seuils et données terrain
Un bon diagnostic Core Web Vitals commence par une mesure dont on connaît le périmètre. Identifier la page ou l’origine, l’appareil, la période et la source avant de discuter du correctif. Une page peut charger vite dans un essai local et rester difficile à utiliser pour une partie du public. Le dossier ci-dessous aide à lire les valeurs sans confondre résultat terrain, trace de laboratoire et promesse SEO.
Sources Google consultées le 23 octobre 2026. Les seuils sont ceux de PageSpeed Insights ; les exemples sont des données fictives CIE, jamais des mesures de ce site. Les contrôles proposés sont une méthode de recette, pas une garantie de positionnement.
Google · About PageSpeed Insights · Living documentation · consulted 2026-10-23
Trois métriques, des seuils et des unités explicites
| Métrique | Bon | À améliorer | Mauvais | Lecture et unité |
|---|---|---|---|---|
| LCP | ≤ 2500 ms | > 2500 ms · ≤ 4000 ms | > 4000 ms | Chargement : apparition du plus grand élément de contenu éligible. Relier le signal à l’élément réellement observé avant d’accuser toutes les images. |
| INP | ≤ 200 ms | > 200 ms · ≤ 500 ms | > 500 ms | Réactivité aux interactions. Une trace d’action aide à séparer attente avant traitement, exécution et présentation ; un score de chargement ne remplace pas cette enquête. |
| CLS | ≤ 0.1 | > 0.1 · ≤ 0.25 | > 0.25 | Stabilité visuelle : score sans unité. Rechercher ce qui déplace les éléments, puis réserver l’espace ou corriger l’insertion ; ne pas convertir ce score en millisecondes. |
Huit points de lecture à conserver avec la mesure
| Point | Ce qu’il faut garder | Conséquence pour la décision |
|---|---|---|
| p75 | La valeur du 75e percentile, pour chaque métrique. | Ce percentile ne décrit ni la moyenne ni la visite la plus lente. Ne pas moyenner les p75 de deux populations pour inventer celui de leur réunion. |
| Appareil | La dimension PHONE, DESKTOP ou TABLET, ou son absence. | Une dimension absente dans une requête CrUX API agrège les appareils. Comparer le même appareil avant et après une correction. |
| URL ou origine | L’identifiant effectivement retourné par la source. | PSI peut afficher l’origine quand l’URL manque de données ; ne pas attribuer ce résultat à la seule fiche ouverte. |
| Période | Les dates de collecte du résultat consulté. | L’API CrUX agrège les 28 jours précédents et se met à jour quotidiennement. Deux dates voisines ne représentent pas deux cohortes indépendantes. |
| INP absent | L’absence de mesure et le message associé. | PSI autorise son exception si LCP et CLS sont bons. Elle ne permet pas de déclarer les interactions rapides. |
| Couverture | Les limites d’éligibilité et de population de CrUX. | Un seuil de fréquentation existe mais sa valeur exacte n’est pas publiée. Ne pas inventer un minimum de visites pour rendre un rapport disponible. |
| Histogramme | Les parts par tranche et le p75 retourné, séparément. | Le p75 CrUX est dérivé des données disponibles, pas des seules trois tranches affichées ; ne pas le reconstruire exactement à partir de ces tranches. |
| Contrat de mesure | La distinction entre valeurs saisies, données source et diagnostic. | Ce lecteur local classe les valeurs fournies. Il n’exécute ni Lighthouse ni CrUX et n’observe aucun visiteur. |
Chrome for Developers · CrUX API · Living documentation · consulted 2026-10-23
Chrome for Developers · CrUX methodology · Living documentation · consulted 2026-10-23
Lecteur local de valeurs p75
Saisir les p75 d’un même appareil, d’une même période et d’un même périmètre. LCP et INP sont en millisecondes ; CLS est sans unité. Un champ vide signifie « donnée indisponible », jamais zéro. Le point ou la virgule décimale est admis, avec au plus quatre décimales et sans séparateur de milliers. Les plafonds de saisie — 600000 ms et CLS 1000 — appartiennent à cet outil ; ce ne sont pas des limites officielles de ces métriques. Les fractions fines des exemples servent à tester les limites du lecteur ; elles ne reproduisent pas la précision de sortie du rapport CrUX.
Lecture locale selon les seuils et l’exception INP de PageSpeed Insights. Aucun test du site, appel distant, historique enregistré, calcul de percentile ou conversion secondes/millisecondes. Le lecteur ne vérifie pas la comparabilité des valeurs : relever leur provenance avant de conclure.
Utiliser les chiffres 0–9. Format attendu : nombre positif ou nul, quatre décimales au maximum, sans espaces ; 600000 ms maximum pour LCP/INP et 1000 pour CLS. Un champ vide signifie donnée indisponible.
Lecture selon PageSpeed Insights
INP indisponible : exception PSI appliquée. La réactivité des interactions reste inconnue.
Huit exemples fictifs, accessibles sans JavaScript
V01 · Trois valeurs exactement aux limites bonnes
- LCP
- 2500 ms
- INP
- 200 ms
- CLS
- 0.1
Évaluation réussie pour les valeurs saisies, selon la règle PSI.
Les égalités restent bonnes : 2 500 ms, 200 ms et 0,1. Aucun arrondi préalable ne déplace la comparaison.
V02 · Une fraction au-dessus du seuil LCP
- LCP
- 2500.0001 ms
- INP
- 200 ms
- CLS
- 0.1
Évaluation non réussie pour les valeurs saisies, selon la règle PSI.
Le LCP nécessite une amélioration. Afficher 2 500 après arrondi ne justifie pas de le reclasser comme bon.
V03 · Limites supérieures de la zone intermédiaire
- LCP
- 4000 ms
- INP
- 500 ms
- CLS
- 0.25
Évaluation non réussie pour les valeurs saisies, selon la règle PSI.
Les trois valeurs nécessitent une amélioration. La catégorie mauvaise commence strictement au-dessus de ces limites.
V04 · Trois dépassements des limites hautes
- LCP
- 4000.0001 ms
- INP
- 500.0001 ms
- CLS
- 0.2501
Évaluation non réussie pour les valeurs saisies, selon la règle PSI.
Les trois métriques sont mauvaises. Prévoir des investigations distinctes sur le chargement, les interactions et les déplacements.
V05 · INP indisponible dans PageSpeed Insights
- LCP
- 2000 ms
- INP
- Donnée indisponible
- CLS
- 0.05
Évaluation réussie pour les valeurs saisies, selon la règle PSI.
INP indisponible : exception PSI appliquée. La réactivité des interactions reste inconnue.
La règle PSI permet une évaluation réussie si LCP et CLS sont bons malgré l’absence d’INP. Cela ne prouve aucune réactivité des interactions : l’exception reste affichée.
V06 · LCP absent, deux autres métriques présentes
- LCP
- Donnée indisponible
- INP
- 150 ms
- CLS
- 0.05
Évaluation impossible : LCP ou CLS indisponible.
Le périmètre ne peut pas être évalué selon cette règle PSI. Une absence de donnée n’est pas un zéro ni un résultat mauvais.
V07 · Un CLS légèrement supérieur à 0,1
- LCP
- 2000 ms
- INP
- 150 ms
- CLS
- 0.1001
Évaluation non réussie pour les valeurs saisies, selon la règle PSI.
LCP et INP restent bons, mais le CLS nécessite une amélioration. Une moyenne des trois nombres n’aurait aucun sens : unités et expériences diffèrent.
V08 · Séparateur de milliers non admis
- LCP
- 2 500 ms
- INP
- 150 ms
- CLS
- 0.05
Corriger les saisies invalides avant toute évaluation.
La saisie est refusée. Saisir 2500 pour 2 500 ms ; la virgule ou le point est réservé au séparateur décimal. Aucun résultat de performance n’est déduit d’une valeur invalide.
Choisir la preuve adaptée à la question
| Source | Question utile | Limite de lecture |
|---|---|---|
| CrUX API | Quel p75 est retourné pour cet identifiant, cet appareil et cette période ? | Données agrégées, couverture conditionnelle ; ne pas transformer une absence de rapport en panne. |
| PageSpeed Insights · terrain | Que décrit l’expérience disponible pour cette URL ou cette origine ? | Vérifier la portée effectivement affichée, les données manquantes et les dates. |
| Lighthouse · laboratoire | Quelle hypothèse puis-je reproduire dans un scénario contrôlé ? | Un essai et son score ne prouvent pas le résultat terrain de tous les utilisateurs. |
| RUM propre au service | Quel composant ou parcours explique le problème observé dans notre instrumentation ? | Documenter la méthode, la population et les différences de collecte avant une comparaison avec CrUX. |
Deux fenêtres de 28 jours se recouvrent largement
Exemple calendaire fictif : du 1er au 28 septembre, puis du 2 au 29 septembre, les fenêtres partagent 27 jours. Cela ne signifie pas que 27/28 des visites sont identiques : le trafic varie. Un correctif récent n’occupe d’abord qu’une partie de la fenêtre ; noter sa date et suivre le même segment plutôt que promettre une bascule immédiate.
Six recettes reliées aux parcours réels
| Cas CIE | Observation à recueillir | Action justifiée |
|---|---|---|
| P-IMAGE · Contenu principal | Élément LCP du modèle concerné, ordre des requêtes et dimensions réservées. | Prioriser le bon média et vérifier son rendu ; ne pas charger toutes les images en priorité. |
| P-INTERACTION · Ouverture d’une fiche | Action clavier ou tactile, trace du traitement et retour visible. | Réduire le travail responsable de l’attente sans supprimer l’annonce d’état ni le fonctionnement de la commande. |
| P-STABILITE · Bloc ajouté tardivement | Déplacement du contenu et position de la commande avant/après insertion. | Réserver l’espace ou revoir l’insertion ; vérifier que le focus et la cible tactile restent compréhensibles. |
| P-PERIMETRE · URL peu documentée | URL demandée et origine réellement affichée dans PSI. | Présenter le résultat avec sa portée exacte et compléter par une observation du modèle de page. |
| P-DEPLOIEMENT · Correctif récent | Date du changement, dates de collecte et population comparée. | Séparer validation locale immédiate et suivi terrain ; documenter les autres changements de trafic ou de contenu. |
| P-REGRESSION · Script tiers retiré | Mesure de performance et parcours métier après retrait, incluant consentement et formulaires. | Conserver le gain seulement si les fonctions attendues, les droits et l’accessibilité restent vérifiés. |
Les Core Web Vitals documentent une partie de l’expérience ; ils ne certifient ni l’accessibilité, ni la sécurité, ni la qualité éditoriale. Une amélioration ne garantit pas une position dans les résultats de recherche. Pour une décision utile, relier chaque chiffre à un élément ou une action, puis conserver les tests fonctionnels du parcours.
web.dev · Web Vitals · Living documentation · consulted 2026-10-23
Google Search Central · Core Web Vitals · Search guidance · consulted 2026-10-23
Provenance, date et crédits
Google documentation consulted 2026-10-23. CIE: original explanations, fictional examples and local threshold reader.
Google · About PageSpeed Insights · HTML SHA-256: 3ca78c96f9df1778aed6aaed634df06b534489176ce8b7824f870661f15e4c26
web.dev · Web Vitals · HTML SHA-256: 024989d5bce351f2a95be14d3a03cba110e5440d055ad5087425a72890ee754a
Chrome for Developers · CrUX methodology · HTML SHA-256: 825f49d646eb05c476a6ec2fbd3a9e12e094e081286489c8ab8def43b9627157
Chrome for Developers · CrUX API · HTML SHA-256: 814c2f1ec4e9cd14028ab30f196f1973ed3722af50fe98f2668e6be5f7338641
Seuils et règles de lecture adaptés de la documentation Google citée, sous licence Creative Commons Attribution 4.0, sauf mention contraire. Explications, exemples fictifs et lecteur local originaux CIE ; aucune approbation par Google n’est impliquée. CC BY 4.0
Google Developers · Site Policies · Documentation licensing and attribution
Répartition A/B : données et SRM
Comparer des populations avant de comparer les métriques
Une évolution de mesure peut modifier les personnes présentes dans l’analyse. Contrôler les effectifs à chaque étape avant d’attribuer une différence à l’interface.
- Nommer l’unité : utilisateur, appareil, session et événement ne sont pas interchangeables.
- Comparer les pertes de télémétrie et les exclusions dans chaque groupe.
- Conserver le périmètre, la fenêtre et les changements de configuration avec le résultat.
Explorer le contrôle de répartition et ses limites →
Microsoft Research · Diagnosing Sample Ratio Mismatch · Published 2020-09-14 · consulted 2026-10-23
NIST/SEMATECH · Binomial distribution · e-Handbook §1.3.6.6.18 · consulted 2026-10-23
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
- web.dev — Web Vitals
- web.dev — Getting started with measuring Web Vitals
- Microsoft Research · Diagnosing Sample Ratio Mismatch
- NIST/SEMATECH · Binomial distribution
- Google · About PageSpeed Insights
- Chrome for Developers · CrUX methodology
- Chrome for Developers · CrUX API
- Google Search Central · Core Web Vitals
Pour aller plus loin
Analyses associées
