Que mesurer : indicateurs clés pour des performances axées sur l'utilisateur (Que Mesurer Indicateurs Cles Pour Des Performances Axees Sur Lutilisateur)

Mesure des performances centrée sur l'utilisateur

La mesure des performances axées sur l'utilisateur ne dépend pas du fait que le système génère du trafic ou qu'il soit techniquement chargé ; Il vérifie si les gens atteignent leurs objectifs rapidement, facilement, de manière fiable et satisfaisante. Les systèmes de mesure les plus puissants lisent ensemble les données comportementales, la perception des utilisateurs, les résultats commerciaux et les performances techniques.

1. Mesures du comportement des utilisateurs

Ceux-ci montrent ce que font réellement les utilisateurs :

• Taux d'achèvement des tâches : pourcentage d'utilisateurs ayant terminé avec succès une tâche définie.
• Durée de la tâche : Le temps nécessaire pour atteindre l'objectif.
• Taux d'erreur : Fréquence des actions ayant échoué, des erreurs de validation ou des erreurs système.
• Taux de récupération après erreur : Pourcentage d'utilisateurs qui ont récupéré après l'erreur et terminé la tâche.
• Adoption de la fonctionnalité : taux auquel les utilisateurs éligibles utilisent la fonctionnalité au cours d'une période donnée. - Abandon de l'entonnoir : là où les utilisateurs abandonnent le processus en plusieurs étapes.
• Délai de valorisation : Temps entre l'inscription ou l'entrée et le premier résultat significatif.

Les mesures comportementales fonctionnent mieux lorsqu'elles sont liées à un objectif utilisateur spécifique, par exemple « finaliser le paiement » plutôt que simplement « augmenter les clics ». Le framework UX de GitLab considère l'achèvement des tâches, la durée de la tâche, les erreurs, la précision du premier clic et l'adoption des fonctionnalités comme des mesures comportementales clés. handbook.gitlab

2. Indicateurs de perception des utilisateurs

Analytics montre ce qui se passe ; les mesures d'attitude aident à expliquer pourquoi :

• Satisfaction client (CSAT) : Dans quelle mesure ils étaient satisfaits de l'expérience.
• Facilité d'utilisation perçue : La facilité d'utilisation du produit.
• Score d'effort client (CES) : l'effort qu'ils pensent avoir déployé.- Efficacité perçue : Si le produit fait gagner du temps.
• Net Promoter Score (NPS) : Probabilité de recommander le produit. - Utilité perçue : Si cela résout un problème significatif.

Un produit peut avoir un taux d’achèvement de tâches élevé mais néanmoins paraître frustrant ou inutilement difficile. Par conséquent, les mesures comportementales et comportementales doivent être évaluées ensemble. handbook.gitlab

3. Mesures de rétention et de valeur

Ceux-ci montrent si le produit offre une valeur continue :

• Taux d'activation : Le pourcentage de nouveaux utilisateurs effectuant la première action significative.
• Taux de rétention : Le pourcentage d'utilisateurs qui reviennent et restent actifs après une certaine période de temps.
• Taux de désabonnement : Pourcentage d'utilisateurs qui arrêtent d'utiliser le produit.
• DAU/WAU/MAU : Utilisateurs actifs quotidiens, hebdomadaires et mensuels.
• Adhésivité : Généralement approximée comme le rapport DAU÷MAU.
• Conservation des cohortes : Suivi séparé des groupes par date d'inscription ou caractéristique commune. - Taux de parrainage : à quelle fréquence les utilisateurs parrainent ou invitent d'autres personnes.

Une structure fonctionnelle : définissez une North Star Metric qui représente la valeur délivrée à l'utilisateur, puis choisissez deux ou trois métriques d'entrée sur lesquelles les équipes peuvent influencer. Par exemple, un produit de collaboration répertorie les « collaborations hebdomadaires réussies » comme étoile du Nord ; Peut utiliser l’activation, l’adoption de fonctionnalités et la rétention en tant que promoteurs. youtube

4. Indicateurs de performances techniques

Dans les produits numériques, la vitesse technique doit être mesurée du point de vue de l'utilisateur :

Expérience utilisateur	Métriques utiles
Première visibilité	Première peinture de contenu (FCP), la plus grande peinture de contenu (LCP)
Détermination	Changement de mise en page cumulatif (CLS)
Réponse du serveur	Temps jusqu'au premier octet (TTFB)
Maîtrise	Cohérence des images et réponse de l'animation
Fiabilité	Taux de plantages, d'échecs de requêtes, de pannes et d'erreurs

Les performances Web doivent être mesurées à la fois par des tests de laboratoire contrôlés et par la surveillance des utilisateurs réels (RUM) ; car l'appareil, le réseau, la personnalisation et l'interaction changent fondamentalement l'expérience. Web

5. Un ensemble de mesures pratiques

La plupart des équipes peuvent commencer avec cinq indicateurs :

1. Une mesure de valeur : Le résultat principal est la raison pour laquelle les utilisateurs viennent.
2. Une métrique comportementale : Taux d'achèvement des tâches ou durée de la tâche.
3. Une métrique de perception : CSAT, CES ou facilité d'utilisation perçue.
4. Une mesure de rétention : Rétention ou réutilisation des cohortes.
5. Une mesure de fiabilité ou de performances : Taux d'erreur, INP, LCP ou disponibilité.

Les bonnes mesures doivent être claires, normalisées, comparables dans le temps, découpées en groupes d'utilisateurs significatifs et exploitables. Ne vous fiez pas uniquement au nombre total de pages vues, aux téléchargements, aux utilisateurs enregistrés ou à la durée de la session ; ceux-ci peuvent croître sans produire de valeur significative. youtube

Exemple

Pour un service de remboursement en ligne :

• North Star : Réclamations retournées avec succès par employé actif.
• Comportement : Taux d'achèvement des demandes et délai médian de soumission.
• Perception : Score de facilité d'utilisation après expédition.
• Rétention : Pourcentage d'employés qui soumettent une deuxième demande dans les 90 jours.
• Technique : Taux d'erreur et INP lors du chargement du plug.
• Diagnostic : Taux d'abandon à l'étape de vérification du bon.Cette combinaison ne détermine pas seulement le nombre de personnes qui entrent dans le processus ; s'ils ont été capables de le terminer, comment ils ont ressenti l'expérience, s'ils sont revenus et si des problèmes techniques ont entravé le succès.

Concepts récurrents dans cette section```text

📦 Laboratuvar vs saha Kontrollü, tekrarlanabilir teşhis ile gerçek kullanıcı ortamındaki doğrulama.

📦 Core Web Vitals (CWV) LCP, INP ve CLS—yükleme, yanıt ve görsel kararlılık; gerçek kullanıcıların 75. yüzdeliğinde.

📦 FID → INP (Mart 2024) FID yalnızca ilk girdi gecikmesini ölçüyordu; INP ziyaret boyunca etkileşim yanıtını ölçer.

📦 RUM Gerçek kullanıcı izleme: cihaz, ağ, rota ve özellik boyutlarında production ölçümü.

📦 CrUX Chrome kullanıcı deneyimi raporu—uygun siteler için kamuya açık saha verisi.

📦 Performans bütçesi LCP/INP/CLS, JS ağırlığı, üçüncü taraf maliyeti ve iş akışı başarı limitleri.

📦 Attribution (ilişkilendirme) web-vitals attribution build: LCP öğesi, INP hedefi, LoAF ve alt faz süreleri.

## Tests en laboratoire et mesures sur le terrain

**Les tests en laboratoire** axés sur les performances de l'utilisateur mesurent le produit dans des conditions contrôlées et reproductibles ; La **mesure de terrain** observe les performances dans l'environnement réel des utilisateurs. Les résultats de laboratoire sont généralement meilleurs pour trouver la cause du problème ; Les résultats sur le terrain permettent de mieux comprendre si le produit fonctionne au quotidien. [web.mit](https://web.mit.edu/6.813/www/sp16/classes/11-experiment-design/)

### Test de laboratoire

Les tests en laboratoire placent les utilisateurs, les tâches, les appareils et les conditions dans un protocole défini.

Dimensions typiques :

- Taux d'achèvement des tâches.
- Durée du mandat.
- Fréquence des erreurs et récupération.
- Chemins de navigation ou de clic.
- Précision du premier clic.
- Disponibilité perçue et charge de travail.
- Satisfaction post-tâche.
- Comparaison entre les versions de conception.

**Forces :** contrôle et répétabilité élevés ; il est facile de comparer des conceptions concurrentes ; isole les problèmes d'interface spécifiques ; Convient au prototypage et aux expériences contrôlées de style A/B.

**Limites :** les participants peuvent se comporter différemment parce qu'ils savent qu'ils sont observés ; les tâches artificielles peuvent ne pas refléter les véritables priorités ; Une salle de test silencieuse ne peut pas reproduire toutes les conditions de travail, de réseau ou techniques. Le laboratoire peut surestimer la convivialité si le contexte réel est plus difficile.

Les études comparant les tests d'utilisabilité en laboratoire et sur le terrain ne trouvent pas de gagnant universel : lorsque les conditions sont favorables, les résultats peuvent être similaires ; Les différences surviennent dans des conditions difficiles, une faible disponibilité ou des tâches concurrentes. [pubmed.ncbi.nlm.nih](https://pubmed.ncbi.nlm.nih.gov/30487113/)

### Mesures sur le terrainLes mesures sur le terrain sont effectuées là où les utilisateurs travaillent, voyagent, font leurs achats ou utilisent normalement le produit. Cela peut inclure l'observation directe, des entretiens contextuels, l'étude d'un journal, la télémétrie à distance ou des tests d'utilisabilité sur le terrain.

Mesures de terrain utiles : réussite de la mission dans le monde réel ; durée incluant les interruptions ; conditions environnementales et du réseau ; différences entre appareils et plates-formes ; fréquence et gravité des erreurs ; solutions de contournement ; réutilisation et conservation ; décalage, plantages et requêtes ayant échoué ; Commentaires des utilisateurs sur le respect du flux de travail.

**Forces :** comportement et contexte authentiques ; La distraction révèle des problèmes causés par les infrastructures ou les outils environnementaux ; Il montre si le produit est intégré dans des routines réelles. Il est particulièrement précieux dans les produits mobiles, de travail, industriels, de soins de santé et géolocalisés.

**Limites :** moins de contrôle sur les variables ; difficile de comparer directement les participants ; les données peuvent être plus bruyantes ; les exigences en matière de confidentialité et de consentement sont plus strictes.

Le domaine est fort en réalisme, le laboratoire est fort en précision et en contrôle. [web.mit](https://web.mit.edu/6.813/www/sp16/classes/11-experiment-design/)

### Qu'est-ce qui est mesuré ?

| Question | Mesures en laboratoire | Dimensions du terrain |
|---|---|---|
| Les utilisateurs peuvent-ils terminer la tâche ? | Taux d'achèvement dans le scénario défini | Taux d'achèvement lors des travaux réels |
| Dans quelle mesure fonctionnent-ils efficacement ? | Durée de la tâche, clics, frappes | Durée incluant les pannes, les transitions et les solutions de contournement |
| Qu'est-ce qui ne va pas ? | Erreurs observées et interactions échouées | Erreurs de production, demandes d'assistance, tâches abandonnées |
| Comment ça se sent ? | Satisfaction, charge de travail, convivialité perçue | Satisfaction à long terme, confiance, frustration, valeur perçue |
| Est-ce fiable ? | Temps de réponse contrôlé et tests des appareils | Latence réelle, variation de connexion, plantages et échecs || Est-ce que cela produit de la valeur ? | Résultat de mission instantané | Réutilisation, rétention, adoption et résultats pour les entreprises et les utilisateurs |

### Approche recommandée

Utilisez les deux comme boucles ; N'en choisissez pas un seul :

1. **Démarrez dans le laboratoire** : identifiez les problèmes d'utilisabilité évidents et comparez les alternatives.
2. **Mesurer sur le terrain** : tester le comportement dans des conditions authentiques.
3. **Retour au laboratoire** : recherchez la cause des problèmes importants sur le terrain.
4. **Vérifiez en production** : avec analyses, commentaires et surveillance des performances.
5. **Découpez les résultats** : appareil, expérience, besoin d'accessibilité, emplacement, connexion et type de tâche.

Exemple : une application de dépenses mobile peut bénéficier d'un tarif d'expédition de 95 % en laboratoire. Le champ peut révéler des pertes lors de la photographie de puces dans un éclairage faible ou sur un réseau mobile médiocre. Le laboratoire indique un problème d'interface ; Le terrain révèle les conditions environnementales et techniques qui le rendent important.

Principe de base : **décrit les compétences en laboratoire ; le terrain valide les performances du monde réel**. Une évaluation crédible centrée sur l’utilisateur nécessite généralement les deux.

## Core Web Vitals : indicateurs clés

**Core Web Vitals (CWV)** sont des métriques de Google centrées sur l'utilisateur qui évaluent trois éléments de l'expérience d'une page : le chargement, la réactivité et la stabilité visuelle. L'ensemble actuel est **LCP, INP et CLS**. [Web](https://web.dev/articles/vitals)

| Métrique | Quelles mesures | Bonne cible |
|---|---|---:|
| **La plus grande peinture de contenu (LCP)** | La rapidité avec laquelle le contenu principal visible (image de héros, titre ou gros bloc de texte) apparaît | ≤ 2,5 secondes |
| **Interaction avec Next Paint (INP)** | Quelle est la rapidité de la réponse visuelle aux clics, tapotements et interactions au clavier tout au long de la visite | ≤ 200 millisecondes |
| **Décalage cumulatif de la mise en page (CLS)** | Quelle quantité de contenu visible change de manière inattendue pendant le chargement ou l'utilisation de la page | ≤ 0,1 |

### Que dit chaque métrique ?- **LCP — chargement :** « Les utilisateurs peuvent-ils voir rapidement le contenu important ? »
- **INP — réponse :** "L'interface répond-elle immédiatement lorsque les utilisateurs interagissent ?"
- **CLS — stabilité :** « Peut-il lire et cliquer sur la page sans défilement inattendu ? »

INP remplace **First Input Delay (FID)** en 2024 — transition officielle **12 mars 2024**. Le FID a mesuré uniquement l’interaction initiale ; L'INP évalue la réponse d'interaction tout au long de la visite. La prise en charge du FID dans les outils de navigateur a été interrompue depuis septembre 2024. [dynatrace](https://www.dynatrace.com/knowledge-base/core-web-vitals/) · [developer.chrome](https://developer.chrome.com/docs/crux/release-notes)

### Comment le CWV est-il évalué ?

Données utilisateur réelles **75. En pourcentage**, mesurez séparément pour les appareils mobiles et les ordinateurs de bureau. Pour qu'une page reçoive une note globale « bonne » CWV, les trois mesures doivent atteindre le seuil « bon ». [Web](https://web.dev/articles/vitals)

Lighthouse et Chrome DevTools sont utiles pour le diagnostic des problèmes ; les données réelles sur le terrain des utilisateurs montrent les performances réelles sur tous les appareils, réseaux et emplacements. PageSpeed ​​​​​​Insights, CrUX et Search Console aident à suivre ces résultats. [Web](https://web.dev/articles/vitals)

### Actions correctives typiques

- **LCP :** optimise les visuels, réduit les ressources bloquant le rendu, améliore la réponse du serveur, donne la priorité au contenu au-dessus de la ligne de flottaison.
- **INP :** divise les tâches JavaScript longues, limite le travail du thread principal, accélère les gestionnaires d'événements.
- **CLS :** Allouez de l'espace pour les images et les publicités, n'ajoutez pas de contenu par-dessus le contenu existant, corrigez les polices et les tailles.

Les CWV sont des indicateurs techniques précieux ; mais doit être combiné avec des résultats axés sur l'utilisateur tels que l'achèvement des tâches, l'abandon, la satisfaction et la conversion. Une page rapide n’est pas nécessairement une page utile ou réussie.## La plus grande peinture de contenu (LCP)

**LCP mesure la rapidité avec laquelle le contenu principal visible apparaît après que l'utilisateur ouvre une page.** Il enregistre le moment où le rendu de la plus grande image, image vidéo ou bloc de texte dans la fenêtre d'affichage est terminé ; est un indicateur puissant de la vitesse de chargement perçue. [Web](https://web.dev/articles/lcp)

### Qu'est-ce qui compte comme LCP ?

Élément LCP souvent : image de héros ou de bannière ; titre ou bloc de texte bien visible ; image du produit ; affiche vidéo ou première image vidéo visible ; C'est une grande image chargée de CSS.

LCP diffère de **First Contentful Paint (FCP)** : FCP mesure le premier moment où un contenu apparaît ; LCP estime le moment où le contenu principal devient visible. [Web](https://web.dev/articles/lcp)

### Seuils LCP

| Résultat LCP | Expérience |
|---|---|
| **2,5 secondes ou moins** | Bon |
| **Plus de 2,5 à 4 secondes** | Devrait être amélioré |
| **Plus de 4 secondes** | Faible |

**75 % des chargements de pages. Tenez compte du pourcentage**, au moins séparément des mobiles et des ordinateurs de bureau, afin que le résultat soit représentatif de la plupart des utilisateurs, et pas seulement de la moyenne. [Web](https://web.dev/articles/lcp)

### Qu'est-ce qui cause le ralentissement du LCP ?

LCP se compose généralement de **quatre délais** :

1. **Délai de réponse du serveur :** Le navigateur attend la première réponse HTML (TTFB).
2. **Délai de chargement :** Le navigateur découvre la ressource LCP tardivement ou commence à la demander tardivement.
3. **Temps de chargement des ressources :** Le téléchargement des images, vidéos, polices ou autres contenus prend beaucoup de temps.
4. **Délai de rendu :** La source est prête mais JavaScript, CSS ou autres travaux retardent le rendu à l'écran. [developer.chrome](https://developer.chrome.com/docs/performance/insights/lcp-breakdown)Selon le HTTP Archive Web Almanac 2024, sur environ 73 % des pages mobiles, l'élément LCP est une image ; Le LCP basé sur une image a tendance à être environ deux fois plus lent que celui basé sur du texte. La désactivation du chargement différé dans l'image LCP au-dessus de la ligne de flottaison et l'attribution de la priorité au réseau avec `fetchpriority="high"` si nécessaire préservent le budget critique.

### Comment améliorer le LCP ?

- Améliorer la réponse du serveur ; Utilisez une mise en cache ou un CDN efficace.
- Optimiser et dimensionner correctement l'image LCP.
- Utiliser des formats modernes et une compression appropriée.
- Lorsque l'exploration est retardée, préchargez uniquement la ressource LCP critique.
- Ne chargez pas paresseusement l'image LCP au-dessus de la ligne de flottaison.
- Supprimez le CSS bloquant le rendu et le JavaScript inutile.
- Réduisez les longues tâches du thread principal.
- Faites apparaître rapidement le texte important lors du chargement des polices Web.
- Évitez les redirections excessives et les chaînes de requêtes critiques.

Utilisez des outils de laboratoire comme Lighthouse pour diagnostiquer la cause ; Validez l’amélioration avec des données de terrain utilisateur réelles. Une page qui semble bonne lors de tests contrôlés peut néanmoins produire un LCP médiocre pour les utilisateurs sur un appareil ou un réseau lent.

## FID, INP et CLS

Ces métriques couvrent deux parties différentes de l'expérience : la **réactivité** (la rapidité avec laquelle la page répond aux entrées) et la **stabilité visuelle** : si le contenu reste là où les utilisateurs s'attendent à ce qu'il soit.

### Délai de première entrée (FID)

**FID a mesuré le délai entre la première interaction de l'utilisateur et le début du traitement par le navigateur.** Il a uniquement capturé le délai de saisie initial, par exemple entre l'appui sur un bouton et le démarrage du gestionnaire d'événements.Le FID était initialement utile pour détecter les pages bloquées par JavaScript ; mais il n’a pas mesuré l’interaction complète ni les interactions ultérieures. FID a maintenant été retiré sous le nom de **Core Web Vital et remplacé par INP**. [developer.chrome](https://developer.chrome.com/docs/crux/release-notes)

Le défaut architectural du FID était qu'il permettait aux développeurs d'améliorer artificiellement le score en asynchronisant les événements ; L’utilisateur pouvait sentir la page ennuyeuse alors que de longues tâches s’exécutaient en arrière-plan. L'INP comble cet angle mort.

### Interaction avec la peinture suivante (INP)

**INP mesure la rapidité de la réponse visuelle aux interactions de l'utilisateur tout au long de la visite.** La latence d'entrée inclut le traitement du gestionnaire d'événements, la tâche de rendu et le temps jusqu'à la prochaine mise à jour de l'écran. [Web](https://web.dev/articles/inp)

Exemples : cliquer sur le menu de navigation ; taper dans le champ de recherche ; ne touchez pas à ajouter au panier ; ouvrir une boîte de dialogue ou un menu contextuel ; en sélectionnant un filtre ou un onglet.

| Score INP | Réactivité |
|---|---|
| **≤ 200 ms** | Bon |
| **> 200 – 500 ms** | Devrait être amélioré |
| **> 500 ms** | Faible |

Un bon INP représente ** 75 % des visites réelles de pages. pourcentage** : généralement les appareils mobiles et les ordinateurs de bureau sont évalués séparément. [Web](https://web.dev/articles/optimize-inp)

INP est divisé en trois sous-phases : **latence d'entrée** (si le thread principal est occupé), **temps de rendu** (gestionnaires d'événements lourds), **latence de présentation** (style/mise en page/peinture et grand DOM). L'optimisation dépend de la phase dominante.

#### Améliorer l'INP

- Divisez les tâches JavaScript longues (`scheduler.yield()` ou API du planificateur).
- Réduisez les scripts JavaScript et tiers inutiles.
- Gardez les gestionnaires d'événements petits et efficaces.
- Reportez les travaux non essentiels jusqu'après l'interaction.
- Évitez les mises à jour excessives du DOM.- Utiliser des techniques de rendu et d'animation efficaces.
- Réduisez le blocage du thread principal lors du chargement de la page.

L'API **Long Animation Frames (LoAF)** expose des mises à jour de visualisation dépassant 50 ms pour diagnostiquer INP : signale le code coupable par invocateur, type de script et `sourceURL` / position du caractère.

### Changement de mise en page cumulatif (CLS)

**CLS mesure les mouvements inattendus du contenu visible.** Un CLS élevé signifie que les boutons, le texte ou les images se déplacent après leur apparition ; les utilisateurs peuvent perdre leur place ou cliquer sur le mauvais contrôle. [Web](https://web.dev/articles/cls)

Causes courantes : image/vidéo surdimensionnée ; publicité ou bannière placée au-dessus du contenu existant ; les polices à chargement paresseux changent la taille du texte ; notifications dynamiques ; JavaScript qui modifie la mise en page une fois qu'elle devient visible.

| Score CLS | Stabilité visuelle |
|---|---|
| **≤ 0,1** | Bon |
| **> 0,1 – 0,25** | Devrait être amélioré |
| **> 0,25** | Faible |

CLS est un score sans unité, pas une mesure du temps. Il prend en compte à la fois le rapport de fenêtre affecté et la distance de décalage. [docs.newrelic](https://docs.newrelic.com/docs/new-relic-solutions/observability-maturity/digital-experience/l2-cwv-cls/)

#### Améliorer CLS

- Donnez ouvert `width` et `height` aux images et vidéos.
- Allouer de l'espace pour la publicité, l'intégration et le contenu dynamique.
- N'insérez pas de contenu par-dessus du contenu déjà visible.
- Préchargez ou épinglez les polices importantes.
- Préférez `transform` et `opacity` plutôt que les fonctionnalités de mise en page dans les animations.
- Utilisez des espaces réservés avec les mêmes dimensions que le contenu final.
- Si vous utilisez `content-visibility: auto`, réservez de l'espace avec `contain-intrinsic-size` pour éviter le défilement.

### Distinction pratique- **FID :** Le navigateur a-t-il traité la première interaction rapidement ? (historique)
- **INP :** La page répond-elle rapidement aux interactions tout au long de la visite ?
- **CLS :** La page est-elle visuellement stable lorsque les utilisateurs lisent et interagissent ?

Concentrez-vous sur **INP et CLS** dans les rapports actuels Core Web Vitals ; Le FID est surtout utile lors de l’interprétation d’anciens rapports ou de données historiques.

## Au-delà des éléments essentiels du Web

LCP, INP et CLS sont obligatoires ; mais cela n'explique pas tous les problèmes de performances. Les mesures de support diagnostiquent les causes ; Les indicateurs produits et commerciaux montrent si les améliorations techniques fonctionnent réellement pour l’utilisateur.

### Interpréter les métriques et les rapports pris en charge

| Métrique | Qu'est-ce qui aide à expliquer |
|---|---|
| **Première peinture de contenu (FCP)** | La première fois que les utilisateurs voient le contenu d'une page |
| **Délai jusqu'au premier octet (TTFB)** | Latence de réponse du serveur, du réseau et du backend |
| **Temps de blocage total (TBT)** | Blocage du thread principal dans les tests en laboratoire |
| **Indice de vitesse** | À quelle vitesse le contenu visible apparaît-il progressivement |
| **Poids de soudure** | JavaScript, CSS, image, police et taille de charge utile tierce |
| **Missions longues / LoAF** | JavaScript et images clés longues bloquant le fil principal |
| **Taux d'erreur et d'échec** | Si les requêtes, les scripts ou les flux de travail critiques ont échoué |
| **Transformation, abandon et réussite de la mission** | Si les performances affectent les résultats des utilisateurs |

FCP et TTFB sont particulièrement utiles pour diagnostiquer LCP : TTFB peut révéler la latence du serveur, FCP peut révéler un blocage de rendu ou des problèmes de rendu prématurés. Le TBT est essentiellement un **diagnostic de laboratoire** ; Le champ ne remplace pas INP. [Web](https://web.dev/articles/user-centric-performance-metrics)

Lors de l’interprétation de rapports :1. Commencez par les données de terrain ; Recherchez la page, l'appareil, la zone géographique, le navigateur et le segment d'utilisateurs concernés.
2. Regardez le 75e percentile, pas les moyennes.
3. Séparez « ce que les utilisateurs ressentent » de « quelles sont les causes ».
4. Utilisez des outils de laboratoire pour reproduire et isoler la cause.
5. Pas seulement les pages les moins bien notées ; Donnez la priorité aux problèmes affectant les voyages importants.
6. Faites des hypothèses, effectuez un changement ciblé, mesurez à nouveau.
7. Vérifiez que la modification améliore à la fois les performances et un résultat utilisateur, tel que l'achèvement ou la conversion.

Ne considérez pas le score Lighthouse comme la cible. L’objectif n’est pas « 100 » ; Ce sont des expériences plus rapides, plus réactives et plus stables pour les vrais utilisateurs.

### Architectures clients évolutives (bref)

Dans les SPA, la navigation logicielle ne réinitialise pas le LCP et le CLS peut continuer à s'accumuler. L'**API expérimentale Soft Navigations** détecte la navigation logicielle sous l'action de l'utilisateur + le changement d'URL + les conditions de peinture visibles, ouvrant la porte à la mesure du LCP interstitiel dans RUM. Le pré-rendu/prélecture avec l'**API Speculation Rules** peut rapprocher le LCP de zéro (exemple Ray-Ban dans la section de suivi). **sGTM (Server-Side Tag Manager)** réduit le coût du thread principal et du DNS/TLS pour obtenir une pondération des balises tierces du navigateur, directement reflétée dans INP et LCP.

## Outils de laboratoire

### Phare : audit de performance

Lighthouse propose des audits automatisés pour les performances, l'accessibilité, le référencement, les meilleures pratiques et les fonctionnalités PWA. Le rapport de performances comprend des mesures, des contrôles de diagnostic, des opportunités et des liens d'amélioration suggérés. [developer.chrome](https://developer.chrome.com/docs/devtools/lighthouse)

Utilisez Lighthouse pour :

- Pull-request ou contrôles de construction.
- Comparaisons de base reproductibles.
- Détection des sources de blocage de rendu.- Recherche d'images trop volumineuses et de JavaScript inutilisé.
- Recherche de LCP, CLS, FCP, TBT et des métriques de laboratoire associées.
- Tester les pages avec un trafic de site faible ou nul.

Exécutez avec des conditions cohérentes : même URL, émulation de périphérique, profil réseau, état d'authentification et répétitions. Considérez les courses simples comme étant bruyantes ; regardez les médianes ou les tendances. Dans Lighthouse CI, `numberOfRuns` (par exemple 3-5) et les assertions basées sur des métriques créent des portes plus fiables basées sur le bruit de score.

### Panneau de performances de Chrome DevTools : diagnostics approfondis et assistance IA

Le panneau Performances enregistre une trace du navigateur qui inclut l'activité réseau, le travail du processeur, l'exécution JavaScript, le rendu, la mise en page, la peinture et les interactions utilisateur. Lighthouse est l'outil à utiliser lorsque vous trouvez un symptôme mais que vous devez trouver l'activité bloquante exacte. [developer.chrome](https://developer.chrome.com/docs/devtools/performance/overview)

Flux de travail pratique :

- Enregistrez le chargement de la page ou une interaction lente.
- Recherchez les phases LCP, les demandes de blocage de rendu, les contrevenants aux changements de disposition et les tâches longues dans la vue **Insights**.
- Recherchez le script, le recalcul de style, la mise en page ou la peinture responsable de la chronologie principale et du flame chart.
- Associez la trace au panneau Réseau et à l'élément DOM concerné.
-Réenregistrer après correction.

Chrome DevTools propose également une assistance IA pour les profils de performances enregistrés. Peut expliquer des informations sélectionnées ou suivre des activités et suggérer des améliorations possibles ; Utilisez-le comme aide à l'analyse, en vérifiant chaque suggestion par rapport à votre trace et à votre code. [developer.chrome](https://developer.chrome.com/docs/devtools/ai-assistance/performance) Les registres LoAF réduisent le goulot d'étranglement INP jusqu'à la fonction et l'emplacement des ressources.

### WebPageTest : tests réalistes et analyses avancéesWebPageTest est utile pour des tests réalistes et avancés sur des emplacements, des navigateurs, des appareils, des profils de connexion et des exécutions répétées. **Filmstrip** ce que les utilisateurs voient au fil du temps ; **cascade** affiche les dépendances des demandes, la planification, la priorité et les latences des ressources. [performance.shopify](https://performance.shopify.com/blogs/blog/how-to-test-with-webpagetest)

Utilisez-le lors de vos recherches :

- Performances lentes de certains pays ou régions.
- Appareil mobile et comportement lent du réseau.
- Répéter la comparution avec la première comparution.
- CDN, DNS, TLS, planification des serveurs et des connexions.
- Découverte visuelle et priorisation des demandes.
- Scripts tiers et goulots d'étranglement en cascade.
- Progression visuelle, pas seulement le score final.
- Simulation SPOF tierce (si le chemin critique est bloqué ou non lorsque le serveur de balises tombe en panne).

## Outils de terrain

### Capture CWV sur le terrain avec `web-vitals.js`

La bibliothèque `web-vitals` mesure les Core Web Vitals dans le navigateur et envoie les résultats à votre système d'analyse ou d'observabilité. Une application minimale :```html
<script type="module">
  import {onCLS, onINP, onLCP}
    from 'https://unpkg.com/web-vitals@4?module';

  function sendToAnalytics(metric) {
    navigator.sendBeacon('/rum', JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      path: location.pathname
    }));
  }

  onCLS(sendToAnalytics);
  onINP(sendToAnalytics);
  onLCP(sendToAnalytics);
</script>
```La bibliothèque officielle fournit également une version **attribution** : l'élément ou la ressource LCP ajoute un contexte de débogage pour INP, tel que `inputDelay` / `processingDuration` / `presentationDelay`, `interactionTarget` et les enregistrements LoAF. Il donne les coordonnées criminelles au lieu du score. [developers.google](https://developers.google.com/codelabs/chrome-web-vitals-js)

Ajoutez des dimensions respectueuses de la confidentialité dans Production : modèle de page et itinéraire ; classe d'appareil et type de connexion ; navigateur et système d'exploitation ; pays ou région ; version; connecté/anonyme ; expérience ou indicateur de fonctionnalité.

Ne soumettez pas d’URL, d’identifiant d’utilisateur, de contenu de formulaire ou d’autres données personnelles à moins que votre conception de confidentialité ne le permette expressément.

### CrUX et données externes

**Le rapport sur l'expérience utilisateur Chrome (CrUX)** représente l'expérience de vrais utilisateurs Chrome éligibles sur des sites populaires. Fournit des données de champ pour LCP, INP, CLS et d'autres dimensions via PageSpeed ​​​​​​Insights, Search Console, l'API CrUX et BigQuery. [developer.chrome](https://developer.chrome.com/docs/crux)

CrUX est précieux pour : l'analyse comparative avec le Web public ; vérifier si les problèmes de performances affectent les utilisateurs réels ; vérifier si une version modifie les performances sur le terrain ; comparaison mobile-ordinateur de bureau ; tendances historiques.

CrUX a des limites de couverture et de disponibilité ; Il se peut qu'il ne représente pas chaque utilisateur ou chaque page. La moyenne mobile sur 28 jours ne montre pas l'impact de la distribution d'hier. Utilisez-le avec du RUM propriétaire pour obtenir une audience exacte et des dimensions spécifiques au produit.

### Au-delà des Web Vitals RUM

La surveillance réelle des utilisateurs doit également capturer :

- Changement d'itinéraire ou timing de navigation SPA (peut être amélioré avec Soft Navigations).
- Latence de l'API et requêtes échouées.- Erreurs JavaScript et rejet de promesse.
- Missions longues et images clés longues (LoAF).
- Délai d'interaction par fonctionnalité.
- Recherche, paiement, connexion ou finalisation du téléchargement.
- Rage cliquez, réessayez et abandonnez.
- Crashes, états hors ligne et changements de connexion.
- Les échecs d'accessibilité lorsqu'ils sont mesurables.

La question utile n’est pas simplement « L’INP est-il mauvais ? » n'est pas ; « Quelle interaction est lente, pour quels utilisateurs, sur quelle version, et est-ce que cela entrave l'achèvement des tâches ? »

Les scripts marketing/analyse tiers peuvent paradoxalement briser l'INP/LCP lorsqu'ils sont ajoutés à des fins de mesure. **sGTM** regroupe des dizaines de scripts du navigateur en un seul flux propriétaire ; Il déplace le coût de l'exécution JS, DNS et SSL vers le cloud, afin que la mesure elle-même n'empoisonne pas les performances.

## Budgets, alertes et suivi continu

Les budgets de performance traduisent les objectifs de qualité en limites applicables. Définissez des budgets pour les métriques et les raisons des utilisateurs :

- LCP : 75e percentile ≤ 2,5 secondes.
- INP : 75e centile ≤ 200 millisecondes.
- CLS : 75ème percentile ≤ 0,1.
- Transfert JavaScript : maximum convenu par itinéraire.
- Poids total des pages : maximum par classe d'appareil.
- Demandes de tiers : liste approuvée et coût maximum.
- Taux d'erreur : pourcentage maximum acceptable.
- Succès critique du flux de travail : taux d'achèvement minimum.

Utilisez trois niveaux d'alerte :

- **Avertissement :** approche de la limite métrique.
- **Régression :** la mesure s'est aggravée en dépassant le pourcentage convenu.
- **Critique :** un workflow Core Web Vital ou critique a dépassé le seuil d'échec.

Exemple d'assertions Lighthouse CI : préférez les portes basées sur des métriques plutôt que sur le score :```json
{
  "ci": {
    "collect": {
      "url": ["http://localhost:3000/", "http://localhost:3000/blog"],
      "numberOfRuns": 3,
      "settings": { "preset": "desktop" }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
      }
    }
  }
}
```### Exemple de surveillance continue

Un système pratique pourrait fonctionner comme ceci :

1. Lighthouse s'exécute sur un ensemble représentatif de pages dans chaque version.
2. WebPageTest s'exécute la nuit à partir de plusieurs emplacements et profils de connexion.
3. `web-vitals.js` (attribution si possible) envoie des LCP, INP et CLS anonymisés depuis la production.
4. Le tableau de bord répartit les résultats par version, itinéraire, appareil et zone géographique.
5. L'alerte est déclenchée lorsque l'INP mobile se détériore de 15 % sur deux périodes consécutives.
6. L'équipe surveille l'interaction affectée avec DevTools + LoAF.
7. Après avoir raccourci une longue tâche JavaScript, les données de trace et de champ sont validées.
8. Le changement n'est conservé que si les performances s'améliorent et si la réalisation/conversion des tâches ne diminue pas.

Cela crée une boucle de rétroaction : **Lighthouse détecte, DevTools diagnostique, WebPageTest stress tests, RUM vérifie, les budgets empêchent la régression**.

### Surveillance continue dans la pratique (brèves notes de cas)

- **Taboola :** TBT/INP élevés sur les sites des éditeurs ; Marquage des goulots d'étranglement avec LoAF, réduction d'échelle tierce et refonte du moteur de rendu.
- **Photocasa :** Vert pendant la période FID ; « Besoin d'amélioration/faible » dans la Search Console après l'INP de mars 2024. Les ralentissements cachés des clients dans les interactions entre la galerie, la carte et les filtres ont été résolus avec RUM.
- **Ray-Ban :** Pré-rendu des pages produits avec des règles de spéculation ; Baisse de LCP d'environ 43 % (moins de 1 s) et conversion PDP sur mobile d'environ 101 % / ordinateur de bureau, augmentation d'environ 156 % signalée.
- **T-Mobile :** Diminution de la conversion et augmentation du rebond pour chaque délai de 100 ms lorsque le LCP dépasse 2 secondes ; Ils ont transformé la vitesse en KPI et ont augmenté la conversion des visites en commandes d'environ 60 %.

La mesure ne sert pas à peindre la planche en vert ; est de rendre la mission possible lors de voyages réels.

## Appariements les plus fréquemment confondus```text
❌ FID hâlâ güncel bir Core Web Vital’dır
✓ FID Mart 2024’te emekli oldu; odak INP’dedir (ziyaret boyunca yanıt)

❌ Yeşil Lighthouse skoru saha CWV’nin iyi olduğu anlamına gelir
✓ Lab teşhis eder; CrUX/RUM gerçek kullanıcı deneyimini doğrular

❌ Ortalama LCP “yeterince iyi”yi temsil eder
✓ 75. yüzdeliği mobil ve masaüstü ayrı izleyin

❌ TBT, INP’nin yerine geçer
✓ TBT lab teşhisidir; saha yanıtı için INP kullanın

❌ web-vitals skoru tek başına kök nedeni gösterir
✓ Attribution + LoAF etkileşim hedefi ve suçlu betiği gösterir

❌ CrUX dünkü deploy’u yansıtır
✓ CrUX ~28 günlük ortalamadır; anlık regresyon için birinci taraf RUM şarttır

Checklist : mesurer ce qui doit être mesuré

1. Choisissez une étoile du Nord + une métrique chacune parmi le comportement, la perception, la rétention et la technique/fiabilité.
2. Définir des scénarios de laboratoire et des dimensions de terrain (appareil, réseau, géographie, itinéraire) pour les parcours critiques.
3. Corrigez les seuils « bons » p75 pour LCP, INP et CLS séparément sur mobile/ordinateur de bureau.
4. Divisez le LCP en quatre délais (TTFB, découverte, téléchargement, rendu) ; Divisez INP en trois phases.
5. Exécutez Lighthouse CI + WebPageTest sur des URL représentatives ; Lire la médiane/tendance.
6. Installez RUM en production avec web-vitals (attribution préférée) + dimensions respectueuses de la confidentialité.
7. Utilisez CrUX pour l'analyse comparative ; Fiez-vous à RUM pour la régression et le diagnostic des fonctionnalités.
8. Définir le budget et trois niveaux d'alerte (alerte / régression / critique) ; Valider l’amélioration par la réussite ou la transformation d’une tâche.

Si vous ne pouvez pas répondre à ces huit questions, vous êtes toujours en train de « regarder le score » ; Vous n'effectuez pas encore de mesures orientées utilisateur.

Points saillants de cet épisode

1. La mesure centrée sur l'utilisateur combine le comportement, la perception, la rétention et les performances techniques, et pas seulement le trafic ou les résultats de laboratoire.
2. Le laboratoire explique la capacité et la raison ; le terrain valide les performances du monde réel ; Les deux forment un cycle.
3. Les Core Web Vitals actuels sont LCP, INP et CLS ; Le FID est historique. Seuils à p75 : LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1.
4. LCP est divisé en quatre retards, INP en trois phases ; LoAF et l'attribution attribuent la cause première aux coordonnées plutôt qu'au score.
5. Des outils architecturaux tels que les navigations douces, les règles de spéculation et sGTM aident à combler les angles morts des mesures et la pondération tierce.
6. Les budgets, les alertes et le suivi continu rendent l'amélioration permanente ; Taboola, Fotocasa, Ray-Ban et T-Mobile montrent que la mesure est liée aux résultats commerciaux.

Le but n'est pas de rendre le tableau vert. L'objectif est de savoir (et de concevoir consciemment) si les utilisateurs peuvent effectuer des tâches importantes de manière rapide, fiable et satisfaisante.

Suivant : Nous transformerons les Core Web Vitals de « mesures intéressantes » en exigences de produits, budgets et portes de publication.