Aller au contenu principal

Monitoring Utilisateur Réel — Core Web Vitals

Open in QuickMonitoring→ Sites → [Votre site] → RUM

Le monitoring utilisateur réel (RUM) capture les Core Web Vitals réels (LCP, FID/INP, CLS) depuis de vraies sessions navigateur — pas des tests de laboratoire synthétiques. Visualisez les performances telles que vos utilisateurs les vivent réellement.

Ce que vous verrez​

L'onglet RUM présente les métriques de performance collectées directement depuis les navigateurs de vos visiteurs :

Résumé des Core Web Vitals​

Trois métriques principales s'affichent avec leur valeur médiane, leur percentile 75 (p75) et leur percentile 95 (p95), accompagnées d'un code couleur indiquant leur niveau de performance :

MétriqueBonneÀ améliorerMauvaise
LCP (Largest Contentful Paint)≤ 2,5 s2,5–4,0 s> 4,0 s
INP (Interaction to Next Paint)≤ 200 ms200–500 ms> 500 ms
CLS (Cumulative Layout Shift)≤ 0,10,1–0,25> 0,25

Le score global Core Web Vitals indique la proportion de sessions ayant obtenu une valeur « Bonne » pour les trois métriques simultanément.

Métriques supplémentaires​

Au-delà des Core Web Vitals, le tableau de bord RUM affiche :

  • FCP (First Contentful Paint) — temps jusqu'au premier élément affiché
  • TTFB (Time to First Byte) — temps de réponse du serveur
  • FID (First Input Delay) — délai avant la première interaction (maintenu pour compatibilité historique)
  • Durée de session — temps total passé sur le site par session
  • Taux d'erreur JS — pourcentage de sessions ayant rencontré une erreur JavaScript

Distribution des performances​

Un histogramme montre la distribution des valeurs LCP sur l'ensemble des sessions — utile pour repérer une bimodalité (ex. : deux groupes d'utilisateurs avec des expériences très différentes selon leur connexion ou appareil).

Analyse par page​

Un tableau liste les pages de votre site avec leurs métriques RUM individuelles. Triez par LCP ou CLS décroissant pour identifier les pages les plus problématiques.

Analyse par dimension​

Des onglets permettent de décomposer les métriques par :

  • Appareil (bureau, tablette, mobile)
  • Navigateur (Chrome, Firefox, Safari, Edge)
  • Pays
  • Type de connexion (4G, WiFi, fibre)

Comment l'utiliser​

Activation du RUM​

Le RUM est activé automatiquement dès l'installation du SDK — aucune configuration supplémentaire n'est nécessaire. Le SDK utilise l'API PerformanceObserver du navigateur pour capturer les métriques nativement.

Pour les environnements où vous souhaitez désactiver le RUM (ex. : environnement de développement) :

QMTracker.init({
  siteId: 'YOUR_SITE_ID',
  rum: false
});

Diagnostiquer un LCP élevé​

  1. Accédez à RUM → Analyse par page et triez par LCP décroissant.
  2. Identifiez la page la plus problématique.
  3. Cliquez sur la page pour voir la distribution des LCP par appareil et navigateur.
  4. Vérifiez l'onglet Scans pour cette page — un scan récent indiquera l'élément LCP et ses caractéristiques (image non optimisée, ressource bloquante, etc.).

Causes fréquentes d'un LCP élevé :

  • Images hero non optimisées (format JPEG au lieu de WebP/AVIF, taille excessive)
  • Absence de directive preload pour les images critiques
  • Serveur lent (TTFB > 600 ms)
  • Ressources JavaScript bloquant le rendu

Diagnostiquer un CLS élevé​

Un CLS élevé signifie que des éléments de la page bougent pendant le chargement, perturbant l'expérience utilisateur.

  1. Filtrez les sessions avec CLS > 0,1 dans le tableau RUM.
  2. Consultez les enregistrements de session correspondants pour visualiser les sauts de layout.
  3. Causes fréquentes :
    • Images ou vidéos sans attributs width et height définis
    • Publicités, embeds ou iframes sans dimensions réservées
    • Polices web qui remplacent une police système avec des métriques différentes
    • Contenu injecté dynamiquement au-dessus du contenu existant

Diagnostiquer un INP élevé​

L'INP mesure la réactivité aux interactions utilisateur (clics, frappes clavier, taps).

  1. Identifiez les pages avec un INP > 200 ms.
  2. Les causes habituelles sont un thread principal surchargé par du JavaScript lourd.
  3. Solutions : code splitting, lazy loading des scripts non critiques, optimisation des handlers d'événements.

Configurer des alertes de performance​

Dans Paramètres → Alertes, créez une alerte RUM :

  • Métrique : LCP p75
  • Condition : supérieur à 3 secondes
  • Notification : email immédiat

Cela vous avertit automatiquement si une mise à jour dégrade les performances de production.

Condition de validation​

Cet achievement est débloqué lorsque : au moins 25 sessions avec des métriques Core Web Vitals ont été collectées, et les résultats s'affichent dans l'onglet RUM de votre site.

Problèmes courants​

Les métriques RUM sont absentes ou partielles Les Core Web Vitals ne sont rapportés que par les navigateurs modernes supportant l'API PerformanceObserver (Chrome 77+, Edge 79+, Firefox 89+). Safari ne rapporte pas encore le CLS et l'INP nativement. Les métriques manquantes pour certains navigateurs sont normales.

Le LCP affiché est très différent des outils Lighthouse C'est attendu — Lighthouse mesure dans des conditions de laboratoire contrôlées (connexion simulée, pas de cache), tandis que le RUM reflète la diversité réelle des connexions, appareils et conditions de cache de vos utilisateurs. Le RUM est plus représentatif de l'expérience réelle.

Le CLS est à 0 pour toutes les sessions Si le CLS est systématiquement à zéro, c'est souvent un bon signe ! Vérifiez cependant que le SDK est bien chargé avant les autres ressources de la page. Un SDK chargé très tard pourrait manquer les shifts de layout initiaux.

Peu de données sur mobile Si votre site reçoit peu de trafic mobile, les percentiles p75 et p95 peuvent être peu fiables. Augmentez la période d'analyse pour accumuler un volume statistiquement significatif (recommandé : minimum 100 sessions par segment pour des métriques fiables).