Définir le périmètre
Choisissez gabarits, URL, appareils, régions et interactions importantes. Consignez la période, le volume de mesures et les changements intervenus.
GUIDE / PROTOCOLE
Mesurer la performance vécue d’une page web
Une note de laboratoire décrit un essai ; la performance vécue dépend des utilisateurs, des appareils et des parcours.
Réponse directe
Comment mesurer la performance sans confondre score et expérience ?
Séparez données terrain et laboratoire, mobile et ordinateur, pages et parcours. Suivez LCP, INP et CLS avec leurs distributions, puis recherchez la ressource ou l’interaction responsable avant de modifier le site.
01 / Méthode de contrôle
Méthode de contrôle
Comparer terrain et laboratoire
Examinez les Core Web Vitals au 75e percentile côté terrain ; utilisez les traces de laboratoire pour reproduire et diagnostiquer, pas comme substitut aux utilisateurs.
Attribuer les causes
Identifiez élément LCP, ressources critiques, scripts bloquants, tâches longues, déplacements de mise en page et chargements tiers. Reliez chaque hypothèse à une trace.
Corriger et surveiller
Priorisez par portée et coût, mesurez avant/après dans les mêmes conditions et surveillez les régressions après publication.
ATELIER DE MESURE
Trois repères pour lire la performance vécue
Les repères « bons » au 75e percentile sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1. Comparez un même appareil, une même période et un même périmètre. Le tableau explique un exemple fictif.
Exemple fictif · aucune mesure du site ou d’un client
| Indicateur | Calcul ou repère | Ce que le résultat permet de dire |
|---|---|---|
| Chargement · LCP | LCP ≤ 2.5 s | 2,8 s dépasse le repère de 2,5 s : investiguer le rendu du contenu principal. |
| Interaction · INP | INP ≤ 200 ms | 180 ms reste sous 200 ms : le repère d’interaction est atteint dans l’exemple. |
| Stabilité · CLS | CLS ≤ 0.1 | 0,08 reste sous 0,1 : le repère de stabilité est atteint dans l’exemple. |
Du relevé à la décision
Identifier la mesure
Séparez données terrain et essai de laboratoire. Conservez URL ou origine, appareil et dates.
Chercher la cause
Pour LCP, examinez le contenu principal ; pour INP, les interactions ; pour CLS, les déplacements de mise en page.
Refaire une comparaison
Relisez le même périmètre après correction. Une bonne valeur dans un essai isolé ne décrit pas tous les visiteurs.
Une moyenne meilleure et une médiane moins bonne
Cinq chargements de laboratoire sont mesurés avant et après, dans le même contexte d’essai. Les séries sont fictives et ne représentent pas une distribution d’usage réel.
| Unité observée | Avant | Après |
|---|---|---|
| Cinq observations (secondes) | 1 ; 1 ; 1 ; 1 ; 8 | 1,5 ; 1,5 ; 1,5 ; 1,5 ; 1,5 |
| Moyenne (secondes) | 2,4 | 1,5 |
| Médiane (secondes) | 1 | 1,5 |
Pourquoi « plus rapide en moyenne » ne décrit-il pas toute la série ?
La moyenne baisse de 2,4 à 1,5 s, tandis que la médiane augmente de 1 à 1,5 s. Conserver les observations et l’indicateur choisi avant le test. Cinq essais ne remplacent pas un percentile de visites réelles.
Repère de méthode : NIST · Measures of Location ·
Atelier de lecture
Une image LCP peut arriver après DOMContentLoaded
Trois traces fictives séparent cache, réseau et étapes du rendu sans annoncer de performance réelle.
Données et traces fictives pour apprendre : aucun résultat présenté ici ne provient d’un service interrogé en direct.
Comparer C1, W1 et C2 sans mélanger leurs conditions
Tous les temps partent du début de navigation. TTFB désigne ici responseStart−startTime, pas un temps serveur isolé. Les entrées LCP sont relevées dans une fenêtre de cinq secondes sans interaction.
Si le tableau dépasse l’écran, faites-le défiler horizontalement ; les flèches du clavier fonctionnent lorsque la zone est sélectionnée.
| Contrôle | Observation du cas | Ce que cela établit | Suite à donner |
|---|---|---|---|
| C1 · cache froid · réseau A | TTFB 400 ms ; DCL 900 ms ; LCP image 2 100 ms | DCL survient avant le dernier rendu LCP observé. | Suivre l’image : fin de réponse 1 800 ms, puis rendu. |
| W1 · cache chaud · réseau A | TTFB 350 ms ; DCL 700 ms ; LCP image 1 000 ms | Les conditions de cache diffèrent de C1. | Décrire une autre condition, pas attribuer l’écart à une correction. |
| C2 · cache froid · réseau B | TTFB 800 ms ; DCL 1 400 ms ; LCP image 3 800 ms | Le réseau change ; C2 n’est pas une répétition comparable de C1. | Garder les séries séparées et répéter sous conditions identiques. |
| Chronologie C1 | LCP−DCL = 1 200 ms ; LCP−fin image = 300 ms | Ce sont des intervalles, pas des causes prouvées. | Examiner découverte, transfert et rendu ; ne pas additionner les marqueurs comme des durées disjointes. |
Que démontre l’écart C1/W1 ?
Ouvrir chaque proposition pour comparer son diagnostic. Plusieurs contrôles peuvent rester nécessaires.
Une correction a fait gagner 1 100 ms à tous les visiteurs.
Non : le cache change et aucun effet utilisateur général n’est mesuré.
DCL à 900 ms prouve que C1 était entièrement affichée.
Non : l’image LCP du cas est rendue plus tard.
Une différence de 1 100 ms entre deux conditions de laboratoire.
Adapté. Pour attribuer un gain, comparer des répétitions avant/après avec cache, réseau et contenu contrôlés.
Trace comparative conservée
Cas : DEMO-P24 ; fenêtre 5 s sans interaction C1 froid/A : TTFB 400 ; DCL 900 ; LCP 2100 ms C1 image : réponse finie 1800 ms ; rendu 2100 ms W1 chaud/A : TTFB 350 ; DCL 700 ; LCP 1000 ms C2 froid/B : TTFB 800 ; DCL 1400 ; LCP 3800 ms C1−W1 pour LCP : 1100 ms ; conditions différentes Bilan : hypothèse à tester, pas gain terrain
Conserver version, viewport, appareil, cache, réseau, élément LCP et traces de ressources. Décrire les répétitions et la règle de synthèse avant de rapprocher ces essais de données terrain.
Documentation des règles, distincte des exemples fictifs
02 / Preuves à conserver
Preuves à conserver
Population mesurée
Source, dates, appareil, pays, URL ou groupe de pages et taille de l’échantillon.
Distribution
LCP, INP et CLS avec percentile, plage et distinction terrain/laboratoire.
Trace causale
Chronologie réseau, élément concerné, tâche ou ressource identifiée et hypothèse testée.
Décision
Modification, responsable, effet observé et seuil de suivi.
Comparer avec les autres situations et exercices
POINT DE CONTRÔLE
Avant de conclure
Une erreur de lecture fréquente et la vérification qui permet de l’éviter.
Conclusion trop rapide
Un score de laboratoire ne représente pas à lui seul l’expérience de tous les visiteurs. Les appareils, réseaux, pages et moments de mesure créent des écarts.
Contrôle décisif
Définir pages et parcours prioritaires, comparer mesures terrain et laboratoire, puis isoler le coût des images, scripts et polices. Vérifier que le correctif améliore le parcours sans déplacer le problème.
APRÈS LE CONTRÔLE
Décider selon le constat
Le laboratoire s’améliore, le terrain reste stable
Ne concluez pas à un gain utilisateur. Vérifiez délai de collecte, population, cache, type d’appareil et URL avant d’attribuer l’écart.
La page charge vite mais une interaction reste lente
Examinez les interactions qui dégradent INP, les tâches JavaScript et les composants tiers ; mesurez après correction sur le même parcours.
Arbitrage et trace de décision
Arbitrage et trace de décision
Ce que le contrôle doit permettre de décider, et la preuve à conserver pour réexaminer ce choix.
Preuve suffisante
Mesurer des pages représentatives avec le même appareil, réseau, cache et version, puis distinguer données de terrain et laboratoire. Garder la trace des ressources dominantes.
Décision suivante
Traiter l’image principale, le CSS ou le script responsable du ralentissement observé. Comparer avant et après sur la même méthode et surveiller une éventuelle régression.
Cas de contrôle approfondis
Situations types pour préparer un contrôle. Elles ne décrivent pas des missions ou observations réalisées.
Une mesure locale rapide masque un parcours mobile lent
Ce qu’il faut examiner
Comparer plusieurs chargements, conditions réseau et appareils. Séparer les mesures de laboratoire des observations d’usage et regarder la dispersion, les pages concernées et les conditions de collecte.
Décision et action
Traiter le goulot identifié dans le parcours prioritaire. Ne pas généraliser une moyenne locale à tous les visiteurs ni attribuer une variation à une correction sans conditions comparables.
Preuve à conserver
Conserver le scénario, l’environnement, le nombre de mesures, leur distribution et les ressources qui ont retardé le contenu utile.
Une image principale attend une dépendance évitable
Ce qu’il faut examiner
Examiner la chronologie des requêtes et le moment où l’image devient découverte, téléchargée puis affichée. Vérifier les scripts, styles et options de chargement qui retardent cette séquence.
Décision et action
Corriger la cause observée, puis mesurer à nouveau. Une réduction du poids ne suffit pas lorsque le navigateur découvre tardivement la ressource qui porte le contenu principal.
Preuve à conserver
Garder les traces avant et après, l’URL de la ressource, ses dimensions, son poids et les changements de priorité réellement appliqués.
Une moyenne masque une page lente
Ce qu’il faut examiner
Séparer gabarits, langues, appareils et conditions de mesure.
Décision et action
Prioriser la tâche lente observée plutôt qu’une moyenne globale rassurante.
Preuve à conserver
URL, conditions, ressource dominante et mesure après correction.
Relecture avant décision
Ces questions complètent la méthode. Elles aident à vérifier ce qui est réellement établi, sans effacer les réserves du relevé.
Mesure comparable
Les mesures avant et après décrivent-elles appareil, réseau, cache, page et conditions identiques ? Conserver plusieurs observations et distinguer mesure de laboratoire et usage réel.
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Le relevé avant utilise un téléphone et un cache froid ; le relevé après utilise un ordinateur et un cache chaud.
- État déclaré
- Écart observé
- Décision et prochain contrôle
- Reconstituer des conditions comparables avant d’annoncer un gain. Conserver les observations initiales comme contextes différents.
Parcours sans régression
Le gain de chargement conserve-t-il recherche, interactions, formulaire et images utiles ? Tester une interaction tardive et un état d’erreur, pas seulement l’arrivée sur la page.
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- L’image principale charge plus vite, mais le bouton de recherche ne répond plus après une saisie.
- État déclaré
- Écart observé
- Décision et prochain contrôle
- Traiter la régression fonctionnelle avant de clore l’amélioration. Rejouer recherche vide, recherche utile et état d’erreur.
Population et percentile
Le percentile et la catégorie d’appareil sont-ils conservés ? Ne pas confondre une moyenne d’essais isolés avec une distribution d’usage réel.
Documentation consultée : web.dev · Web Vitals ·
Voir une décision commentée
Exemple fictif : l’état concerne uniquement le critère et le périmètre décrits.
- Observation fictive
- Trois essais de laboratoire donnent une moyenne ; aucune distribution de visites réelles n’est disponible.
- État déclaré
- Non vérifié
- Décision et prochain contrôle
- Qualifier le résultat de mesure de laboratoire. Laisser le percentile d’usage réel non vérifié et préciser la catégorie d’appareil.
OUTILS / REGISTRES
Informations à relever
Séparer les mesures de laboratoire des données de terrain. Comparer la même page, le même appareil et des fenêtres comparables ; conserver le percentile et la taille d’échantillon disponibles.
- Date de consultation et fuseau
- URL exacte
- Appareil / navigateur
- Métrique / mesure
- Échantillon / population
- Résultat observé
- Décision / prochaine action
- Responsable du contrôle
- Prochain contrôle
03 / FAQ
Questions fréquentes
Pourquoi les chiffres divergent-ils ?
Le terrain agrège de vrais appareils et réseaux ; le laboratoire utilise un scénario contrôlé. Vérifiez population et période avant de comparer.
Que signifie le 75e percentile ?
Il indique une valeur que 75 % des visites mesurées atteignent ou améliorent, pour une métrique et une population données.
Peut-on diagnostiquer INP avec un seul test ?
Non. Testez plusieurs interactions et utilisez les données terrain ; une trace de laboratoire aide à expliquer un cas.
Faut-il optimiser toutes les images ?
Ciblez d’abord les images effectivement responsables du chargement perçu, avec dimensions et priorité adaptées.
Quelle valeur retenir lorsque les mesures varient ?
Conserver les exécutions et décrire leur dispersion avec une règle de synthèse explicite. Le choix doit répondre à l’objectif du contrôle et permettre de refaire une comparaison dans les mêmes conditions.
04 / Références officielles
Références officielles
Présenter un contexte
REPÈRES DOCUMENTÉS
Lire les seuils Core Web Vitals sans inventer un verdict
LCP, INP et CLS décrivent trois dimensions distinctes de l’expérience. Leurs seuils publiés classent une valeur ; ils ne transforment pas un test isolé en observation représentative de tous les visiteurs.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| LCP | ≤ 2500 ms · > 4000 ms | LCP décrit le rendu du plus grand contenu éligible. Bon jusqu’à 2 500 ms inclus ; à améliorer au-delà, jusqu’à 4 000 ms inclus ; mauvais au-dessus. |
| INP | ≤ 200 ms · > 500 ms | INP décrit la réactivité aux interactions éligibles. Bon jusqu’à 200 ms inclus ; à améliorer jusqu’à 500 ms inclus ; mauvais au-dessus. Ce n’est pas le temps complet d’une tâche métier. |
| CLS | ≤ 0,1 · > 0,25 | CLS est un score sans unité de stabilité visuelle. Bon jusqu’à 0,1 inclus ; à améliorer jusqu’à 0,25 inclus ; mauvais au-dessus. Ne pas convertir ce score en millisecondes. |
| p75 | 75 % | L’évaluation de terrain retient le 75e percentile : environ trois observations sur quatre sont à cette valeur ou en dessous. La moyenne arithmétique répond à une autre question. |
| COHORT | URL / origine · appareil · période | Comparer le même périmètre : page ou origine, appareil et période. Les seuils restent identiques entre mobile et ordinateur ; les populations doivent être lues séparément. |
| MISSING | ≠ 0 | Une métrique absente, notamment faute d’interaction éligible, n’est pas une valeur nulle. Sans les trois métriques requises et leur contexte, ne pas annoncer une réussite globale. |
Classer trois valeurs selon les seuils publiés
Valeurs initiales : limites de la classe « bon ». Aucune requête réseau ni mesure du site. Le contexte est déclaré par vous, sans vérification des données.
Saisir trois décimaux positifs ou nuls, sans unité ni séparateur de milliers (64 caractères maximum). Point ou virgule décimale accepté.
Exemple initial : les trois limites appartiennent à la classe « bon ». Classement numérique uniquement : aucune conclusion sur la réussite de terrain.
| Métrique | Valeur saisie | Classe numérique |
|---|---|---|
| LCP | 2500 ms | Bon |
| INP | 200 ms | Bon |
| CLS | 0.1 | Bon |
| Métrique | Bon | À améliorer | Mauvais |
|---|---|---|---|
| LCP | ≤ 2500 ms | > 2500 · ≤ 4000 ms | > 4000 ms |
| INP | ≤ 200 ms | > 200 · ≤ 500 ms | > 500 ms |
| CLS | ≤ 0.1 | > 0.1 · ≤ 0.25 | > 0.25 |
À retenir pour le dossier
Le lecteur ci-dessous applique uniquement les bornes numériques publiées. Ses valeurs initiales sont les limites de la classe « bon », pas des mesures de ce site.
Trois valeurs dans la zone « bon » prouvent-elles que le site réussit ?
Seulement sous les conditions de l’évaluation de terrain : trois p75 comparables et éligibles, au périmètre déclaré. Un résultat de laboratoire ou une saisie manuelle ne vérifie pas ces conditions.
Documentation primaire
Documentation consultée le .
REPÈRES DOCUMENTÉS
CrUX : distinguer fenêtre, périmètre et données disponibles
Une réponse CrUX décrit une population admissible dans une fenêtre glissante. Avant de comparer deux p75, conserver la clé demandée, les appareils et les dates renvoyées avec le résultat.
| Repère | Valeur ou forme | Ce que cela désigne |
|---|---|---|
| url / origin | page / origine | Une requête URL cible une page ; une requête origin agrège les pages de cette origine. Le bon résultat de l’origine ne remplace pas automatiquement la mesure d’une page précise. |
| formFactor | PHONE · DESKTOP · TABLET | Le filtre formFactor isole une catégorie d’appareil. Son omission agrège les catégories disponibles ; elle ne signifie pas « ordinateur ». Comparer deux filtres différents change la population. |
| collectionPeriod | firstDate · lastDate | Le schéma de réponse utilise firstDate et lastDate dans collectionPeriod. Archiver ces deux bornes avec la métrique, plutôt que la seule date de consultation de l’API. |
| WINDOW | 28 jours | La période couvre 28 jours, même pour une page créée plus récemment. Cette fenêtre ne prouve donc ni 28 jours d’observations réelles ni une présence continue dans l’échantillon. |
| percentiles.p75 | ≠ moyenne | Le champ p75 est un percentile, pas une moyenne et pas une mesure instantanée. Deux fenêtres successives se recouvrent largement ; leurs valeurs ne sont pas deux échantillons indépendants. |
| ELIGIBILITY | public · populaire | L’admissibilité dépend des utilisateurs, des pages et d’une popularité minimale dont le seuil exact n’est pas publié. Une réponse absente ne permet d’inférer ni trafic nul ni mauvaise performance. |
À retenir pour le dossier
L’API est mise à jour quotidiennement avec un décalage de collecte. Répéter la même requête ne crée pas une mesure en temps réel ; conserver aussi le périmètre effectivement reçu.
Peut-on appeler la période « 28 jours mesurés » ?
Préférer « fenêtre d’agrégation de 28 jours ». Une page récente ou temporairement non admissible peut n’apporter qu’une partie des observations possibles.
Documentation primaire
Documentation consultée le .
APPROFONDISSEMENT / PRATIQUE
Relier une mesure technique à un usage
Une page obtient un score variable selon l’outil ou l’exécution. Pour comprendre l’expérience, il faut documenter le contexte et distinguer la mesure de laboratoire des observations d’usage disponibles.
Mis à jour le .
Vérifications prioritaires
Relever appareil, réseau simulé, page, état du cache et répétitions. Examiner les ressources qui retardent l’affichage utile ou l’interaction, puis reproduire la mesure après correction.
Pièges d’interprétation
Comparer deux scores issus de conditions différentes peut attribuer à une optimisation un effet qui vient du test. Un gain technique peut aussi laisser inchangé un parcours confus.
Document de travail à conserver
Un dossier de mesure présente conditions, valeurs brutes, dispersion et changement effectué. Il relie la correction à l’étape du parcours qu’elle cherche à améliorer.