Rendimiento del navegador: optimización a escala

Mida primero la carga

La capacidad depende de las páginas, el modo del navegador, la duración de la sesión, la ruta de red y la concurrencia de la aplicación. Mida esos factores juntos antes de cambiar memoria, CPU, red o ciclo de vida. El objetivo es completar el trabajo con estabilidad y protección de privacidad coherente, no alcanzar el mayor número posible de workers.

Una carga breve de texto no cuesta lo mismo que una sesión larga con vídeo, capturas o descargas. Planifica la capacidad con la mezcla real de trabajos y conserva margen para arranques simultáneos, reintentos y recuperación.

Por qué importa la optimización del rendimiento

Quedarse sin memoria puede detener BotBrowser a mitad de operación, producir resultados incompletos y dañar el estado de la sesión. Las CPU sobrecargadas ralentizan cada instancia y aumentan los tiempos de carga y los fallos por tiempo de espera. El crecimiento descontrolado de procesos huérfanos de BotBrowser termina por agotar los recursos del sistema.

A escala, las pequeñas ineficiencias se acumulan. El uso de memoria, la latencia y los cierres incompletos afectan directamente los costes de infraestructura y la capacidad operativa. Mide cada carga con sus páginas, perfiles y rutas de red reales.

La optimización del rendimiento también es una cuestión de fiabilidad. Un host sin margen de memoria puede convertir una salida del navegador en una interrupción más amplia. Reserva capacidad para variaciones normales e inicios concurrentes.

Construye una referencia de capacidad

Clases de carga

Clasifica los trabajos por lo que hacen y por el tiempo que mantienen recursos activos:

• Navegación breve: una página sencilla y pocas interacciones.
• Aplicación compleja: sesiones más largas, marcos y estado activo.
• Trabajo visual: vídeo, Canvas, capturas y documentos.
• Transferencia de datos: descargas, cargas y rutas de red con mayor latencia.

Mide cada clase en el host, modo de navegador, perfil y ruta previstos. No extrapoles una cifra obtenida con una página vacía.

Desglose de consumo de memoria

Componente	Principal fuente de variación
Sesión	Duración, páginas abiertas y estado conservado
Trabajo visual	Complejidad de la página, vídeo y capturas
Aplicación	DOM, JavaScript y operaciones activas
Transferencia	Descargas, cargas y latencia de la ruta
Observabilidad	Registros y artefactos aprobados

Las aplicaciones grandes, las imágenes, los medios y las estructuras DOM complejas aumentan el consumo. El dimensionamiento debe partir de mediciones de la carga objetivo.

Sobrecarga de carga de perfiles

Incluye la validación del perfil, la preparación de la ruta y la primera navegación en la medición de arranque. Conserva la misma versión durante cada comparación.

Decisiones operativas

Sobreaprovisionamiento

La capacidad adicional aporta margen, pero no corrige colas sin límite, cierres incompletos o un backend gráfico inadecuado. Mide la carga antes de añadir hosts.

Bloqueo de recursos

Bloquear medios innecesarios puede reducir el trabajo de red y renderizado. Conserva los recursos necesarios para diseño, interacción, autenticación y validación de privacidad. Prueba los cambios con páginas representativas.

Configuración de la versión

Mantén la configuración documentada de la versión. Cambiar opciones de seguridad o renderizado para ahorrar recursos puede alterar el comportamiento de las páginas y complica la comparación.

Reutilización

Reutiliza una página solo mientras represente la misma sesión y el mismo plan de identidad. Crea un contexto nuevo cuando el almacenamiento o el perfil deban separarse, y cierra por completo el contexto anterior.

Enfoque de BotBrowser

El coste depende de la página, el modo gráfico, la concurrencia, la ruta y la duración de la sesión. Usa una referencia estable y mide la carga completa.

Para despliegues que evalúan flujos por contexto, Per-Context Fingerprint de BotBrowser (ENT Tier3) ofrece otra opción compatible. Compárala con la topología actual usando la misma carga autorizada y los mismos requisitos de privacidad. El resultado es evidencia específica de esa carga, no un compromiso general de capacidad.

Controles operativos

Gestión de memoria

Mide la tendencia de memoria con páginas representativas. Cierra cada página y contexto al terminar, limita la cola de trabajo y recicla el proceso cuando la política operativa lo requiera. El límite adecuado del heap depende de la aplicación y debe validarse antes de producción.

Almacenamiento de perfiles

Almacena los perfiles en almacenamiento local rápido, no en volúmenes montados por red:

# Copiar perfiles de NFS a SSD local
cp /mnt/nfs/profiles/*.enc profiles/

# Usar ruta local para carga de perfiles
chromium-browser --bot-profile="profiles/profile.enc"

La carga de perfiles ocurre una vez al inicio. Su coste relativo depende del flujo completo de arranque. En despliegues que reinician instancias con frecuencia, el almacenamiento local puede reducir la demora de red en la ruta de inicio.

Optimización de CPU

Conserva el modelo multiproceso y las capacidades gráficas normales de Chromium. Regula la concurrencia con una cola limitada y aumenta la carga por etapas. Una página con JavaScript prolongado, medios o Canvas necesita más capacidad que una navegación sencilla.

Optimización de red

Bloquea tipos de recursos innecesarios para reducir el ancho de banda:

// Playwright
await context.route('**/*.{png,jpg,gif,svg,ico}', route => route.abort());
await context.route('**/*.{mp4,webm,ogg}', route => route.abort());

// Solo bloquea recursos que no necesitas
// Mantén CSS y fuentes si la representación de texto importa

Define rutas selectivas solo cuando el plan de red lo requiera. Mantén navegación y recursos en una política coherente. Consulta la guía de rutas selectivas cuando determinados destinos deban usar una ruta directa separada.

Mantén la preparación del proxy en la configuración de red aprobada. Reutiliza una ruta validada solo mientras sus credenciales, región y salida no cambien, y vuelve a validarla después de cualquier modificación.

Gestión de instancias paralelas

Coloca una cola acotada entre el trabajo entrante y la capacidad del navegador. Admite trabajo nuevo solo mientras la CPU, la memoria, la demora de la cola y la tasa de errores medidas permanezcan dentro del intervalo operativo aprobado. Cuando aumente la presión, pausa la admisión o reduce el ritmo de despacho en lugar de crear más sesiones.

Define con claridad la propiedad de cada tarea. El planificador debe distinguir trabajo en espera, activo, terminado, cancelado e incierto para que la recuperación no duplique tareas de forma silenciosa. Aplica límites y demora de reintentos en la cola, y devuelve capacidad únicamente después de que la sesión anterior se cierre correctamente.

Revisa la contrapresión con clases de carga representativas. Un recorrido multimedia, una navegación corta y un flujo autenticado largo pueden necesitar grupos de programación diferentes. Mantén cada grupo dentro de su presupuesto medido y amplíalo gradualmente cuando el candidato de versión permanezca estable.

Monitoreo y seguimiento de recursos

Registra el estado de salida del navegador, la finalización de tareas, la tendencia de memoria, el tiempo de apertura y cierre y la profundidad de la cola. Usa las herramientas normales del sistema operativo y conserva stderr para distinguir una configuración de perfil no válida de la presión de recursos.

Ciclo de vida bajo carga alta

BotBrowser 150.0.7871.46 mejora la estabilidad de cargas headless y de alta concurrencia que crean páginas, procesos de trabajo, capturas y BrowserContexts de forma repetida. Combina este comportamiento con control de ritmo en la aplicación, colas limitadas y un cierre completo.

Calienta cada proceso antes de medir. Define un límite de concurrencia, encola el trabajo adicional y cierra por completo los contextos cuya identidad ya no sea necesaria. Conserva el estado de salida del navegador y stderr para separar problemas del perfil de la presión de recursos. En Linux, usa el mismo backend gráfico entre procesos comparables.

Para la identidad por contexto, aplica el perfil antes de iniciar la primera página o proceso de trabajo. Los controles operativos compatibles pueden cambiar después, pero un contexto activo debe mantener la misma identidad de familia de navegador.

Validación

Valida una sola optimización cada vez con una carga de preproducción controlada. Compara la finalización de tareas, el estado de salida del navegador, la tendencia de memoria, la latencia de creación de páginas, las capturas y el cierre de contextos con la configuración de versión sin cambios. Mantén constantes la familia de perfil, la ruta del proxy, el backend gráfico y el conjunto de páginas.

Usa la guía Linux GPU Backend cuando el despliegue no tenga pantalla física. Mantén activo el soporte gráfico salvo que el backend documentado requiera otra configuración. Un cambio que elimina una capacidad necesaria del navegador no es una mejora válida de rendimiento.

Aceptación de versiones y evidencias de recuperación

Compara fases operativas representativas

Un candidato de versión debe medirse frente a la referencia aprobada con las mismas clases de trabajo y la misma imagen del host. Separa el arranque en frío, el trabajo estable y el cierre controlado. El arranque en frío muestra si los workers nuevos pueden entrar en servicio de forma predecible. La fase estable permite revisar si la espera en cola y el uso de recursos se mantienen controlados cuando las cachés y conexiones ya se han asentado. El cierre confirma que la capacidad vuelve después de trabajos completados, cancelados y fallidos.

Mantén cada fase el tiempo suficiente para observar la variación normal de las páginas y de la ruta de red. Compara distribuciones de duración y espera, junto con presión sostenida de memoria, contención de CPU, actividad de almacenamiento y uso de red. Una ejecución breve y correcta sirve para comprobar compatibilidad básica, pero no basta para aprobar un presupuesto de producción.

Documenta la mezcla de trabajo que respalda la decisión. Incluye tareas ordinarias, la sesión admitida más larga y un caso de fallo autorizado. Así, el registro seguirá siendo útil cuando cambien la aplicación, la ruta, la imagen del host o la versión del navegador.

Aplica criterios explícitos de aceptación

La aceptación debe confirmar que el servicio completa el trabajo requerido y conserva margen operativo. Revisa de forma conjunta la finalización correcta, el tratamiento esperado de errores, el crecimiento de la cola, la limpieza y el tiempo de recuperación. Una versión no debe aprobarse solo porque mejora las tareas rápidas si las tareas más pesadas pierden fiabilidad.

Usa el objetivo de servicio vigente como límite de decisión. Si todavía no existe un objetivo formal, establece uno a partir de la versión actualmente aprobada antes de comparar el candidato. Registra cualquier compromiso deliberado, por ejemplo una latencia algo mayor a cambio de menor presión sostenida de memoria, y obtén la aprobación del responsable de la aplicación.

Incluye las comprobaciones funcionales y de privacidad en el mismo plan. Un cambio que reduce recursos eliminando comportamiento necesario de renderizado, almacenamiento, medios o red sigue siendo una regresión. La evidencia de rendimiento solo respalda la versión cuando el flujo representativo conserva su resultado autorizado.

Prueba la contrapresión y la recuperación

La prueba de aceptación debe incluir un periodo en el que las llegadas superen la capacidad disponible. Confirma que la cola acotada aplica la política de admisión prevista, protege el trabajo en curso y vuelve a su rango normal cuando baja la demanda. Comprueba también que los reintentos esperan según la política, en lugar de añadir presión de inmediato.

Prueba además una interrupción controlada de un worker. El supervisor debe reconocer su ausencia, conservar un resultado claro para la tarea y admitir reemplazos solo cuando exista capacidad. El trabajo completado no debe repetirse de forma silenciosa, y el trabajo incierto debe seguir la política de conciliación de la aplicación.

Después de la interrupción, verifica que la memoria, la actividad de almacenamiento, la espera en cola y la duración de las tareas regresan al rango aprobado. Un servicio que vuelve a aceptar trabajo mientras la limpieza sigue incompleta aún no se ha recuperado. Mantén la admisión reducida hasta que el flujo y el margen del host estén estables.

Conserva evidencias para la reversión

Cada cambio de rendimiento necesita una condición de reversión y una persona responsable. La condición puede ser crecimiento sostenido de la cola, menor fiabilidad de finalización, limpieza incompleta o pérdida del margen de recuperación. Defínela antes del despliegue para evitar interpretaciones improvisadas durante un incidente.

Conserva el identificador de versión, la imagen del host, el manifiesto de trabajo, la clase de ruta, el registro de configuración, la ventana de observación y los resultados resumidos del candidato y de la referencia. Guarda los registros según la política de retención y acceso, sin credenciales, contenido de páginas ni datos personales.

En un despliegue gradual, amplía el alcance solo cuando la etapa anterior cumpla los criterios durante una ventana de observación adecuada. Si aparece una condición de reversión, detén la expansión, reduce admisiones, completa o concilia el trabajo aceptado y restaura la última configuración aprobada. Repite la referencia representativa después de revertir para confirmar la recuperación completa.

Notas de producción

Comienza con los valores predeterminados, optimiza los cuellos de botella. Perfila tu carga de trabajo real antes de aplicar optimizaciones. Las limitaciones de memoria, saturación de CPU y ancho de banda de red son diferentes cuellos de botella con diferentes soluciones.

Cierra las páginas completadas. Llamar a page.close() marca un límite claro del ciclo de vida. Navegar a otra URL no termina la propiedad de la página.

Usa domcontentloaded en lugar de networkidle0 para velocidad. La estrategia de espera networkidle0 espera a que toda la actividad de red se detenga, lo cual puede tomar segundos en páginas pesadas. domcontentloaded se dispara cuando el DOM está listo, lo cual es suficiente para la mayoría de las tareas de extracción de datos.

Establece tiempos de espera realistas. Define el límite a partir del recorrido y trata el vencimiento como un resultado controlado.

Supervisa la memoria de forma continua. Define alertas según la capacidad medida del host y el objetivo de servicio. Observa tendencias antes de llegar al agotamiento.

Recicla instancias según la tendencia. Reinicia procesos cuando la política operativa o la tendencia de recursos lo indiquen, después de cerrar correctamente sus contextos.

Evalúa Per-Context Fingerprint como opción de despliegue. Si tu licencia lo admite, compara el flujo compatible por contexto con el despliegue actual bajo la misma carga representativa. Planifica la capacidad con resultados medidos.

Preguntas frecuentes

¿Cuánta memoria necesita una instancia?

Mide páginas representativas en el host objetivo. Los medios, iframes, extensiones y la complejidad de la página pueden cambiar mucho el consumo. Reserva margen para el sistema operativo y los inicios concurrentes.

¿El modo headless ahorra memoria?

Puede reducir parte del trabajo del sistema de ventanas, pero la página sigue usando renderizado, red, JavaScript y recursos gráficos. La diferencia depende de la carga.

¿Debo desactivar el soporte gráfico?

Mantén activo el soporte gráfico. Eliminarlo puede cambiar las capacidades de renderizado e impedir que funcionen cargas que dependen de WebGL o WebGPU. Consulta la guía Linux GPU Backend para hosts headless.

¿Cómo manejo un cierre incompleto del navegador?

Llama a browser.close() en todas las rutas de salida y usa el supervisor del despliegue para identificar workers sin respuesta. Confirma que la capacidad del host vuelve a su rango normal después de cancelaciones y errores.

¿--bot-time-scale afecta la carga de páginas?

Este ajuste controla la presentación temporal asociada al perfil. Mide por separado la finalización de páginas y conserva el mismo valor entre procesos comparables.

¿Cuándo debo añadir capacidad?

Añade capacidad cuando una carga sostenida deje de cumplir el objetivo de servicio después de verificar las colas y el cierre. Usa tendencias de CPU, memoria, finalización de tareas y salidas del navegador en lugar de un umbral fijo.

¿Qué impacto tiene el proxy?

Un proxy añade latencia de red. Mantén la ruta estable durante la medición comparativa y acerca la salida a la región necesaria cuando el flujo lo permita.

Decisiones de capacidad

La optimización del rendimiento para BotBrowser se trata de maximizar la densidad de instancias mientras se mantiene la estabilidad y consistencia de huella digital. Enfócate en la gestión de memoria a través de límites de heap y reciclado de instancias, eficiencia de CPU a través de parámetros de funciones y límites de concurrencia, y optimización de red a través de bloqueo de recursos y configuración de proxy.

Para configuración de infraestructura, consulta Configuración de servidor headless y Guía de despliegue con Docker. Para referencia de parámetros CLI, consulta Recetas CLI. Para optimización específica de capturas de pantalla, consulta Mejores prácticas de capturas de pantalla.