Real User Monitoring (RUM): definición y ejemplos

¿Qué es Real User Monitoring (RUM)?

Real User Monitoring (RUM, monitorización de usuarios reales) mide cómo rinde tu sitio para las personas que realmente lo usan. Un pequeño script en la página registra en el navegador de cada visitante los tiempos de carga, los retrasos de interacción, los cambios de diseño y los errores, y los envía a un backend. El resultado son datos de campo de dispositivos, redes y países reales, no de una prueba con guion.

Cómo funciona RUM

El script usa APIs estándar del navegador como PerformanceObserver, recoge métricas mientras la página carga y se usa, y las envía en lotes. El momento fiable para enviar es cuando la página pasa a estar oculta, porque los eventos unload más antiguos a menudo no se disparan en móvil. Para eso existe navigator.sendBeacon(): encola un POST pequeño que no retrasa la salida de la página (referencia de MDN, en inglés).

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));  }});

En el backend, cada beacon se etiqueta con contexto como navegador, dispositivo, país y página, y se agrega en percentiles que puedes segmentar.

Qué mide RUM

• Carga: time to first byte, First Contentful Paint y Largest Contentful Paint.
• Capacidad de respuesta: Interaction to Next Paint y tareas largas.
• Estabilidad visual: Cumulative Layout Shift.
• Errores: excepciones de JavaScript, peticiones fallidas y promesas rechazadas sin gestionar.
• Contexto: navegador, sistema operativo, tipo de dispositivo, tipo de conexión, país y versión de release.
• Eventos de negocio: registro completado, pago iniciado, para relacionar la velocidad con los resultados.

Las tres más importantes para búsqueda y experiencia de usuario son las Core Web Vitals. La guía de Google (web.dev, en inglés) es LCP dentro de 2,5 segundos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, evaluados en el percentil 75 de las cargas de página, segmentadas por móvil y escritorio.

RUM frente a monitorización sintética

Usa ambas. Las comprobaciones sintéticas te avisan de que algo se rompió a las 3 de la madrugada y dan cifras comparables de una ejecución a otra. RUM te dice a quién afecta y si una corrección ayudó. El artículo monitorización sintética frente a real user monitoring (en inglés) profundiza en cómo elegir.

Ejemplo: un checkout lento en móvil

Las pruebas sintéticas en un equipo de escritorio muestran que la página de pago carga bien. RUM, segmentado por dispositivo, muestra un LCP en el percentil 75 muy por encima del objetivo de 2,5 segundos en móviles Android de gama media, concentrado en un país. La causa resulta ser una imagen principal demasiado grande. Tras la corrección, la misma vista de RUM confirma que el percentil se movió, algo que una prueba de laboratorio por sí sola no podría demostrar.

Errores comunes con RUM

• Leer promedios. Los promedios esconden la cola lenta. Sigue p75 y p95.
• No segmentar. Móvil y escritorio, conexiones rápidas y lentas se comportan de forma muy distinta, y un número mezclado oculta ambas.
• Recoger datos personales. Mantén las URLs libres de tokens y correos, evita identificadores innecesarios y cumple tus obligaciones de privacidad. Consulta los requisitos de consentimiento con tu propio asesor legal.
• Alertar por cada pico. Alerta ante regresiones sostenidas de un percentil, no ante sesiones sueltas.
• Olvidar las aplicaciones de una sola página. Los cambios de ruta no recargan la página, así que necesitan marcadores explícitos de vista de página.
• Esperar que RUM detecte caídas. Sin visitantes no hay señal. Combínalo con comprobaciones programadas.

RUM, CrUX y LoadFocus

El Chrome UX Report (CrUX) son datos RUM públicos de usuarios de Chrome que han dado su consentimiento, agregados por origen. Sirve para ver cómo ve Google tu sitio y para comparar orígenes. Tu propio RUM cubre todos los navegadores y lleva tus propias dimensiones, lo que lo hace mejor para depurar. LoadFocus no ejecuta un script de RUM. La monitorización de velocidad de página te da la otra mitad: auditorías de Lighthouse desde 25 regiones cloud con programación, más datos de campo de CrUX con una insignia de Core Web Vitals de aprobado o suspenso. Para comprobar disponibilidad y tiempos de respuesta de tu backend, mira la monitorización de APIs. RUM es el lado del navegador de la monitorización del rendimiento de aplicaciones.

Preguntas frecuentes: Real User Monitoring

¿RUM es lo mismo que APM?

No. APM vigila el backend: servidores, servicios y llamadas a bases de datos. RUM vigila el frontend en el navegador del visitante. Juntos dan una imagen completa de una petición desde el clic hasta la respuesta.

¿RUM ralentiza mi sitio?

Un poco, si se hace mal. Carga el script de forma asíncrona, mantenlo pequeño y envía los datos con sendBeacon para que nunca bloquee la página. Mide el coste del propio script antes de desplegarlo.

¿Qué diferencia hay entre RUM y CrUX?

CrUX es un conjunto de datos público sobre la experiencia de usuarios de Chrome, agregado por origen y grupo de páginas. RUM lo recoges tú: todos los navegadores, tus propias sesiones y dimensiones propias como la release o la variante de un experimento.

¿Puedo hacer RUM sin proveedor?

Sí. La librería de código abierto web-vitals de Google informa de las Core Web Vitals en el navegador, y tú las envías a tu propio endpoint con sendBeacon. Después tendrás que almacenarlas, agregarlas y graficarlas tú mismo.

¿Se permite RUM bajo el RGPD?

Depende de qué recojas y cómo. Los tiempos de rendimiento son mucho menos sensibles que las grabaciones de sesión o los identificadores de usuario. Anonimiza lo que puedas, mantén los identificadores fuera de las URLs, documéntalo en tu política de privacidad y pregunta a tu asesor legal si necesitas consentimiento.