¿Cuántos vCPU dedicados necesita un VPS para web scraping con Chrome headless?

¿Cuántos navegadores headless puede ejecutar cada plan?

Un navegador Chrome headless necesita entre 1,5 y 2 vCPU: dos reglas publicadas caen en ese rango. Playwright Test inicia, por defecto, la mitad de workers que núcleos de CPU lógicos hay. BrowserStack, que se dedica a ejecutar navegadores reales, pide a sus clientes autoalojados 1,5 CPU por navegador en Linux para sitios web estándar, y al menos 2 para sitios intensivos o uso las 24 horas. Aplicado a cada plan:

¿Por qué Chrome headless consume tanta CPU?

Un navegador headless hace todo lo que hace uno visible excepto pintar en una pantalla. Descarga la página, analiza el HTML y el CSS, ejecuta todos los scripts, maqueta la página y mantiene los temporizadores activos. Chromium reparte ese trabajo entre varios procesos: un proceso de navegador que gestiona al resto, y procesos de renderizado para el contenido web, con cada nueva pestaña o ventana abriéndose, por regla general, en el suyo. Diez pestañas cuestan casi lo que diez renderizadores en CPU.

Tres cambios recortan la factura sin cambiar el resultado:

• Bloquea lo que nunca se lee. Las imágenes, fuentes y multimedia cuestan ancho de banda y tiempo de decodificación; la interceptación de peticiones en Puppeteer o el enrutado en Playwright los rechazan.
• Reutiliza un navegador, abre contextos nuevos. Arrancar Chrome es el paso caro; un contexto o una página nuevos dentro de un navegador en marcha son mucho más baratos.
• Sáltate el navegador cuando los datos lo permitan. Los datos que están en el HTML o en una API JSON que llama la página vuelven de un cliente HTTP simple, que no ejecuta ningún script.

Desde Chrome 132, el modo headless antiguo se distribuye solo como binario separado, chrome-headless-shell; --headless en Chrome normal ejecuta el modo nuevo.

¿Importan las vCPU dedicadas para los workers de scraping?

Un navegador falto de recursos falla en vez de ir más lento. Los timeouts de navegación y de selector se definen en segundos. Cuando un vecino consume tiempo de CPU, las páginas terminan de renderizarse tarde, las esperas expiran y un trabajo que habría funcionado se reintenta, lo que consume más CPU. Browserless, que vende Chrome alojado, lo indica en su documentación: una menor concurrencia da a cada navegador más CPU y memoria, reduce los timeouts y mejora la estabilidad. El tiempo de CPU perdido aparece como steal, explicado en qué es el tiempo de CPU steal y cómo comprobarlo en un VPS.

En Cobaltfell el lado de la CPU de ese intercambio está fijado. Una vCPU es un hilo de hardware del procesador del host. Los tuyos están fijados uno a uno a tu VPS y nunca se prestan a otro cliente, y los dos hilos de un núcleo físico permanecen juntos, así que cada 2 vCPU forman un núcleo entero que ningún vecino comparte. Se permite la carga completa durante todo el tiempo que tu trabajo lo necesite: sin créditos de CPU, sin ventana de ráfaga y sin limitación tras unos minutos al 100 %.

La concurrencia se averigua igual en cualquier proveedor: empieza con un navegador por cada dos vCPU, súbela mientras la tasa de errores se mantenga estable y detente en el primer aumento de los timeouts.

Los proveedores que venden vCPU dedicadas, clasificados con los mismos criterios por escrito, están en cuál es el mejor proveedor de VPS con CPU dedicada en 2026.

¿Cómo ejecuto workers de Chrome de forma segura en un VPS?

Mantén activado el sandbox de Chrome, ejecútalo como un usuario normal y dale al contenedor un proceso init. Las páginas scrapeadas son código no confiable por definición, y las guías oficiales coinciden en cada punto:

• Sandbox. La guía de solución de problemas de Puppeteer califica de muy desaconsejado ejecutar sin sandbox. La guía de Docker de Playwright señala que ejecutar como root desactiva el sandbox de Chromium, y recomienda un usuario aparte más su perfil seccomp para scraping y rastreo (crawl).
• Proceso init. Ambas guías recomiendan la opción --init de Docker, para que los procesos hijos de Chrome terminados se recojan en vez de acumularse como zombis.
• Memoria compartida. Playwright recomienda --ipc=host para Chromium, porque sin ella Chromium puede quedarse sin memoria y fallar.

Dos cifras indican cómo va un pool: la memoria que ocupan todos los procesos de Chrome y la columna steal de mpstat.

# total resident memory of chrome / chromium / headless shell processes, in MB
ps -eo rss=,comm= | awk '/chrom/ {s+=$1} END {printf "%.0f MB\n", s/1024}'

# how many renderer processes are alive right now
pgrep -fc -- '--type=renderer'

# per-vCPU load and %steal while the pool works (package sysstat)
mpstat -P ALL 5 3

¿Y las normas de los sitios web y los proxies?

El scraping se mantiene dentro de los términos de cada sitio y de la ley que se aplica al operador y al sitio. Esta página dimensiona la máquina, no la legalidad de un proyecto. Los ataques a sistemas que no son tuyos, incluidos el fuerza bruta y la denegación de servicio, están prohibidos según lo que permite la política de uso aceptable de Cobaltfell, así que los ritmos de peticiones se mantienen moderados.

Los proxies y la rotación de IP son un tema aparte, y Cobaltfell no vende ninguno de los dos. Cada VPS recibe una dirección IPv4 y una IPv6 /64 en un puerto de 1 Gbit/s. El tráfico mensual de tu plan cuenta solo los datos salientes, y pasarse nunca añade un cargo por sí solo. Los precios de los planes aparecen en cuánto cuesta un VPS con núcleos dedicados.