Análisis de Browserless: Chrome como servicio que puedes dosificar

Browserless es Chrome sin interfaz gráfica empaquetado como un servicio que puedes alojar tú mismo. Su contenedor Docker se queda corriendo, acepta trabajo por HTTP o WebSocket y aplica límites compartidos de admisión en vez de integrarse dentro de cada consumidor. En las pruebas REST hechas aquí, el servicio mantuvo cero procesos de Chrome en reposo, creó procesos de Chrome mientras había una solicitud activa y volvió a cero después. Lo que se comparte es la capacidad del servicio y la cola, no un conjunto verificado de navegadores ya calentados.

Probé la versión v2.55.0 con un entorno local controlado: arranque desglosado por etapas, control de admisión en tres configuraciones, fidelidad de los endpoints frente a una referencia conocida, un soak de 30 sesiones y el límite de timeout. El comportamiento útil fue operativo más que una mejora de velocidad: los límites de admisión coincidieron con las respuestas visibles para el cliente y los puntos críticos estuvieron, sobre todo, en la forma de despliegue.

El resultado más interesante no fue una cifra de latencia. Browserless no acelera el arranque de Chrome: le pone una política de acceso, con un número fijo de sesiones dentro, una cola detrás y un HTTP 429 para el resto. Ese techo pasó de 4 a 8 y luego a 10 cuando cambié dos variables de entorno, y la contabilidad del contenedor coincidió con los códigos de estado de mi cliente en absolutamente todas las solicitudes.

Qué es realmente Browserless

Aquí es donde mucha gente se confunde con la categoría. Browserless no es una librería que importas y llamas. Es una imagen Docker — ghcr.io/browserless/chromium — que ejecutas como un servicio de larga duración. Intermedia el trabajo del navegador y lo expone de dos formas: endpoints REST (/content, /scrape, /screenshot, /pdf, además de /function y /unblock) y una superficie CDP/WebSocket a la que Puppeteer y Playwright pueden conectarse con connect().

Yo probé la superficie REST. La ruta WebSocket existe y se usa mucho, pero no la medí.

La versión evaluada fue v2.55.0, verificada el 27 de julio de 2026.

Las estrellas cambian con el tiempo; tómalo como una lectura puntual.

La barrera de licencia: SSPL-1.0 o licencia comercial

El repositorio ofrece Browserless bajo SSPL-1.0 o una licencia comercial de Browserless. Lee el archivo LICENSE actual del repositorio y la guía oficial de despliegue open source antes de decidir. Este artículo no hizo un análisis jurídico de productos comerciales, aplicaciones de código cerrado, sistemas CI, servicios alojados ni despliegues internos, así que no asigna ninguno de esos casos a una licencia. Pide a un abogado o a quien gestione las licencias de software que evalúe el modelo de despliegue y distribución.

Browserless también vende planes alojados. Los precios y las definiciones de unidades de uso cambian con frecuencia y no formaron parte de esta prueba autogestionada, así que conviene verificarlos en el sitio oficial en lugar de tomar una tabla desactualizada como evidencia de compra.

Cómo funciona el modelo de sesiones por dentro

La ruta REST medida se comportó como trabajo de navegador por solicitud, pero este entorno no rastreó los detalles internos de Browserless lo suficiente como para distinguir un proceso nuevo de Chrome de cualquier estrategia posible de reutilización de contexto. Lo que sí quedó claro es más simple: cero procesos de Chrome en reposo, 11 procesos de la familia chrome durante una solicitud activa y cero después de la ejecución secuencial. No hubo evidencia de un pool de navegadores precalentados en esta configuración.

El servicio Node de larga duración admite un número limitado de trabajos de navegador, pone en cola otro grupo limitado y rechaza el resto. Toma ese modelo de admisión como el contrato arquitectónico medido más abajo. No infieras reutilización de procesos o contextos por la palabra “pool”; el entorno de medición no puede probarlo.

El control de admisión se define con dos parámetros:

• CONCURRENT — cuántas sesiones se ejecutan al mismo tiempo.
• QUEUED — cuántas solicitudes adicionales pueden esperar turno.

El endpoint /config del contenedor mostró por defecto CONCURRENT=10, QUEUED=10, TIMEOUT=30000. Cualquier cosa por encima de CONCURRENT + QUEUED se rechaza de inmediato.

La autenticación no es opcional. Browserless v2 siempre exige un token — si no defines TOKEN, genera uno aleatorio y lo imprime en stdout al arrancar. Cada llamada REST lleva ?token=.

Para observabilidad tienes /pressure (en ejecución, en cola, CPU, memoria, rechazadas recientemente), /sessions y /config. También existe una exportación JSON de /metrics, pero requiere definir METRICS_JSON_PATH y no la usé. Además, la imagen ejecuta dumb-init como PID 1, que es la respuesta documentada a las quejas por procesos zombis que han acompañado a Chrome en contenedores durante años.

La realidad del setup: un comando, y cuatro cosas que nadie mete en ese comando

La línea de instalación que todos citan realmente es un solo docker run. Lo que la rodea es lo que debes planificar.

La imagen pesa 4.34 GB. Ese es el número que debe marcar tus expectativas, no la latencia de arranque. El manifiesto incluye linux/arm64 y linux/amd64; en mi host arm64, Docker descargó la variante nativa arm64. (El user-agent de Chrome dentro del contenedor sigue diciendo X11; Linux x86_64 — es el UA cosmético de Chrome en Linux, no emulación. uname -m devuelve aarch64. La gente abre bugs por esto.)

Usé --shm-size=2g en todas las mediciones. El entorno no incluyó una ejecución de control con el /dev/shm por defecto de Docker, así que este artículo no puede afirmar que 2 GiB sea universalmente obligatorio ni cuantificar el punto exacto de fallo. Ajusta el tamaño según tu número de navegadores y la carga de trabajo.

El token es una cuestión de despliegue, no un trámite. Sin él, cualquiera que pueda alcanzar el puerto 3000 controla un navegador en tu red.

La red del contenedor es tu problema. Mi fixture corría en el host, así que el contenedor llegó a él mediante host.docker.internal (colima lo mapea con --add-host host.docker.internal:host-gateway). Verifiqué que el contenedor realmente podía alcanzar el fixture con un curl en crudo antes de confiar en cualquier medición.

Mi entorno: colima 0.10.3 (6 CPU / 11.6 GiB) con Docker 29.2.1 en macOS 26.5.2 arm64. El entorno de pruebas usó solo la biblioteca estándar de Python 3. Para PNG y PDF comprobó firmas de archivo, no validez del decodificador, dimensiones, número de páginas, completitud ni fidelidad visual.

Un lanzamiento equivalente mínimo usa la imagen fijada, un token explícito y la asignación de memoria compartida usada aquí:

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

Después de que /pressure?token=... responda, un POST /content?token=... autenticado con un cuerpo JSON que incluya la URL de destino ejercita la ruta REST. En producción también necesitas reintentos limitados con jitter para las respuestas 429; reintentar de inmediato solo vuelve a competir por la misma cola llena.

El peaje del arranque, desglosado

Tres arranques nuevos con docker run, medianas con mínimo-máximo:

La fila del medio se presta a sobreinterpretación. No mide el arranque del navegador de forma aislada ni demuestra que Browserless arranque Chrome más rápido que una librería en proceso. Es un ida y vuelta HTTP al contenedor más trabajo del navegador, navegación y transferencia de la respuesta. La diferencia de unos 0.17 segundos entre la primera llamada y las posteriores podría incluir efectos de sistema de archivos, sistema operativo, Chrome, Node o caché del contenedor. Como los procesos de Chrome eran cero en reposo y el entorno no capturó un trazo CDP ni una línea temporal de procesos para estas llamadas, no puede atribuir esa diferencia a reutilización del navegador ni a un coste de arranque “amortizado”.

Además: estos son números de la VM de colima en macOS. Linux sobre metal se comportará distinto. No le cites 0.78 s a tu equipo de SRE como si fuera portable.

Prueba práctica: encontrar el techo desde ambos lados

El contrato CONCURRENT + QUEUED → 429 se repite por todas partes, pero no se demuestra en ninguna.

El montaje: una ruta de fixture que duerme 5 segundos en el servidor, de modo que cada solicitud ocupa de forma fiable una sesión durante un tiempo conocido. Luego lanza CONCURRENT + QUEUED + 4 solicitudes a la vez y observa qué devuelve, mientras un hilo de muestreo aparte consulta /pressure para leer la contabilidad interna del contenedor.

De esto salieron tres conclusiones.

El techo es exactamente CONCURRENT + QUEUED, siempre. Las respuestas correctas fueron 4, 8 y 10: la suma configurada en cada caso. Los rechazos coincidieron con el exceso, que fue 4 en las tres ejecuciones.

El techo se mueve. No es un valor fijo grabado en la imagen; es lo que tú configuras. Pasar de 4 → 8 → 10 cambiando variables de entorno es lo que hace que esto sea útil y no una curiosidad.

Y las dos señales son independientes. Los códigos de estado de mi cliente venían de respuestas HTTP reales; /pressure venía de la contabilidad interna del contenedor, consultada por otro hilo. Coincidieron en estas tres ejecuciones cortas. Eso convierte a /pressure en un posible indicador de producción, no en un contrato completo de autoescalado: todavía hay que validar la cadencia de muestreo, la semántica de reinicio, la agregación entre réplicas y el comportamiento con cargas mixtas más largas.

Hay un matiz que los conteos de aprobado/rechazado ocultan. Una solicitud en cola no falla: espera, y puede esperar bastante. En (2, 2) con trabajo de 5 segundos, las respuestas correctas llegaron entre 5.7 s y 11.0 s, con mediana de 8.3 s. Por tanto, la latencia extremo a extremo llegó aproximadamente a dos duraciones de sesión. El entorno no capturó marcas de tiempo separadas de admisión y ejecución, así que no puede asignar todo el retraso a la espera en cola.

Cómo se ve esto en un trabajo real

Supón que renderizas 4,000 páginas de producto a PDF cada noche y cada página tarda unos 5 segundos. Defines CONCURRENT=5, QUEUED=5. Tu techo de rendimiento es 5 páginas por 5 segundos — una página por segundo — así que el trabajo tarda unos 67 minutos si mantienes la tubería exactamente llena. Es aritmética basada en comportamiento medido, no un benchmark, pero es la aritmética que debes hacer antes de desplegar.

Cualquier solicitud que llegue después de que todas las ranuras de ejecución y cola estén ocupadas puede recibir un 429 de inmediato; lanzar todo a la vez no garantiza qué solicitud ordinal perderá la carrera. Un ejecutor de trabajos debería tratar esa respuesta como presión de retorno y usar reintentos limitados con jitter. Si no, corre el riesgo de perder páginas mientras la contabilidad general del trabajo sigue avanzando: un riesgo operativo, no un escenario de fallo demostrado por este entorno.

Prueba práctica: qué ven realmente los endpoints

Para probar la fidelidad del render de forma honesta, la página de fixture oculta su texto marcador a cualquiera que no esté ejecutando un navegador real. La cadena visible Runtime Injected Marker 88 se ensambla a partir de fragmentos de JavaScript en tiempo de carga, así que no existe ningún literal contiguo para ella en ningún byte enviado por el servidor. Una descarga estática simple de esa página devuelve 702 bytes que no contienen ninguno de los marcadores.

Que /content devuelva 811 bytes con el marcador inyectado significa que un Chromium real renderizó la página antes de que volviera el HTML. /scrape extrajo un valor de un nodo que no existe hasta que corre JavaScript. Ambos funcionaron con cero código de automatización del lado cliente — un único POST autenticado.

Ese es el argumento real. En la misma ronda de pruebas, un crawler estático se perdió por completo esta clase de contenido, y las librerías de navegador en proceso (chromedp, rod, Selenium) solo lo captaron después de que escribí una espera explícita. Browserless lo captó con una petición con forma de curl. Estás cambiando código de automatización por peso de despliegue.

Dos límites a esa afirmación. La evidencia cubre las clases de contenido de mi fixture, no una encuesta de la web moderna. Y /unblock, el endpoint anti-detección, se dejó deliberadamente sin tocar — ninguno de estos resultados debe leerse como una afirmación sobre capacidad anti-bot. /function, /download y /performance tampoco se probaron.

Prueba práctica: una comprobación breve de residuos

Chrome en contenedor tiene fama de dejar cadáveres, así que ejecuté 30 sesiones secuenciales con CONCURRENT=3 y conté procesos dentro del contenedor.

Antes de confiar en nada, calibré el detector. Mientras una sesión estaba en curso, el enumerador de /proc vio 11 procesos de la familia chrome (navegador, zygote, GPU, renderers, utilidades). Eso importa: demuestra que el instrumento ve Chrome, así que el cero posterior a la ejecución es una medición y no ceguera. Una prueba de fugas que informa “0 procesos” sin demostrar que puede contarlos no vale nada.

Después de 30 sesiones: 0 procesos chrome, 0 zombis. Los únicos supervivientes fueron dumb-init, node, Xvfb, start.sh y sh. /sessions mostró 0 en reposo.

Memoria del contenedor, desde docker stats (la cifra visible para el operador, no el RSS de un proceso individual):

Crecimiento neto en 30 sesiones: unos 9.5 MB, y la curva muestreada se aplanó después de la sesión 10. Eso no encaja con una fuga lineal simple por sesión en esta ventana corta. El calentamiento de Node es una explicación plausible, no algo que esta serie de procesos y memoria pueda demostrar.

Alcance: 30 sesiones secuenciales es un soak pequeño, no una prueba de resistencia ni de concurrencia. Las advertencias de EventEmitter listener de larga data en el rastreador de incidencias son el tipo de cosa que podría aparecer tras horas y miles de sesiones, y yo no ejecuté eso. La conclusión válida es solo que no se observaron procesos Chrome ni zombis acumulándose en esta ventana sobre v2.55.0.

El límite del timeout

TIMEOUT está documentado como un ajuste. Quería verlo entrar en acción.

Con TIMEOUT=5000, una sesión que intentó mantener una página durante 15 segundos devolvió HTTP 408 a los 5.007 s en lugar de quedarse colgada. Esta única observación confirma que se aplica cerca del límite configurado. No revela la implementación del temporizador ni prueba la liberación de la ranura; una prueba más sólida repetiría el intento, observaría que /sessions y /pressure vuelven al estado inactivo y después confirmaría que una solicitud siguiente adquiere la ranura liberada.

La trampa de migración: PREBOOT es inerte y no te avisa

De todo lo que medí, este es el resultado que más me gustaría que me hubieran dado antes de actualizar.

Browserless 2.0.0 eliminó PREBOOT y KEEP_ALIVE — el changelog dice que se retiraron por ser confusos, aportar poco y causar errores. Decisión razonable. El problema es lo que pasa cuando una configuración de v1 se copia y pega en v2, que es la forma más común de actualizar.

Ejecuté el contenedor con -e PREBOOT=true y lo comparé con el comportamiento por defecto:

Cada tiempo cae dentro del propio rango mínimo-máximo del brazo por defecto: es ruido, no un efecto. Y no hubo precalentamiento: el contenedor con PREBOOT=true permanece en reposo sin tener ningún navegador, igual que uno sin esa bandera. Otras dos señales, ninguna de ellas una cifra:

• /config no expone ninguna clave preboot. Las claves son concurrent, queued, timeout, token, maxCPU, maxMemory, retries y otras similares.
• Ningún error. Ninguna advertencia. Nada en los logs del contenedor.

Así que una configuración v1 con PREBOOT en v2 es un no-op silencioso en arranque normal y en una revisión de logs. La ausencia de la clave en /config más el comportamiento inalterado es la señal detectable; Browserless no emite un rechazo explícito ni un aviso. Una comprobación de migración debe inspeccionar la configuración aplicada en lugar de tomar un arranque verde como prueba de que cada variable de entorno surtió efecto.

KEEP_ALIVE es el caso opuesto, y no deben mezclarse. Se eliminó en la misma versión, pero no es silencioso — una comprobación puntual del contenedor muestra que registra Environment variable of "KEEP_ALIVE" is deprecated and ignored. justo en stdout. Eso sí es una advertencia dirigida al operador. No sometí KEEP_ALIVE al mismo entorno medido que PREBOOT, así que lo informo como una comprobación y no como una medición. Pero la dirección es lo bastante clara como para importar: solo PREBOOT es la trampa silenciosa. Browserless es más honesto con KEEP_ALIVE de lo que permitiría una síntesis general del tipo “v2 ignora tus flags de v1”.

Pros y contras

Pros

• Control de admisión que se comporta exactamente como está documentado y se ajusta con la configuración — probado en tres techos distintos, tanto en los códigos de estado del cliente como en la propia contabilidad del servidor.
• /pressure coincidió con los conteos visibles para el cliente de running, queued y rejected en tres ejecuciones cortas; vale la pena considerarlo como una entrada posible para autoescalado y alertas.
• Render real con Chromium y cero código de automatización del lado cliente: un POST autenticado mostró DOM inyectado por JS que una descarga estática de la misma página no puede ver.
• No se observaron procesos Chrome acumulándose en una ejecución secuencial de 30 sesiones; el conteo tras finalizar fue 0 procesos Chrome y 0 zombis.
• Una prueba de TIMEOUT devolvió 408 a los 5.007 s frente a un presupuesto de 5.000 s; la limpieza y la liberación de ranura no se verificaron por separado.
• Autenticación activada por defecto: los cuatro endpoints REST devuelven 401 sin token.
• Un docker run deja un servicio listo en unos 0.78 s, y el primer render llega 0.32 s después.

Contras

• Imagen de 4.34 GB. Ese es el coste real, y se nota en tu registry, en la caché de CI y en el tiempo de despliegue en frío.
• SSPL-1.0 o licencia comercial de Browserless. Evalúa los términos actuales exactos frente a tu modelo de despliegue y distribución.
• PREBOOT de v1 se acepta y se ignora silenciosamente en v2: sin error, sin aviso, sin clave en /config.
• Estás operando un servicio, no añadiendo una dependencia: un contenedor, un token, una ruta de red, un techo de admisión y responsabilidad de actualización.
• Las solicitudes en cola empujaron la latencia extremo a extremo a aproximadamente dos duraciones de sesión en la ejecución (2, 2); la espera en cola no se midió por separado.
• El tiempo REST medido incluye un salto HTTP y no aísla el coste de arranque del navegador ni prueba reutilización del navegador.

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

Browserless merece su peso cuando más de una cosa necesita un navegador. Un servicio de render compartido entre varias apps, un equipo que quiere capturas y PDFs detrás de un endpoint HTTP en lugar de una dependencia de Chrome en cada servicio, una cadena de trabajos que de verdad necesita un techo de capacidad con backpressure medible: ese es el perfil que encaja. Si ya ejecutas Docker y alguien se encarga del despliegue, la historia operativa es clara: admisión predecible, backpressure observable y sin procesos Chrome ni zombis acumulándose en la comprobación secuencial de 30 sesiones.

También es una buena decisión si la alternativa es que cada servicio de tu stack instale su propio Chromium. Centralizarlo en un solo contenedor con token y techo de capacidad es, de verdad, una buena decisión arquitectónica.

Evítalo si solo escribes un script. Descargar 4.3 GB y levantar un contenedor para que un único archivo Python capture una página renderizada es demasiada ceremonia para un trabajo pequeño — una librería de navegador en tu propio proceso lo hace sin desplegar un servicio aparte. Evítalo si los términos de SSPL no encajan con tu producto comercial y no puedes resolverlo. Evítalo si lo que realmente quieres es un navegador que llegue precalentado sin coste en frío, porque PREBOOT no te dará eso en v2. Y evítalo si tu problema real es el manejo anti-bot, porque eso vive en un endpoint que deliberadamente no probé y sobre el que no voy a dar garantías.

Alternativas, incluyendo dónde encaja Thunderbit

La comparación útil no es Browserless contra otro contenedor. Es dónde vive el navegador y quién se encarga de mantenerlo vivo.

Revisión relacionada: Browsertrix Crawler review.

Revisión relacionada: chromedp review.

Si quieres un navegador dentro de tu propio proceso y no te importa escribir las esperas, una librería es más ligera y no requiere despliegue. He desarrollado ese lado en la comparación Playwright vs Puppeteer y en el resumen de proyectos open source de scraping.

Si no quieres operar un navegador en absoluto, nuestro propio Thunderbit es una alternativa gestionada. Browserless devuelve material renderizado que tu código interpreta; Thunderbit puede devolver Markdown o datos que encajan con un esquema mientras el proveedor asume la infraestructura de renderizado. Este artículo no comparó la latencia, la capacidad, el comportamiento ante fallos, la calidad de extracción ni el coste de Thunderbit, así que la tabla describe fronteras de responsabilidad y no una comparación de rendimiento.

Lectura relacionada de la misma ronda de pruebas: la revisión de Crawl4AI cubre una canalización Markdown respaldada por navegador que tú mismo ejecutas, y la visión general de herramientas de web scraping mapea la categoría más amplia.

Prueba Thunderbit para extracción de datos web

Veredicto

¿Deberías usar Browserless? Sí, si varios consumidores necesitan trabajo de navegador, alguien puede operar el contenedor y tu revisión de licencia aprueba el modelo de despliegue. En tres pruebas sintéticas de admisión, el número aceptado coincidió con CONCURRENT + QUEUED, el exceso recibió 429 y /pressure coincidió con los conteos visibles para el cliente. En una comprobación separada de 30 sesiones secuenciales, no se acumuló ningún proceso Chrome ni zombi. Una prueba de timeout devolvió 408 cerca del límite configurado. Son observaciones útiles y acotadas, no garantías universales.

Eso sí, dimensiona el compromiso con honestidad. Es una imagen de 4.34 GB y un servicio que operas, no una dependencia que añades; esta prueba no estableció una comparación de velocidad con una librería de navegador en proceso. Lo que te da es un navegador que puedes racionar: un techo conocido y backpressure medible. En la comprobación secuencial de 30 sesiones no se observaron procesos Chrome ni zombis acumulándose. Los costes son el peso del despliegue y una licencia que debes leer. Si solo renderizas unas pocas páginas desde un script, ese intercambio no compensa. Si ejecutas una capa de render de la que dependen varios servicios, sí — solo revisa tus variables de entorno de v1 al entrar, porque PREBOOT se quedará ahí con pinta de estar trabajando mientras no hace absolutamente nada.

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

Preguntas frecuentes

¿Browserless hace que Chrome sin interfaz sea más rápido? Esta prueba no puede responder eso. El endpoint HTTP estuvo disponible 0.78 s después de docker run; la primera llamada a /content tardó luego 0.32 s y las llamadas posteriores en el mismo contenedor unos 0.15 s. Esas cifras combinan ida y vuelta HTTP, trabajo del navegador, navegación y transferencia de la respuesta. El entorno no aisló el tiempo de arranque, no trazó la reutilización de procesos ni publicó un benchmark comparable en proceso. Usa Browserless por su frontera de servicio compartido y su control de admisión, y luego mide tu propia ruta de latencia.

¿Qué pasa cuando superas el límite de concurrencia de Browserless? Recibes un HTTP 429 inmediato. El techo es exactamente CONCURRENT + QUEUED, y lo confirmé en tres configuraciones: (2,2) aceptó 4 y rechazó 4, (3,5) aceptó 8 y rechazó 4, (5,5) aceptó 10 y rechazó 4. El endpoint /pressure del servidor informó en todo momento conteos coincidentes de running, queued y recentlyRejected. Conviene saber esto: las solicitudes en cola no fallan, esperan — en (2,2) con trabajo de 5 segundos, las respuestas correctas tardaron entre 5.7 s y 11.0 s. Haz que tu cliente trate el 429 como presión de retorno con reintentos y backoff.

¿PREBOOT sigue funcionando en Browserless v2? No. PREBOOT se eliminó en 2.0.0, y v2 acepta -e PREBOOT=true sin error ni aviso, pero sin hacer nada con ello. Confirmé su inercia de tres maneras: la latencia era indistinguible del comportamiento por defecto, un contenedor PREBOOT=true en reposo tenía 0 procesos chrome esperando, y /config no expone ninguna clave preboot. Si migraste una configuración v1, tus instancias no están precalentadas. Nota: KEEP_ALIVE, eliminado en la misma versión, sí registra un aviso de "deprecated and ignored" — así que el problema de fallo silencioso es específico de PREBOOT.

¿Browserless es gratis para uso comercial? El repositorio ofrece SSPL-1.0 o una licencia comercial de Browserless, pero este artículo no asigna casos comerciales o de código cerrado concretos a ninguna de las dos opciones. Revisa el LICENSE actual y la guía oficial de despliegue, y luego pide a la persona responsable de licencias que evalúe tu modelo de despliegue y distribución.

¿Browserless deja procesos zombis de Chrome? No se acumuló ninguno en la ventana corta probada. Tras 30 sesiones secuenciales, el contenedor tenía 0 procesos Chrome y 0 zombis, con solo dumb-init, node, Xvfb, start.sh y sh en ejecución. El detector contó 11 procesos de la familia chrome mientras una sesión estaba activa, así que no estaba ciego. La memoria del contenedor pasó de 294 MiB a 303 MiB y luego se aplanó en las muestras. Esto no es una prueba de resistencia de varias horas, con concurrencia o de miles de sesiones.