Cómo detectar tabs congelados que tu RUM no registra
Las herramientas de monitoreo estándar pierden sesiones cuando fallan silenciosamente. Una guía técnica explica cómo construir un watchdog en Web Workers.
El artículo de Dev.to aborda un problema具体 para equipos de frontend y DevOps: por qué tus dashboards de Real User Monitoring (RUM) muestran todo en verde mientras un usuario pierde el trabajo porque su pestaña se ha congelado. La causa raíz suele ser la muestreo de sesiones. Para ahorrar costos de almacenamiento, muchas herramientas de replay solo graban un porcentaje pequeño del tráfico (a menudo alrededor del 10%) o capturan la sesión únicamente cuando se lanza una excepción de JavaScript.
Los fallos que interesan aquí son silenciosos: una pestaña que se vuelve lenta progresivamente, un scroll con tirones o una congelación total del main thread no lanzan errores. Si la sesión no cayó en la muestra aleatoria y no hubo un throw, el registro no existe. Cuando el usuario llama a soporte al día siguiente, ya es demasiado tarde: la sesión no está disponible. Además, muchas herramientas limitan la duración de la grabación a una hora, lo que puede truncar justo el periodo de degradación en aplicaciones single-page de larga duración.
El segundo problema técnico es arquitectónico. El código de monitoreo se ejecuta normalmente en el mismo main thread que se está congelando. Si la pestaña se llena, el script de observación se atasca con ella y no puede enviar el reporte. Un porcentaje de latencia (p75, p95) nos dice que hay un problema agregado, pero no nos permite identificar qué sesión específica sufrió el fallo ni reconstruir el estado de memoria o el documento antes de la caída.
La solución propuesta en el post es implementar un monitoreo por sesión completo, donde cada tab tiene su propio log ordenado con un identificador único. Para evitar el fallo del hilo principal, el author sugiere mover la lógica de vigilancia (watchdog) a un Web Worker. Este worker permanece activo aunque la interfaz se congele, ya que opera en un hilo separado. La estrategia consiste en tomar una instantánea del estado de la página mientras esta es saludable, pasarla al worker y dejar que este envíe el reporte si detecta que el main thread ha dejado de responder.
El texto también señala las limitaciones de la métrica INP (Interaction to Next Paint). INP mide la latencia de la respuesta, pero no captura la frustración del usuario por clics muertos, arrastres que zumban o la inactividad total. Para llenar esos huecos, el artículo describe cómo escribir pequeños detectores personalizados que muestrean gestos con marcas de tiempo, usando APIs como PerformanceEventTiming.
La recomendación final es operar esta infraestructura en herramientas que ya posees (AWS S3, CloudWatch, etc.) en lugar de depender de límites de terceros. Al mantener la fidelidad completa de cada sesión, cualquier queja de usuario queda trazable de forma determinista, permitiendo reproducir el estado exacto del navegador antes del fallo.
