¿Cuánto ralentiza el session replay la velocidad de un sitio web?

¿Ralentiza el session replay el rendimiento de un sitio web?

El session replay, es decir, la reproducción de visitas grabadas, le cuesta a una página en tres sitios, y por eso la respuesta a "ralentiza el session replay el rendimiento de un sitio web" es sí: bytes de script en la primera carga, CPU del hilo principal serializando mutaciones del DOM y ancho de banda de subida durante la visita. Cuánto crece cada coste depende del grabador, del tamaño del DOM de la página y de la configuración de muestreo. Sentry publica un benchmark fechado con su metodología adjunta, y esas cifras ponen el coste visible en el hilo principal, no en la red.

¿Cuáles son los tres costes de grabar una sesión?

Un grabador le cobra a una página una vez al cargar y luego de forma continua durante el resto de la visita. El cargo único es el bundle, que se descarga, se parsea y se ejecuta antes de poder tomar su primera instantánea del DOM. El cargo continuo se reparte entre la CPU, que serializa los registros de mutación en eventos JSON, y la red, que sube esos eventos por lotes. Como el session replay reconstruye una visita a partir de mutaciones del DOM en lugar de fotogramas de vídeo, la línea de CPU es la que escala con tu página.

¿Cuánto pesa un script de session replay?

El bundle del grabador es la única parte que un visitante paga antes de que la página se vuelva interactiva. Bundlephobia mide @rrweb/record 2.1.4, la mitad de grabación de rrweb, en 23.262 bytes gzipped, y el paquete rrweb completo con el reproductor incluido en 78.597 bytes gzipped. La propia documentación de Sentry indica que "as of version 7.78.0 the Session Replay plugin is an additional ~36KB gzipped" sobre su SDK de errores. Flowsery envía un solo script por debajo de 10 KB. Carga de forma asíncrona el grabador que elijas para que sus bytes nunca se sitúen delante del primer pintado, y luego haz tú mismo la comparación antes y después en Lighthouse en lugar de fiarte de una insignia de tamaño.

¿Cuánto tiempo de hilo principal cuesta la serialización del DOM?

El coste de CPU se concentra en la primera instantánea completa y luego cae a trabajo por lotes durante el resto de la sesión. rrweb registra un MutationObserver, y por eso su guía indica que rrweb "does not support IE11 and below because it uses the MutationObserver API"; esa API entrega al grabador un lote de registros en cola en lugar de dispararse una vez por cada cambio del DOM, así que la serialización corre lote a lote, no en cada toque de nodo. Hay cifras publicadas de la instantánea: la issue de rrweb #1337 midió la serialización de la instantánea completa en 34,55 ms de media sobre un documento de divs muy anidados, y en 27,35 ms tras eliminar búsquedas repetidas de closest().

El artículo de web.dev de Google sobre tareas largas define el umbral y la aritmética:

blocking time = task duration - 50 ms

Una instantánea de 34,55 ms aporta por tanto 0 ms de blocking time, porque "any task that takes longer than 50 milliseconds is a long task" y nada más corto cuenta. Las instantáneas sobre árboles del DOM mucho mayores cruzan esa línea, y el tracker de rrweb tiene los reportes: la issue #1547 dice que una comprobación interna "lags by 1 to 3 seconds on pages with lots of nodes", y la issue #1820 documenta el bloqueo del hilo principal cuando hay un widget de Zendesk en la página. Ningún benchmark público mapea el número de nodos del DOM a milisegundos de serialización, así que trata cualquier cifra fija de CPU por página que declare un proveedor como no medida.

Los grabadores pueden empujar el trabajo no urgente a requestIdleCallback, pero la especificación del W3C limita cada deadline de inactividad "to a maximum value of 50ms" para que el navegador conserve margen y responda a la entrada dentro de la ventana de 100 ms que se percibe como instantánea. MDN advierte de que sin la opción timeout "it's possible multiple seconds will elapse before the callback is fired", así que la planificación en tiempo libre encaja con la compresión y la subida, no con la instantánea.

¿Cuánto ancho de banda sube un session replay?

El benchmark de Sentry midió la subida de red de su escenario creciendo de 3,84 KB solo con el SDK de errores a 272,51 KB con el replay activado, mientras la descarga se quedaba plana en 8,09 MB y 8,07 MB. La subida es el coste que cargan a la vez tu servidor y la conexión de tu visitante, y escala linealmente con las sesiones grabadas:

monthly replay upload = uploaded bytes per session x sessions per month

Con los 272,51 KB medidos por Sentry por escenario grabado y 50.000 sesiones al mes, eso son 13.625.500 KB, o unos 13 GB de subida. Las apps con mucho texto y DOM de cambio lento quedan por debajo de esa cifra y las apps con mucho canvas o animación quedan por encima, y para eso existe la receta de almacenamiento de rrweb.

¿Cambia el session replay las Core Web Vitals?

En la ejecución publicada por Sentry, el session replay dejó en paz a Largest Contentful Paint y a Cumulative Layout Shift y movió el Total Blocking Time. El benchmark estaba "last updated on Sept 25, 2023" y corrió "on an Apple M1 MacBook Pro against a remote preview server and a remote API backend with 50 iterations".

El Total Blocking Time subió 415,13 ms entre el SDK de errores y la build con replay, y Sentry señala que una página de prueba más simple "produced an increase of ~100 ms of total JS blocking time". La estabilidad de diseño no se movió nada, lo que encaja con el funcionamiento de la métrica: la grabación lee el DOM y Cumulative Layout Shift puntúa el movimiento dentro de él. Un portátil M1 no es un móvil Android de gama media, y nadie ha publicado el mismo benchmark en hardware móvil de gama baja, así que mide las Core Web Vitals con tus propios datos de campo antes de decidir que las cifras se trasladan.

¿Cómo recortas el overhead del session replay sin perder la grabación?

El muestreo elimina los eventos que más cuestan y menos prueban. La receta de almacenamiento de rrweb recomienda mousemove: false para descartar el movimiento del ratón, scroll: 150 para emitir como mucho un evento de scroll cada 150 ms, media: 800 para la interacción con medios e input: 'last' para grabar solo el valor final de un campo escrito, con el argumento de que el muestreo "can reduce the storage size by dropping some events". Más allá del muestreo, blockClass salta subárboles enteros, ya que "an element with the class name .rr-block will not be recorded, instead it will replay as a placeholder", y slimDOMOptions recorta las partes del DOM que no aportan valor de reproducción. Empieza por mousemove y scroll en tu página más pesada, y vuelve a medir. El enmascaramiento corre dentro de la misma pasada de serialización, así que cómo configuras el enmascaramiento cambia el coste de CPU además de tu postura de privacidad.

Preguntas frecuentes

¿Bloquea el session replay el primer renderizado de una página?

No cuando el grabador carga de forma asíncrona, porque un script async no se sitúa en la ruta crítica del parser. Lo que sí puede aterrizar cerca del primer renderizado es la instantánea inicial del DOM, que corre después de que arranque el grabador y escala con el número de nodos. El benchmark de Sentry mostró Largest Contentful Paint en 1529,11 ms con el replay activado frente a 1599,19 ms sin ningún SDK, así que el primer pintado no fue el punto de presión en esa ejecución.

¿Cuánto añade el script del grabador al peso de la página?

Bundlephobia lista @rrweb/record 2.1.4 en 23.262 bytes gzipped y el bundle rrweb completo en 78.597 bytes gzipped, y Sentry documenta su plugin de Session Replay en unos 36 KB gzipped sobre su SDK de errores. El script de Flowsery está por debajo de 10 KB. Comprueba el tamaño de transferencia comprimido en el panel de red de tu navegador, ya que las cifras sin comprimir exageran lo que descarga un visitante.

¿Aumenta el session replay el consumo de datos de un visitante?

Sí, por el lado de la subida. Sentry midió 272,51 KB subidos en su escenario de benchmark con el replay activado, frente a 3,84 KB solo con el SDK de errores, mientras que el volumen de descarga no se movió. Los visitantes con conexiones móviles con límite pagan esa subida, y ese es el argumento más fuerte para sacar mousemove del flujo por muestreo.

¿Por qué cuesta más CPU el session replay en unas páginas que en otras?

El trabajo de serialización es función del número de nodos del DOM y de la tasa de mutación, no de las páginas vistas. Un dashboard que vuelve a renderizar una tabla grande en cada pulsación produce más registros de mutación que un artículo estático, y la issue de rrweb #1547 reporta retrasos de 1 a 3 segundos "on pages with lots of nodes". Los widgets de terceros suman también, que es lo que documenta la issue #1820 para el Zendesk Web Widget.

¿Perjudica el session replay al posicionamiento SEO?

Solo por la misma vía que cualquier script, moviendo las Core Web Vitals. La documentación de búsqueda de Google dice que sus sistemas de ranking principales premian una buena experiencia de página, y a la vez avisa de que las Core Web Vitals por sí solas no garantizan posiciones (Google Search Central). Como la medición de Sentry movió el Total Blocking Time y dejó planos Largest Contentful Paint y Cumulative Layout Shift, la métrica a vigilar es la capacidad de respuesta del hilo principal.

¿Cómo mido el overhead del session replay en mi propio sitio?

Carga tu página más pesada con el grabador desactivado, graba un perfil de rendimiento en Chrome DevTools, luego repite con el grabador activado y compara tiempo de scripting, número de tareas largas y bytes transferidos. Ejecuta cada configuración varias veces y compara medianas, porque las ejecuciones sueltas varían más que el efecto que estás midiendo. Los datos de campo de dispositivos reales zanjan lo que un perfil de laboratorio solo sugiere.

¿Desactivar el seguimiento de mousemove ahorra tiempo de CPU o solo ancho de banda?

Ambas cosas. La tabla de costes del artículo incluye el muestreo entre los controles tanto del hilo principal como del ancho de banda de subida, porque cada evento de mousemove que se descarta es un registro de mutación menos que serializar y un evento menos que subir. Desactivar mousemove con mousemove: false es la misma palanca que la receta de almacenamiento de rrweb recomienda primero.

¿Qué cuenta como una 'tarea larga' que el session replay debe evitar?

El artículo de web.dev de Google define una tarea larga como cualquier trabajo que dure más de 50 milisegundos en el hilo principal, con un tiempo de bloqueo igual a la duración de la tarea menos 50 ms. El benchmark de instantánea completa de rrweb midió 34.55 ms en un documento de divs anidados, lo que queda por debajo de ese límite y no genera tiempo de bloqueo. Las instantáneas en árboles DOM mucho más grandes son las que superan ese límite, como muestran los informes del propio rastreador de incidencias de rrweb sobre retrasos de varios segundos.

¿Puede requestIdleCallback evitar que el session replay bloquee el hilo principal?

Solo para el trabajo que puede esperar. Los grabadores pueden mover la compresión y la subida a requestIdleCallback, pero la especificación del W3C limita cada plazo de inactividad a 50 ms, y MDN advierte que sin una opción timeout un callback puede tardar varios segundos en dispararse. Eso hace que la planificación en tiempo inactivo sirva para trabajo de fondo, no para la instantánea inicial del DOM que debe ejecutarse en cuanto arranca el grabador.

¿Cuesta más el session replay con una CPU lenta o con una conexión de red lenta?

En la prueba publicada por Sentry, la CPU carga con la mayor parte del coste. La descarga se mantuvo estable en 8.09 MB frente a 8.07 MB con el replay activado, mientras que el Total Blocking Time subió de 2621.67 ms a 3036.80 ms, y la conclusión del artículo es que el coste recae en el hilo principal, no en la red. La subida sí creció de 3.84 KB a 272.51 KB, así que una conexión con datos limitados también lo nota, aunque menos que una CPU lenta.