Análisis de Browsertrix Crawler: archiva lo que hizo el navegador, no lo que dice el código

Browsertrix Crawler es el rastreador de archivado de Webrecorder: una imagen Docker que controla un Chromium real mediante Puppeteer, registra todo lo que ese navegador descarga y lo guarda en WARC —el formato estándar de archivo web—, con la opción de empaquetarlo en un paquete WACZ con índice, lista de páginas y registros. Su propósito es precisamente lo que lo diferencia de las herramientas de scraping a las que se parece por encima. Un scraper va a buscar datos y desecha la página en cuanto obtiene los campos; un archivador conserva la visita en sí —los bytes, las cabeceras, el orden en que llegaron— para que la página pueda volver a abrirse mucho tiempo después, aunque el sitio haya cambiado o desaparecido. Webrecorder ha mantenido esa capa de infraestructura de la web, incluidos formatos y sistema de reproducción, desde mucho antes de que el archivado pareciera una categoría de producto, y bibliotecas, redacciones y equipos de investigación dependen de ello.

Probé la v1.14.0 en Docker contra un entorno local de prueba con cuatro clases de endpoints intencionalmente distintas, e instrumenté ambos lados del rastreo: registros WARC para el contenido archivado y un contador de accesos en el servidor para las solicitudes reales. La diferencia útil no fue simplemente estático frente a dinámico. Browsertrix capturó un enlace creado en tiempo de ejecución y un fetch() emitido por la página, pero no solicitó dos literales de URL dentro de una función JavaScript que nunca se ejecutó.

El archivo app.js vinculado sí se archivó completo, incluidos ambos paths literales, pero ninguno de esos endpoints generó un registro de respuesta, un registro de solicitud ni un acceso en el servidor. La función que los contenía nunca llegó a ejecutarse. Por eso, este artículo evalúa Browsertrix como archivador de una sesión del navegador, no como inventario de cada URL mencionada en el código fuente.

Qué es realmente Browsertrix Crawler

Mucha gente llega esperando un scraper y se va decepcionada. Nada en el flujo predeterminado te entrega un CSV con precios de productos, y esperar eso es como esperar que una dashcam te redacte un informe de tráfico. El resultado es un registro reproducible de una sesión de navegación, y todas las decisiones de diseño posteriores parten de ahí.

Probé v1.14.0 el 27 de julio de 2026: webrecorder/browsertrix-crawler:latest con digest sha256:9d6800a8…, y crawl --version confirmó la compilación. El proyecto está bajo AGPL-3.0. Todas las mediciones se ejecutaron en Docker mediante Colima en macOS arm64 contra el entorno local controlado; el contador del lado del servidor aportó evidencia independiente de los registros de Browsertrix y del análisis del archivo archivado.

La AGPL-3.0 merece una pausa aparte. Es copyleft fuerte con cláusulas de uso en red. Si Browsertrix Crawler va a integrarse en un producto comercial en lugar de ejecutarse como una herramienta aislada, conviene que alguien revise bien la licencia antes de publicarlo. Esto es una advertencia, no asesoría legal.

El archivo conserva la sesión, no el código fuente

Mi entorno de prueba sirvió cuatro tipos de endpoint, separados a propósito porque un archivador los trata de forma completamente distinta:

• Clase A — <a href> simple en el HTML. Cuatro páginas más una cadena de profundidad de tres niveles. Cualquier rastreador del mundo encuentra esto.
• Clase B — literales de URL dentro de una función que nunca se ejecuta. Dos rutas, /api/js-endpoint-7 y /api/js-endpoint-8, como cadenas dentro de loadData(), una función no llamada en app.js.
• Clase C — un enlace construido en tiempo de ejecución. Un <a href> ensamblado a partir de fragmentos en JavaScript ('endpoint' + (6 * 7)) y añadido al DOM. La ruta continua /runtime-only/endpoint42 no existe en ningún byte servido.
• Clase D — un fetch() que la página sí emite. La ruta se arma del mismo modo ('runtime-xhr-' + (33 * 3)), y luego se solicita de verdad al cargar la página.

Para las clases C y D, las rutas completas no aparecían como cadenas continuas en los archivos servidos. Por eso, sus accesos y registros de respuesta en el servidor son evidencia de que en este entorno se ejercitaron tanto la construcción en tiempo de ejecución como las rutas de solicitud.

Qué se capturó y qué no

Dos instrumentos, comprobados entre sí en cada caso: registros de respuesta WARC (lo que está dentro del archivo) y el contador de accesos del servidor del entorno, indexado por (Host header, path) (lo que realmente se solicitó). Coincidieron en todo.

La clase C es la que separa a un navegador real de un rastreo estático. La extracción de enlaces predeterminada lee el DOM renderizado (a[href]->href, según la documentación de opciones comunes), así que un enlace que solo existe después de ejecutarse JavaScript igualmente se pone en cola, se solicita y se archiva. La clase D entra por otro motivo: la propia página emitió la solicitud, y el archivador está en la ruta de red registrando todo lo que pasa por ahí.

Un límite importante sobre la clase C: mi enlace se inyectó de forma síncrona al cargar la página. Los enlaces que aparecen más tarde, durante los comportamientos de Browsertrix, son otro caso, y existe una incidencia abierta precisamente para eso: #723, "Links on pages that are discovered during behaviors are not extracted". No probé ese escenario, así que no afirmo nada al respecto.

El archivo sí se archivó. Los endpoints no.

Confirmar el fallo de la clase B exigió revisar el WARC registro por registro, no solo contar resúmenes.

app.js sí está en el archivo —un registro de respuesta, un cuerpo JavaScript de 222 bytes— y los dos literales de la clase B aparecen allí de forma textual. Sin embargo, ni /api/js-endpoint-7 ni /api/js-endpoint-8 aparecen como URI objetivo en ningún registro de todo el archivo: cero registros de respuesta, cero registros de solicitud. Cada cadena literal aparece exactamente una vez en todo el archivo, y ambas veces dentro del cuerpo almacenado de app.js.

Eso descarta la explicación obvia (“app.js nunca se descargó”). El archivador guardó el archivo que hace referencia a esos endpoints y nunca llegó a solicitarles nada, porque loadData() no se ejecutó. Los comportamientos predeterminados de Browsertrix estaban activos —autoplay, autofetch, autoscroll, siteSpecific— y autofetch tampoco los rescató, lo cual tiene sentido si se lee qué hace autofetch: va a por entradas srcset de img, hojas de estilo y URLs data-*, no por literales de cadena enterrados en cuerpos de función.

Para un contraste ilustrativo dentro del mismo entorno, también ejecuté Katana v1.6.1 como katana -u <seed> -jc -silent -nc -d 4. Su resumen bruto de descubrimiento refleja el resultado opuesto en las dos clases de JavaScript construidas ad hoc:

Ambos comandos usaron el mismo entorno y los mismos nombres de endpoint. La tabla no pretende ser una clasificación general entre rastreadores de navegador y estáticos; muestra por qué el inventario de endpoints y la preservación de sesión requieren pruebas de cobertura distintas.

La frase “es un navegador real, así que captura todo lo que hace JavaScript” es la que verás repetida en muchas reseñas. Está exagerada. Captura el tráfico ejecutado. El código que menciona una URL sin llegar a llamarla no genera tráfico, y sin tráfico no hay registro.

Los cuerpos de replay están ahí, con una cosa que no comprobé

Para los dos endpoints generados en tiempo de ejecución, extraje del WARC los cuerpos de respuesta HTTP archivados y confirmé que contienen el JSON servido: 206 bytes para el objetivo del enlace inyectado en runtime y 201 bytes para el objetivo del fetch() en runtime. Así que no son simples índices apuntando a nada: el contenido está en el archivo, que es la condición previa para que una reproducción lo sirva.

Lo que no hice fue levantar pywb o replayweb.page y renderizar el archivo. Tener el cuerpo dentro del archivo y lograr una reproducción renderizada correcta no son la misma afirmación, y esta prueba solo cubre la primera. El comportamiento de replay, los controles de autenticidad, la cadena de custodia y la admisibilidad como evidencia requieren validación aparte.

Una captura de producción necesita una prueba de aceptación más amplia

Este entorno responde una pregunta estrecha con claridad: ¿un enlace construido sincrónicamente en runtime y una solicitud emitida por la página se convirtieron en tráfico de red y registros de archivo? Un trabajo de preservación en producción suele tener varias formas más de fallar y aun así producir un WACZ válido.

Empieza por la reproducción. Abre el paquete en el sistema de replay que se vaya a usar realmente y compara un conjunto fijo de páginas con la referencia tomada en el momento de la captura. Verifica texto renderizado, imágenes, estilos, navegación y cualquier interacción que importe para el registro. Luego inspecciona el panel de red del navegador de replay en busca de subrecursos ausentes. Un cuerpo de respuesta puede existir en WARC y, aun así, la reproducción fallar porque la reescritura, los índices, los tiempos, los orígenes o las dependencias no encajan. Esta revisión no cruzó esa frontera.

El comportamiento dinámico merece su propio conjunto de pruebas. El enlace de la clase C aquí apareció de forma síncrona durante la carga. Las aplicaciones reales pueden revelar contenido tras temporizadores, desplazamiento, cierre de consentimientos, cambios de ruta, componentes personalizados o largas cadenas de API. Coloca un objetivo conocido detrás de cada comportamiento de interés y verifica tanto el acceso al servidor como el cuerpo archivado. Los comportamientos predeterminados de Browsertrix son entradas útiles para esa prueba, no una prueba de que se alcanzó cada estado diferido. La incidencia #723 es especialmente relevante si los enlaces aparecen durante los comportamientos y no durante la ejecución inicial de la página.

Las capturas autenticadas añaden preguntas de sesión. Confirma que el estado de inicio de sesión entra en el perfil del navegador, sobrevive a las navegaciones necesarias y no se filtra a colecciones que deberían permanecer aisladas. Prueba la renovación de tokens y las rutas de cierre de sesión. Si el archivo contiene material privado o personal, prueba los controles de acceso y la retención de esos archivos como parte del mismo plan de aceptación. Una captura técnicamente correcta aún puede gestionarse mal después de recolectarse.

Service workers, medios en streaming, WebSockets, descargas, frames de otros orígenes y URLs firmadas merecen cada uno una página representativa si son importantes para el objetivo. El entorno de once páginas no dice nada sobre eso. Tampoco establece cómo se comporta el rastreador cuando una página permanece activa durante minutos, emite solicitudes después de la ventana habitual de estabilización o requiere gestos del usuario. Evita convertir “Chromium real” en una afirmación de cobertura total; define los comportamientos del navegador que la colección debe preservar y haz que cada uno sea observable.

Por último, conserva la evidencia necesaria para diagnosticar los fallos. Guarda el digest exacto de la imagen y el comando, los registros de Browsertrix, las listas de páginas, los índices, los checksums de WARC/WACZ, la evidencia de solicitudes del lado del servidor cuando exista, y un pequeño manifiesto de verdad de referencia. En capturas repetidas, registra tiempo, configuración y entorno junto con el artefacto. Esos registros no crean admisibilidad legal, pero sí hacen reproducible una afirmación técnica y permiten ver si una diferencia posterior provino del sitio, del rastreador o de la pila de replay.

Lo que costó en bytes este entorno de cuerpos pequeños

Este entorno solo sirve unos pocos cientos de bytes por página, así que sus ratios de sobrecarga no deben extrapolarse a sitios cargados de recursos. Dentro de ese régimen estrecho, medí la composición del archivo en lugar de fijarme solo en su tamaño final:

Los conteos y totales de bytes por tipo están en el público capture-summary.json; las participaciones usan como denominador el total de 17,024 bytes de contenido del registro.

En esta ejecución de cuerpos pequeños, los registros de solicitud pesaron más que el contenido de respuesta, y los bytes de solicitud más urn:pageinfo: fueron unas 2.1× el payload de respuesta. Eso describe la mezcla de registros de este entorno, no una relación general de WARC.

En disco, en tres ejecuciones aisladas:

Tomando las medianas, salen cuatro ratios:

Y dentro del propio WACZ:

La última fila fue la que más me sorprendió. Casi un tercio del paquete de archivo, en un rastreo pequeño, es el registro del rastreo más que la web.

La medición fue estable: el payload de respuesta salió byte a byte idéntico en las tres ejecuciones (5,339 B cada vez), y WARC.gz y WACZ variaron menos de 0.4%.

Estos ratios no se trasladan a páginas reales con imágenes, fuentes y grandes paquetes de scripts. El punto estructural sí: los registros de solicitud y page-info generan sobrecarga independientemente del tamaño del payload. Mide una muestra representativa antes de planificar el almacenamiento de producción; no multipliques el ratio 10× de este entorno por una estimación del corpus.

Configuración y el espacio en disco que debes prever

Una vez instalados y en marcha Docker o Colima, la configuración específica de Browsertrix es docker pull webrecorder/browsertrix-crawler:latest y luego docker run … crawl --url … --generateWACZ. La imagen ya trae Chromium, así que no hizo falta un navegador aparte ni un entorno de Python.

Lo que cuesta esa comodidad, en las ejecuciones medidas aquí:

El contenedor es donde vive la fricción, y esa línea de descarga y descompresión es lo que cuesta empaquetar un navegador. Lo ejecuté con --shm-size 1g, y como mi entorno vivía en el host mientras el rastreo corría en el contenedor, necesité --add-host=host.docker.internal:host-gateway y que el entorno estuviera enlazado a 0.0.0.0 en lugar de loopback. Si vas a rastrear internet público te ahorrarás ese paso de red, pero si vas a archivar algo en tu propia máquina o en un host interno de staging, reserva una tarde para dejarlo listo.

El directorio de salida es la parte que más fácilmente se subestima. Extrapola ese crecimiento a un rastreo real y planifica el almacenamiento antes de empezar, no cuando el disco se quede sin espacio a las 3 de la mañana.

Probablemente el arranque del navegador contribuye de forma material a un rastreo de 28–30 segundos para solo once páginas, pero no separé el tiempo de arranque del de navegación o empaquetado. De esta ejecución no se desprende ninguna conclusión sobre rendimiento por página.

Cómo planificar almacenamiento sin abusar de los ratios de este entorno

La forma útil de dimensionar una colección es empírica. Selecciona páginas que representen la distribución real del objetivo: shells de aplicación ligeros, landing pages cargadas de imágenes, descargas de documentos, artículos largos y vistas autenticadas si están dentro del alcance. Captura cada clase con los comportamientos y ajustes de empaquetado previstos. Mide el payload de respuesta, WARC, WACZ, índices, registros, residuos del perfil del navegador y cualquier espacio temporal que permanezca durante la ejecución. El uso máximo de disco importa tanto como el paquete final si el empaquetado mantiene varias copias durante unos instantes.

Separa componentes fijos y variables. La imagen de contenedor de 3.51 GB es una sobrecarga de despliegue que puede compartirse entre muchas capturas en un mismo worker. Los registros de solicitud, los registros page-info, los índices y las listas de páginas crecen con la actividad del rastreo. Los cuerpos de respuesta dependen mucho del objetivo, mientras que los registros dependen de la duración y la verbosidad de la ejecución. La retención y la replicación multiplican después la colección final de forma independiente al comportamiento del rastreo. Un modelo de capacidad que mezcle todo eso en “bytes por página” será frágil.

La compresión y la deduplicación también necesitan contenido representativo. El payload de respuesta de este entorno fue idéntico byte por byte en tres ejecuciones, pero eso no describe páginas con anuncios cambiantes, marcas de tiempo, respuestas personalizadas o URLs de recursos con cache-busting. Si las capturas repetidas forman parte del programa, mide capturas sucesivas de las mismas páginas e inspecciona los registros revisit en lugar de asumir que las páginas aparentemente idénticas deduplican bien. Del mismo modo, prueba si los registros y los índices se conservan al mismo nivel de réplica que el payload de preservación.

En términos operativos, establece umbrales de aviso antes de comenzar la colección. Supervisa el espacio libre, el crecimiento por colección, los fallos de empaquetado y el tamaño de los perfiles del navegador o directorios temporales. Realiza una prueba de restauración desde el WACZ almacenado, no solo una comprobación de checksum. Los ratios anteriores son útiles porque revelan qué componentes existen; la muestra representativa es la que te dice cuánto pesarán para tu sitio.

Documenta esas suposiciones junto al cálculo de capacidad y revísalas después del rastreo piloto.

Disciplina de alcance, comprobada con dos controles

Los rastreadores de archivado que se desvían son un riesgo operativo real: puedes acabar con un problema legal y una factura de almacenamiento al mismo tiempo. Mi página de inicio enlazaba a http://outofscope.test:<port>/page/out, un hostname distinto que apunta al mismo entorno, así que un acceso con esa cabecera Host demostraría una solicitud fuera de alcance sin tráfico real a internet.

La segunda fila es la que da sentido a la primera. Con any el enlace se alcanzó dos veces, así que era accesible; el cero bajo el alcance prefix predeterminado es disciplina real, no un enlace que el rastreador no detectó. Existe un informe abierto sobre visitas fuera de alcance en otras configuraciones, #788, que no reproduje bajo el alcance prefix por defecto en este entorno. Conviene saber que existe; no conviene que yo afirme haberlo visto.

La robustez fue poco llamativa en el buen sentido. Una ruta que devolvía HTTP 500 y un enlace roto se solicitaron ambos, el rastreo terminó limpiamente con un WARC y un WACZ válidos, y el enlace roto se almacenó como un registro revisit deduplicado en lugar de romper nada.

Ventajas y desventajas

Ventajas

• Captura enlaces del DOM inyectados en runtime y llamadas fetch() emitidas por la página; ambas fueron confirmadas en el archivo y en el servidor, sobre rutas que no existen como literales en ningún sitio.
• El HTML estático y el recorrido en profundidad son completos: 4/4 enlaces, cadena de profundidad 3/3, sin fallos.
• Una vez que Docker/Colima estuvo en marcha, un solo docker run produjo un WARC y un WACZ; Chromium venía dentro de la imagen.
• El alcance prefix predeterminado se mantuvo con cero solicitudes fuera de alcance; any amplió el alcance como se documenta, así que el control hace lo que promete.
• La salida es un archivo basado en estándares (WARC, empaquetado como WACZ con índice CDX y lista de páginas) y no un blob propietario.
• Archivos casi deterministas: payload idéntico byte por byte en tres ejecuciones, con una variación de tamaño en disco inferior al 0.4%.
• Comportamiento de fallo limpio: una ruta 500 y un enlace roto no abortaron el rastreo.

Desventajas

• Los literales de URL en JavaScript no ejecutado simplemente no se descubren (0/2), incluso cuando el archivo que los contiene sí se archiva. Es correcto por diseño, pero sigue siendo una brecha real de cobertura si tu objetivo es descubrir endpoints.
• Huella pesada: descarga de ~1 GB, 3.51 GB en disco y directorios de salida que crecen rápido.
• La sobrecarga en bytes es considerable en páginas pequeñas: los registros de solicitud más pageinfo superaron el payload real, y ~30% del WACZ fue el registro del rastreo.
• AGPL-3.0 implica trabajo serio de cumplimiento si se incorpora en un producto comercial.
• No es una herramienta de datos estructurados. No hay esquema, no hay mapeo de campos, no hay filas limpias al final.
• El rendimiento por página es modesto por diseño, porque cada página pasa por un navegador real.

Quién debería usarlo y quién no

Browsertrix está pensado para equipos cuyo artefacto necesario es un archivo de recursos obtenidos por el navegador, no filas extraídas. En este entorno, los cuerpos de respuesta obtenidos en runtime estuvieron presentes en WARC y empaquetados en WACZ. Bibliotecas, redacciones y equipos de investigación son usuarios plausibles, pero la adopción en producción debería probar por separado la reproducción, la autenticación, los service workers, los flujos de consentimiento, los comportamientos diferidos, los recursos de streaming y los requisitos de manejo de evidencia.

Pásalo por alto si lo que realmente necesitas son datos. Si el objetivo es “dame todos los productos y precios de estas 400 páginas en una hoja de cálculo”, un archivador es una ruta extraña para llegar ahí: acabarás archivando gigabytes y luego tendrás que escribir igualmente código de extracción sobre archivos WARC. También conviene descartarlo si estás mapeando la superficie de API de una aplicación, porque el resultado de la clase B dice claramente que un parser estático de JavaScript encontrará endpoints que Browsertrix nunca toca. Y si no te gusta Docker o trabajas en un entorno donde una imagen de 3.5 GB es un problema, esta no es la herramienta que se va a adaptar a ti.

Autorización y retención

Los controles de alcance no equivalen a autorización. Define hosts permitidos, retención y acceso al archivo antes de rastrear, sobre todo cuando las capturas duraderas puedan incluir datos personales. La prueba prefix/any muestra que la configuración cambia el alcance de red; no establece qué alcance es legal para una colección concreta.

Revisión relacionada: implicaciones legales del web scraping y el archivado.

Alternativas según el resultado requerido

Elige según el artefacto. Browsertrix apunta a la preservación en WARC/WACZ. Una biblioteca de automatización de navegador como Playwright te da una página programable, pero deja en tus manos el empaquetado de la captura. Los rastreadores de descubrimiento de endpoints enumeran URLs, mientras que las herramientas de extracción devuelven texto o registros estructurados. Estas categorías pueden compartir navegador y aun así resolver trabajos distintos.

Revisión relacionada: análisis de Heritrix.

Divulgación: Thunderbit es el producto del editor y no se probó en este entorno de Browsertrix. Pertenece a la categoría de extracción gestionada, y produce texto de página o datos estructurados en lugar de un archivo basado en estándares. Esta reseña solo respalda el límite de salida, no una comparación de rendimiento o capacidades.

Prueba Thunderbit para extracción de datos web

Veredicto

Usa Browsertrix Crawler cuando el resultado requerido sea una captura WARC/WACZ y un Chromium en contenedor encaje con el despliegue. En este entorno, los registros del archivo y los accesos del servidor coincidieron para enlaces síncronos generados en runtime y para fetch() emitidos por la página; el alcance prefix por defecto excluyó el segundo host, y las rutas con fallo no impidieron generar un archivo válido.

Antes de usarlo en producción, valida la reproducción, el comportamiento diferido, las sesiones autenticadas, los service workers, la composición del almacenamiento en páginas representativas y las obligaciones de licencia. El límite probado es más estrecho: las referencias de código que nunca se ejecutan no produjeron ni solicitud ni registro de archivo para sus objetivos, aunque el script que las contenía sí se preservó.

Prueba Thunderbit para extracción de datos web Get Started Free

Preguntas frecuentes

¿Cuál es la diferencia entre WARC y WACZ aquí? WARC contiene la solicitud capturada, la respuesta y los registros relacionados. WACZ empaqueta WARC con índices, listas de páginas, metadatos y registros para distribución y herramientas de reproducción. Esta reseña inspeccionó ambos paquetes, pero no renderizó una reproducción.

¿Cómo debo estimar el almacenamiento? Mide páginas representativas y conserva en la muestra la composición completa del WACZ, incluidos registros e índices. Los ratios de este artículo provienen de cuerpos de respuesta inusualmente pequeños y no sirven para multiplicarlos por el número de URLs de producción.

¿Se saldrá del sitio al que lo apunte? En mi prueba, no con la configuración predeterminada. Con --scopeType prefix, un enlace hacia otro hostname se solicitó cero veces; al cambiar a --scopeType any, se solicitó dos veces, lo que demuestra que el enlace era accesible y que el cero del alcance predeterminado era disciplina real. Existe un informe upstream abierto sobre visitas fuera de alcance en otras configuraciones que no reproduje con el valor predeterminado, así que conviene revisar tus propios ajustes de alcance en lugar de darlo por hecho.

¿Qué debo probar antes de afirmar fidelidad de replay? Carga el WACZ en el sistema de replay previsto y compara las páginas renderizadas, las interacciones y los subrecursos necesarios frente a la captura viva o de referencia. Que el cuerpo exista en WARC es necesario, pero por sí solo no verifica la reproducción renderizada.

¿Browsertrix convierte una página archivada en filas estructuradas? No. Su salida es un paquete de archivo, no una tabla de campos seleccionados. Si el entregable son productos, precios, contactos u otro esquema, todavía necesitas una etapa de extracción después de la captura, o una herramienta distinta cuyo resultado principal sea datos estructurados.