Grabar pantalla del navegador con agent-browser: fps y flujo de trabajo

Elige los fps según lo que debas revisar

El punto de partida es 30 fps. Es el nuevo valor predeterminado porque permite leer con claridad los clics comunes, los estados hover, el desplazamiento, las transiciones CSS y los recorridos guiados, sin asumir la carga adicional de 60 fps.

El intervalo válido de --fps va de 1 a 60. Un número mayor no produce automáticamente una evidencia mejor. Si la página se redibuja con menos frecuencia que la tasa solicitada, pedir 60 fps no puede generar 60 estados de página realmente distintos.

Qué cambió en v0.37.0

El grabador ahora trata el video como una vista sincronizada de la página que realmente está en uso. record start y record restart capturan de forma predeterminada la página activa a 30 fps, aceptan --fps 1-60 y utilizan Page.startScreencast de Chrome. Es la propia señal de Chrome con los fotogramas que la página vuelve a dibujar: equivale a conectar una cámara directamente al canal de visualización del navegador, en lugar de tomar capturas de pantalla ocasionales.

La versión v0.37.0 también endureció el manejo de errores. Si falta ffmpeg, la ruta de salida no tiene extensión o una opción de grabación no es válida, el proceso falla antes de modificar el navegador o el estado de la grabación. Si una toma de reemplazo no puede iniciarse, la toma activa se conserva. Además, al navegar durante una grabación se eliminan las referencias obsoletas a elementos y el estado de los frames, igual que en una navegación normal.

Eso importa en un ciclo real de QA. Una ruta de video incorrecta no debería cambiar silenciosamente la página que se está probando, y comenzar una segunda toma no debería destruir la primera antes de saber si el reemplazo funciona.

Cómo grabar pantalla del navegador en cinco pasos

La secuencia confiable es comprobar, abrir, grabar, validar y detener. El último comando forma parte del contrato de la evidencia, porque vacía el búfer y guarda el archivo.

agent-browser doctor
agent-browser open https://app.example.com/login
agent-browser record start ./login-flow.mp4 --fps 30
agent-browser snapshot -i
agent-browser click @e1
agent-browser wait --url "**/dashboard"
agent-browser record stop

1. Comprueba primero el codificador. agent-browser doctor informa sobre ffmpeg y los codificadores disponibles para grabar. MP4 necesita libx264; WebM necesita libvpx. Una compilación estándar de ffmpeg para Homebrew o Debian/Ubuntu suele incluir ambos.

2. Coloca la página correcta en la pestaña activa. Si record start no recibe una URL, el grabador se conecta a la página activa tal como está. No la recarga, no abre otra pestaña ni crea un contexto limpio del navegador. Esto resulta útil cuando el error depende de una aplicación ya inicializada, una sesión autenticada o un estado dentro de la página. Si incluyes una URL, la pestaña activa navega primero y la grabación comienza cuando termina de cargar.

3. Elige el contenedor mediante la extensión. .mp4 selecciona H.264 a través de libx264; .webm selecciona VP8 a través de libvpx. Las demás extensiones se envían a ffmpeg con H.264 y solo funcionan si ffmpeg reconoce el contenedor. Los nombres de archivo sin extensión se rechazan.

4. Mantén la comprobación de aprobado o fallido dentro de la automatización. En el ejemplo, wait --url verifica si el navegador llegó al panel. El clip ayuda a una persona a entender lo ocurrido, pero no convierte los píxeles en una aserción de prueba.

5. Detén la grabación antes de cerrar. record stop guarda la toma y vacía el búfer. Si cierras primero la sesión, podrías quedarte sin el archivo que querías conservar. Usa record restart cuando necesites cerrar una toma y comenzar de inmediato la siguiente en la página activa.

capturedFrames y frames responden preguntas distintas

Interpreta los dos contadores como material de origen y video terminado. capturedFrames cuenta los fotogramas distintos producidos por la página. frames cuenta los fotogramas escritos en el archivo de video. Una página estática puede producir muy pocas imágenes distintas mientras ffmpeg escribe fotogramas repetidos para que la toma pueda reproducirse correctamente.

Hay una salvedad importante relacionada con el tiempo. Cuando la página deja de cambiar, se mantiene el último fotograma. Un único intervalo estático se conserva hasta cinco segundos; el resto de ese tramo sin cambios se omite. En la práctica, el video mantiene las pausas breves, pero comprime los periodos largos de inactividad. No uses la duración de reproducción como cronómetro para una prueba prolongada.

Por eso, un valor bajo de capturedFrames no indica necesariamente que la grabación falló: también puede significar que la página permaneció inmóvil. Y por eso conviene reservar 60 fps para movimientos que merezcan una inspección detallada. La guía de grabación señala que 60 fps prácticamente duplica la tasa de bits de 30 fps, aunque la cantidad de fotogramas distintos sigue dependiendo de los redibujados de la página.

La partida del presupuesto que cambia

Si el equipo ya utiliza agent-browser, la evidencia básica en video ya no tiene que comenzar con otra licencia para un grabador. El paquete v0.37.0 declara una licencia Apache-2.0, por lo que el grabador no tiene un costo de software por usuario. Los costos incrementales corresponden a lo que el equipo opera: configurar ffmpeg, consumir tiempo de CI, almacenar artefactos y dedicar minutos humanos a revisar el resultado.

La diferencia frente a comprar una plataforma completa de feedback o pruebas es considerable. Jam Team publica un precio de $14 por creador al mes con facturación anual. BugHerd Standard cuesta $50 al mes para cinco miembros con facturación mensual e incluye feedback en video. BrowserStack Automate cobra $59 al mes, con facturación anual, por una ejecución paralela en Chrome Desktop e incluye grabaciones de video entre sus herramientas de depuración.

Esos productos ofrecen mucho más que una grabación, así que concluir que deben reemplazarse sería un error. BrowserStack vende cobertura administrada de navegadores. BugHerd y Jam ofrecen colaboración, captura de incidencias e integraciones. La decisión útil sobre costos es más concreta: no compres una segunda capa de captura cuando agent-browser ya ejecuta el flujo y el único artefacto que falta es un video fácil de revisar.

Siete casos de uso, ordenados por quién obtiene más valor

1. Equipos de producto que diagnostican flujos fallidos de CI

Ante una prueba inestable de inicio de sesión o checkout, un equipo de producto puede iniciar una grabación a 30 fps justo antes del tramo de riesgo, mantener sus aserciones de URL o elementos y conservar el MP4 como artefacto de CI cuando la ejecución falle. Así, la persona encargada de ingeniería puede ver un banner de consentimiento, una capa que apareció tarde, un salto de foco o una transición que quizá no figure en el registro de texto. El resultado son menos minutos remunerados de ingeniería dedicados a intentar recrear un estado intermitente.

2. Equipos front-end que revisan arrastres, desplazamientos y animaciones

Una persona de ingeniería front-end puede aislar una interacción breve, capturarla a 60 fps y acompañar el clip con imágenes de los estados inicial y final. El video muestra si el movimiento entre ambos estados fue limpio; las capturas conservan los píxeles exactos. Es especialmente valioso cuando el defecto ocurre entre dos capturas, como un fotograma perdido o un objetivo de arrastre atravesado en el momento equivocado.

3. Equipos de productos de IA que auditan agentes de navegador

Un equipo de producto de IA puede grabar a 30 fps la página activa y autenticada mientras su agente ejecuta una tarea, y luego adjuntar el video junto al registro de comandos y las aserciones del agente. Quien revise el resultado podrá diferenciar entre un plan defectuoso y una página que cambió durante la ejecución. Así, un proceso opaco se convierte en evidencia que producto e ingeniería pueden analizar en conjunto.

4. Profesionales de QA que reproducen errores dependientes del estado

Una persona de QA puede preparar la sesión hasta cumplir las condiciones previas del error y después ejecutar record start sin una URL. Como la grabación se conecta al estado actual, la página no se sustituye por una navegación desde cero. Esto resulta valioso cuando el error depende del contenido acumulado en el carrito, de un modal, de una ruta autenticada o de cualquier otra condición que desaparezca al recargar.

5. Agencias que entregan una versión a un cliente

Una agencia web puede grabar a 30 fps un recorrido de aceptación, añadir esperas breves en los puntos de decisión y entregar al cliente un clip con un ritmo pensado para una persona, no para un motor de automatización. El cliente revisa el recorrido exacto sin obtener acceso al ejecutor de pruebas. La agencia dedica menos tiempo de reunión a narrar un flujo que el propio artefacto ya muestra.

6. Equipos de confiabilidad que conservan líneas de tiempo de ejecuciones largas

Una persona de ingeniería de confiabilidad puede grabar una prueba prolongada a 10 fps cuando la secuencia importa más que el movimiento. La tasa menor reduce la carga de grabación y el crecimiento del archivo frente a 30 o 60 fps. La toma sigue sirviendo para localizar el momento visible del fallo, pero los intervalos estáticos comprimidos obligan a obtener las marcas de tiempo de los registros, no de la duración de reproducción.

7. Equipos de soporte que escalan un problema complejo del navegador

Una persona de soporte puede reproducir el recorrido del cliente en una cuenta controlada, grabarlo a 30 fps, detener la toma y adjuntarla al escalar el caso. El equipo de desarrollo recibe detalles sobre los tiempos y las capas inesperadas que suelen perderse en un ticket escrito. Esto solo aporta valor si el flujo de trabajo también impide que secretos y datos de clientes entren en la grabación.

Tres productos que vale la pena crear

La mejor oportunidad: un paquete de evidencia generado por agentes

Crea un servicio pequeño que convierta una ejecución de un agente de navegador en un único paquete de revisión: resultado de la aserción, registro de comandos, captura final, MP4, contadores de fotogramas y un enlace publicado en Jira o Linear. Los equipos de producto e ingeniería pagarían porque el resultado encaja en el flujo de incidencias que ya utilizan.

La demanda es concreta. Los datos de keywords de EE. UU. muestran alrededor de 590 búsquedas mensuales de “bug reporting tool”, con un CPC de $43.80. También hay gasto visible en productos existentes: Jam Team cuesta $14 por creador al mes con facturación anual, mientras BugHerd Standard cuesta $50 al mes con facturación mensual. La versión comercial más pequeña necesita un wrapper de agent-browser, almacenamiento de artefactos, una integración con un gestor de incidencias y una lista de comprobación para ocultar datos sensibles.

Es la oportunidad más sólida porque vende la entrega, no el códec. El problema es que la barrera técnica es baja. Publicar en Jira y almacenar video son funciones fáciles de copiar, por lo que el producto debe destacar al reunir contexto confiable y evitar que se filtren datos sensibles.

Un portal de entrega de QA para agencias

Crea una página de revisión para clientes donde la agencia elija un flujo, lo ejecute contra el entorno de staging y publique la aserción, las capturas y un video con ritmo comprensible bajo un único enlace de aprobación. Las agencias y los equipos externos de QA son los compradores naturales, porque la aprobación del cliente es el punto donde la evidencia técnica suele convertirse en una reunión.

Los datos de keywords de EE. UU. indican 110 búsquedas mensuales de “website qa testing”, con un aumento interanual del 55% y un CPC de $23.91. Un MVP podría admitir varios flujos reutilizables, capturas a 30 fps, comentarios y opciones de aprobar o rechazar. El problema es la profundidad de los competidores: el plan Standard de BugHerd ya incluye proyectos ilimitados, usuarios cliente, capturas, metadatos y feedback en video. El nuevo producto debe ganar por la evidencia generada por agentes, no por ofrecer otro pin de comentarios.

Una capa de presets para pruebas de movimiento

Crea una herramienta ligera de CI que etiquete las pruebas como timeline, default o motion, las asigne a 10, 30 o 60 fps y señale diferencias inesperadas entre los fotogramas capturados y los escritos. Los equipos de plataforma front-end pagarían por obtener evidencia coherente en regresiones de animación e interacción.

Los datos de keywords de EE. UU. muestran 110 búsquedas mensuales de “automated browser testing” con un CPC de $14.96. La frase comercial más específica “automated browser testing tools” solo alcanza 20 búsquedas mensuales, pero tiene un CPC de $63.21, señal de que acceder a ese reducido grupo de compradores resulta caro. El MVP consiste en un manifiesto de pruebas, un wrapper de comandos de agent-browser, clips conservados únicamente cuando hay fallos y un índice compacto de artefactos.

El inconveniente es un impulso menor: la keyword más amplia cae un 18% interanual y 60 fps añade carga, aunque sigue limitada por la frecuencia con la que se redibuja la página. Conviene empezar como una función dentro de un producto de evidencia, no como una empresa independiente.

Lo que una grabación no demuestra

El video aporta observabilidad, no garantiza la corrección. No puede confirmar que se escribió la fila correcta en la base de datos, que una respuesta de API fuera válida ni que todos los navegadores y dispositivos se comporten igual. Debe acompañarse de aserciones, registros y capturas.

Tampoco elimina los riesgos del entorno. La grabación necesita ffmpeg en el PATH y el codificador correspondiente. Las tasas de fotogramas más altas añaden carga, las grabaciones largas consumen espacio en disco y las máquinas headless con recursos limitados pueden presentar restricciones de códec o GPU. Una página que se redibuja lentamente no puede aportar 60 fotogramas distintos cada segundo.

La privacidad debe tratarse como un requisito del producto. El grabador captura el viewport activo y el estado de la página: esa es precisamente la razón de su utilidad y también el motivo por el que se necesitan reglas deliberadas para las cuentas de prueba, el enmascaramiento de secretos, la retención de artefactos y el control de acceso. Es una decisión operativa, no una promesa integrada de ocultar datos.

Por último, agent-browser graba la evidencia, pero no la interpreta. Si necesitas que un modelo analice el video después de la ejecución, se trata de otro sistema, más próximo a la comprensión de video basada en agentes. Mantén esa capa separada de la comprobación determinista que decide si la prueba pasa o falla.

Qué hacer el lunes

La próxima semana, elige un recorrido de inicio de sesión, checkout o publicación que tienda a fallar. Ejecuta doctor, graba a 30 fps la página activa existente, conserva la aserción actual, llama a record stop y adjunta el MP4 al resultado de la prueba. Cambia a 60 fps solo si quien revisa no puede evaluar un defecto de movimiento; baja a 10 fps cuando una ejecución larga sea principalmente una secuencia. El piloto funciona cuando alguien puede diagnosticar el fallo sin repetir la ejecución, no cuando el video se limita a verse fluido.

Si necesitas un agente de navegador que produzca evidencia lista para que tu equipo la revise, puedo crearlo en torno a tu flujo real de QA.