La monitorización sintética prueba tu web o tu API con peticiones programadas según un calendario, haya o no alguien visitándola. La monitorización de usuarios reales (RUM) mide lo que experimentan los visitantes reales, mediante un script en su navegador, pero solo cuando visitan la web. Las comprobaciones sintéticas te dicen que algo se ha roto, a menudo antes de que lo noten los clientes. RUM te dice lo rápida y fluida que es la web para quienes la usan, en sus dispositivos y sus redes. Empieza con comprobaciones sintéticas para la disponibilidad y añade RUM cuando el rendimiento para los visitantes reales se convierta en una pregunta que necesitas responder.
Cómo funciona la monitorización sintética
Un servicio de monitorización hace de visitante. Desde una ubicación conocida y con una frecuencia fija, envía una petición o ejecuta un script y evalúa el resultado. Como hace lo mismo cada vez, los resultados se pueden comparar de una comprobación a otra, y un fallo a las 03:00 se detecta a las 03:00, sin necesidad de tráfico. La monitorización sintética adopta varias formas:
Comprobaciones de disponibilidad: una petición a una URL, un host o un puerto, en la que se comprueban el código de estado, el tiempo de respuesta y a menudo el contenido. Es el tipo más sencillo; consulta qué es la monitorización de disponibilidad.
Comprobaciones de API: una petición con método, cabeceras y cuerpo, y comprobaciones sobre el JSON que se recibe.
Flujos de varios pasos: un recorrido como iniciar sesión o completar una compra, ejecutado paso a paso, como peticiones HTTP simples o en un navegador real que ejecuta JavaScript.
Pruebas de rendimiento de laboratorio: una herramienta como Lighthouse carga una página en un dispositivo y una red simulados y le da una puntuación.
Cómo funciona la monitorización de usuarios reales
La monitorización de usuarios reales añade un script a tus páginas. En el navegador de cada visitante lee los tiempos que los navegadores exponen mediante API estándar, como Navigation Timing, y los envía a un recopilador. Agregando las visitas, obtienes distribuciones: cuánto tardan en cargar las páginas, lo rápido que responden a los clics, qué páginas lanzan errores de JavaScript, desglosado por país, dispositivo y navegador.
Como los resultados son distribuciones, RUM informa de percentiles en lugar de cifras sueltas. Las Core Web Vitals de Google se miden en el percentil 75 de las cargas de página, con estos umbrales para una buena experiencia:
Largest Contentful Paint (carga): 2,5 segundos o menos.
Interaction to Next Paint (capacidad de respuesta): 200 milisegundos o menos.
Cumulative Layout Shift (estabilidad visual): 0,1 o menos.
También hay datos RUM que no recopilas tú. El Chrome UX Report (CrUX) de Google publica datos de campo de los usuarios de Chrome que lo permiten, por página y por sitio, cuando hay suficiente tráfico. Son los datos que Google usa para las Core Web Vitals en la búsqueda.
Cara a cara
Monitorización sintéticaMonitorización de usuarios realesQuién genera los datosUn servicio de monitorización, según un calendarioTus visitantes, cuando visitan la webNecesita tráficoNoSíNecesita un script en tus páginasNoSíDetecta una caídaSí, en la siguiente comprobaciónIndirectamente, cuando dejan de llegar datosCubreLas páginas y recorridos que programasTodas las páginas que visita la genteDispositivos y redesUnos pocos conocidosLos de todos tus visitantesResultadosCorrecto o fallido, un tiempo por comprobaciónDistribuciones y percentilesIdeal paraDisponibilidad, alertas, detectar regresiones tras los desplieguesRendimiento real, Core Web Vitals, errores en el navegador
Qué se le escapa a cada una
Puntos ciegos de la monitorización sintética
Los recorridos que no programaste. Si el flujo de compra prueba un producto, una página rota de otra categoría pasa desapercibida.
Dónde están tus visitantes. Una comprobación desde una ciudad ve la ruta de esa ciudad hasta tu servidor, no la de un visitante con una red móvil en otro continente.
Los dispositivos reales. Un móvil lento, una extensión del navegador o una versión antigua del navegador pueden romper o ralentizar una página que pasa todas las comprobaciones.
Puntos ciegos de RUM
Sin visitantes no hay datos. De noche, en una página nueva o en una web con poco tráfico, RUM tiene poco o nada que decir.
Las caídas. Cuando la web está caída, el script no llega a cargarse, así que no se informa de nada. Un hueco en un gráfico es fácil de pasar por alto y no despierta a nadie.
Los visitantes que no puedes medir. Los bloqueadores de anuncios y las preferencias de consentimiento pueden impedir que se ejecute el script, así que los datos describen a los visitantes que lo permiten.
El peso. El propio script supone trabajo extra para la página. Cárgalo de forma asíncrona y revisa su tamaño.
Datos de laboratorio frente a datos de campo
La misma división aparece en las herramientas de rendimiento, donde se habla de datos de laboratorio y datos de campo. Una puntuación de Lighthouse son datos de laboratorio: una carga de página sintética en un móvil y una red de gama media simulados. CrUX y tu propio RUM son datos de campo: lo que midieron las visitas reales. A menudo no coinciden. Una página puede puntuar mal en el laboratorio y aun así aprobar las Core Web Vitals en el campo porque la mayoría de los visitantes tienen dispositivos rápidos, o al revés. Usa los datos de laboratorio para encontrar y corregir problemas y para comparar una versión con la siguiente, y los datos de campo para valorar lo que reciben realmente los visitantes. Los consejos para que tu web cargue más rápido ayudan con ambos, y qué es un buen tiempo de respuesta trata la parte del servidor.
Por cuál empezar
Cualquier web: comprobaciones sintéticas de disponibilidad en la página de inicio y en las páginas que generan ingresos. Una caída cuesta más que una página lenta, y solo las comprobaciones sintéticas te avisan de forma fiable. La lista de qué monitorizar recoge las URL que conviene cubrir.
Tiendas y productos SaaS: añade flujos de varios pasos para el checkout o el inicio de sesión, para detectar un recorrido roto aunque todas las páginas respondan 200.
Webs en las que importa el tráfico de búsqueda: vigila las Core Web Vitals de CrUX y una prueba de laboratorio diaria, para detectar una versión lenta antes de que se note en el posicionamiento.
Audiencias grandes o globales y front ends complejos: añade RUM para ver el rendimiento y los errores de JavaScript por país, dispositivo y página.
Cómo se complementan
Imagina una tienda que despliega un nuevo checkout el martes por la tarde. El miércoles a las 03:12, el paso de pago empieza a agotar el tiempo de espera. Nadie está comprando, así que RUM no muestra nada raro, pero el flujo sintético de compra falla, una segunda comprobación lo confirma y el desarrollador de guardia recibe una alerta. A las 03:30 está arreglado. El jueves, RUM muestra que el Interaction to Next Paint del nuevo checkout se ha duplicado para los visitantes con Android, algo que ninguna comprobación sintética desde un servidor rápido habría detectado. Una herramienta detectó la caída; la otra, la experiencia lenta. Ese es el reparto de trabajo habitual.
Qué cubre Uptimecheck y qué no
Uptimecheck es un servicio de monitorización sintética. No añade ningún script RUM a tus páginas, así que, para los tiempos y los errores de JavaScript de tus propios visitantes, usa una herramienta RUM específica junto a él. Lo que sí hace:
Monitorización de disponibilidad: comprobaciones HTTP(S), de ping y de puertos con una frecuencia de hasta cada minuto desde Estocolmo, Londres y Nueva York, con comprobaciones de palabras clave, JSON y cabeceras, y cada fallo confirmado desde una segunda ubicación antes de enviar una alerta. Los tiempos de respuesta se desglosan en DNS, conexión, TLS, servidor y descarga.
Monitorización de flujos: hasta 10 pasos, como abrir una página, iniciar sesión, enviar un formulario o llamar a una API, con valores que pasan de un paso al siguiente. Los flujos de peticiones simples pueden ejecutarse cada minuto; los flujos en un navegador real ejecutan JavaScript y clics como mucho cada 15 minutos, con una captura de pantalla del paso que falló.
Monitorización de la velocidad de página: una prueba diaria de Lighthouse en móvil y escritorio para la página de inicio y hasta 4 páginas más y, para las páginas y webs con suficientes visitas, lo que experimentaron los usuarios reales de Chrome durante 28 días según el Chrome UX Report. Recibes una alerta cuando la puntuación de una página baja de tu límite.
Para configurar un recorrido, consulta cómo monitorizar un inicio de sesión o un checkout con un flujo y cómo comprobar la velocidad de página. Los planes empiezan en 9 € al mes con facturación anual o 12 € con facturación mensual, IVA no incluido; consulta la página de precios.
Entérate de que algo falla antes de que te lo digan tus visitantes. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.