Real User Monitoring (RUM) : définition et exemples

Qu'est-ce que le Real User Monitoring (RUM) ?

Le Real User Monitoring (RUM, surveillance des utilisateurs réels) mesure les performances de votre site pour les personnes qui l'utilisent vraiment. Un petit script dans la page enregistre, dans le navigateur de chaque visiteur, les temps de chargement, les délais d'interaction, les décalages de mise en page et les erreurs, puis les envoie à un backend. Vous obtenez des données de terrain issues d'appareils, de réseaux et de pays réels, pas d'un test scripté.

Comment fonctionne le RUM

Le script s'appuie sur des API standard du navigateur comme PerformanceObserver, collecte les métriques pendant le chargement et l'usage de la page, puis les envoie par lots. Le moment fiable pour envoyer est celui où la page devient masquée, car les anciens événements unload ne se déclenchent souvent jamais sur mobile. navigator.sendBeacon() existe pour cela : il met en file un petit POST qui ne retarde pas le départ de la page (référence MDN, en anglais).

new PerformanceObserver((list) => {  for (const entry of list.getEntries()) {    send({ metric: 'lcp', value: entry.startTime });  }}).observe({ type: 'largest-contentful-paint', buffered: true });document.addEventListener('visibilitychange', () => {  if (document.visibilityState === 'hidden') {    navigator.sendBeacon('/rum', JSON.stringify(queue));  }});

Côté backend, chaque beacon est étiqueté avec un contexte comme le navigateur, l'appareil, le pays et la page, puis agrégé en percentiles que vous pouvez segmenter.

Ce que mesure le RUM

• Chargement : time to first byte, First Contentful Paint et Largest Contentful Paint.
• Réactivité : Interaction to Next Paint et tâches longues.
• Stabilité visuelle : Cumulative Layout Shift.
• Erreurs : exceptions JavaScript, requêtes échouées et promesses rejetées non gérées.
• Contexte : navigateur, système d'exploitation, type d'appareil, type de connexion, pays et version de release.
• Événements métier : inscription terminée, paiement démarré, pour relier la vitesse aux résultats.

Les trois plus importantes pour la recherche et l'expérience utilisateur sont les Core Web Vitals. La recommandation de Google (web.dev, en anglais) : LCP en 2,5 secondes ou moins, INP de 200 millisecondes ou moins et CLS de 0,1 ou moins, évalués au 75e percentile des chargements de page, segmentés mobile et ordinateur.

RUM et monitoring synthétique

Utilisez les deux. Les contrôles synthétiques signalent qu'un élément est tombé à 3 heures du matin et donnent des chiffres comparables d'une exécution à l'autre. Le RUM dit qui est touché et si un correctif a aidé. L'article monitoring synthétique ou real user monitoring (en anglais) approfondit le choix.

Exemple : un paiement lent sur mobile

Des tests synthétiques sur une machine de bureau montrent que la page de paiement se charge bien. Le RUM, segmenté par appareil, montre un LCP au 75e percentile bien au-dessus de l'objectif de 2,5 secondes sur des téléphones Android milieu de gamme, concentré dans un pays. La cause est une image principale trop lourde. Après le correctif, la même vue RUM confirme que le percentile a bougé, ce qu'un test en laboratoire seul ne pourrait pas prouver.

Erreurs courantes avec le RUM

• Lire des moyennes. Les moyennes cachent la queue lente. Suivez p75 et p95.
• Ne pas segmenter. Mobile et ordinateur, connexions rapides et lentes se comportent très différemment, et un chiffre mélangé cache les deux.
• Collecter des données personnelles. Gardez les URL exemptes de tokens et d'e-mails, évitez les identifiants inutiles et respectez vos obligations de confidentialité. Vérifiez les exigences de consentement auprès de votre propre conseil juridique.
• Alerter à chaque pic. Alertez sur des régressions durables d'un percentile, pas sur des sessions isolées.
• Oublier les applications monopages. Les changements de route ne rechargent pas la page : ils exigent des marqueurs de vue de page explicites.
• Attendre du RUM qu'il détecte les pannes. Pas de visiteurs, pas de signal. Associez-le à des contrôles planifiés.

RUM, CrUX et LoadFocus

Le Chrome UX Report (CrUX) regroupe des données RUM publiques d'utilisateurs de Chrome ayant donné leur accord, agrégées par origine. Il sert à voir comment Google perçoit votre site et à comparer des origines. Votre propre RUM couvre tous les navigateurs et porte vos dimensions, ce qui le rend meilleur pour le débogage. LoadFocus n'exécute pas de script RUM. Le monitoring de vitesse de page apporte l'autre moitié : des audits Lighthouse depuis 25 régions cloud selon un planning, plus des données de terrain CrUX avec un badge Core Web Vitals réussi ou échoué. Pour les contrôles de disponibilité et de temps de réponse de votre backend, voir le monitoring d'API. Le RUM est le côté navigateur de la surveillance des performances applicatives.

Questions fréquentes : Real User Monitoring

Le RUM est-il la même chose que l'APM ?

Non. L'APM surveille le backend : serveurs, services et appels de base de données. Le RUM surveille le frontend dans le navigateur du visiteur. Ensemble, ils donnent une vue complète d'une requête du clic à la réponse.

Le RUM ralentit-il mon site ?

Un peu, s'il est mal fait. Chargez le script de façon asynchrone, gardez-le léger et envoyez les données avec sendBeacon pour qu'il ne bloque jamais la page. Mesurez le coût du script lui-même avant de le déployer.

Quelle est la différence entre RUM et CrUX ?

CrUX est un jeu de données public sur l'expérience des utilisateurs de Chrome, agrégé par origine et groupe de pages. Le RUM, c'est vous qui le collectez : tous les navigateurs, vos propres sessions et des dimensions personnalisées comme la release ou la variante d'une expérience.

Puis-je faire du RUM sans fournisseur ?

Oui. La bibliothèque open source web-vitals de Google remonte les Core Web Vitals dans le navigateur, et vous les envoyez à votre propre endpoint avec sendBeacon. Vous devez ensuite les stocker, les agréger et les afficher vous-même.

Le RUM est-il autorisé par le RGPD ?

Cela dépend de ce que vous collectez et de la manière. Les mesures de performance sont bien moins sensibles que les enregistrements de session ou les identifiants d'utilisateur. Anonymisez ce que vous pouvez, gardez les identifiants hors des URL, documentez-le dans votre politique de confidentialité et demandez à votre conseil juridique si un consentement est nécessaire.