Un Parámetro, 3.8× Menos CPU: Kitesurf Saca Chromium de Browser Run (y te Cuesta 1.7× en Tiempo)
Por Devy · Categoría: Herramientas de IA — General (Cat 10)
Si ya tienes algo ejecutándose en Browser Run — un scraper, una pipeline de capturas de pantalla, un agente que lee páginas — el cambio que Cloudflare implementó el 6 de agosto es una cadena de consulta:
browser=kitesurf
Esa es toda la migración. El mismo endpoint, el mismo Protocolo de Chrome DevTools, el mismo cliente de Puppeteer o Playwright. Lo que cambia por debajo es que ya no hay Chrome. Kitesurf es un navegador que Cloudflare construyó desde cero sobre Workers — Rust y WebAssembly ejecutándose dentro de aisladores V8 — y explícitamente no intenta ser un navegador para que la gente lo mire.
Ese es el intercambio, y es real en ambas direcciones. Midámoslo antes de decidir nada.
Los números, lado a lado
Cloudflare publicó una comparación contra una instancia de Chromium caliente. Estas son sus cifras, auto-reportadas, en dos operaciones que la mayoría de las pipelines de agentes realmente hacen:
| Kitesurf | Chromium (caliente) | ||
|---|---|---|---|
| CPU — captura de pantalla | 380 ms | 1.173 ms | 3.1× menos |
| CPU — extracción de HTML | 229 ms | 877 ms | 3.8× menos |
| Memoria — captura de pantalla | 57,8 MiB | 271,0 MiB | 4.7× menos |
| Memoria — extracción de HTML | 39,4 MiB | 273,7 MiB | 7.0× menos |
| Tiempo real — captura de pantalla | 1.148 ms | 637 ms | 1.8× más lento |
| Tiempo real — extracción de HTML | 820 ms | 472 ms | 1.7× más lento |
Lee primero la columna de memoria, porque es la que describe algo diferente que las otras. 39 MiB versus 274 MiB por página no es «más rápido» — es cuántas páginas caben a la vez. Con un presupuesto por página que se reduce 7×, la concurrencia deja de ser lo que limita tu pipeline. La columna de CPU es lo que aparece en la factura. La columna de tiempo real es lo que tu agente siente.
Y la columna de tiempo real va en la dirección equivocada. Cloudflare no lo oculta ni lo explica: un JIT calentado le gana a un renderizador por software, y Kitesurf renderiza por software. Si tu carga de trabajo es una página a la vez y un humano está esperando, esto es una degradación. Si tu carga de trabajo es diez mil páginas y nadie está esperando, acabas de reducir CPU aproximadamente 3–4× y memoria 5–7× por el precio de un parámetro de consulta.
El tutorial: mide tu propio antes y después
No confíes en la tabla — fue medida en las páginas de Cloudflare, no en las tuyas. Todo el punto de un cambio de un parámetro es que hacer pruebas A/B es casi gratis.
Paso 1 — Ejecuta la operación que realmente te importa, en Chromium. El endpoint de acción rápida es suficiente para obtener una línea base:
curl -X POST \
'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot' \
-H 'Authorization: Bearer <apiToken>' \
-H 'Content-Type: application/json' \
-d '{"url": "https://the-site-you-actually-scrape.com"}'
Paso 2 — Agrega el parámetro. No cambies nada más.
curl -X POST \
'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
-H 'Authorization: Bearer <apiToken>' \
-H 'Content-Type: application/json' \
-d '{"url": "https://the-site-you-actually-scrape.com"}'
Paso 3 — Si lo controlas con Puppeteer o Playwright, el parámetro va en el endpoint de WebSocket, no en el código:
const browser = await puppeteer.connect({
browserWSEndpoint: `wss://…/v4/accounts/${accountId}/browser-run/…?browser=kitesurf`
});
Tus selectores, tus esperas, tu lógica de extracción — nada de eso cambia. Kitesurf habla CDP, así que chrome-remote-interface y clientes MCP funcionan de la misma manera: agrega la cadena de consulta a --wsEndpoint y listo.
Paso 4 — Compara tres cosas, no una. Tiempo real (que empeorará), tiempo de CPU en la invocación (que debería bajar), y — la que la gente olvida — si la salida es la misma. Diff el HTML extraído. Mira los dos capturas. Esa comparación es la decisión real, y toma una tarde.
También hay un playground en kitesurf.cloudflare.app donde puedes apuntarlo a una URL e inspeccionar el resultado con Chrome DevTools, incluyendo un panel de memoria mostrando la huella de WebAssembly por aislador. Útil para un primer vistazo antes de que conectes algo.
Qué realmente se rompe
Esta es la mitad del artículo que decide si migras. Kitesurf no admite:
- WebGL — cualquier cosa que renderice canvas-3D no muestra nada
- Reproducción de video
- Fingerprinting de TLS para desafíos de bots — si tu sitio objetivo tiene una puerta, no pasas
- Sesiones autenticadas persistentes más allá de ~10 minutos — flujos de sesión iniciada largos están fuera
- Renderización pixel-perfecta — deliberadamente, esta es la premisa del diseño
- Desplazamiento de 60 fps
Notice la forma de esa lista. Todo en ella es algo que un humano necesita de un navegador. Kitesurf pasa 215.000+ Web Platform Tests, así que no es que el motor sea delgado — es que las partes que omitió son las partes que un agente leyendo una página nunca pide. Se construye sobre Blitz, el motor de renderización modular de código abierto, con Stylo para CSS y Parley para la formación de texto.
La regla práctica: la carga de trabajo que se mueve es aquella donde la salida es texto o una imagen aproximada, en volumen, desatendida. Scraping, extracción de HTML, alimentar páginas a un modelo, generación de miniaturas. La carga de trabajo que se queda en Chromium es pruebas de regresión visual, cualquier cosa detrás de un login largo, cualquier cosa con un video o un canvas 3D, y cualquier cosa donde una persona está mirando un spinner.
Nada te detiene de dividir los dos — es la misma API, y el parámetro es por solicitud.
Dos preguntas abiertas que vale la pena mantener
El arranque en frío no está en la tabla. Cada cifra de Chromium que Cloudflare publicó es contra una instancia caliente, y lo dicen. Pero el arranque en frío es exactamente donde un aislador V8 debería demoler un proceso de navegador, y es la medición que falta de una tabla de benchmark que de otra manera tiene todo. Su ausencia es extraña en la dirección que los favorecería. Si tu pipeline es ráfagas en lugar de estado estable, ese es el número que querrías, y tendrás que medirlo tú mismo.
Nadie ha respondido la pregunta anti-bot. Un navegador ejecutándose en la propia red de Cloudflare, obteniendo páginas protegidas por Cloudflare — alguien en el hilo de lanzamiento preguntó si el tráfico de Kitesurf se trata diferente al de cualquier otro, y nadie del equipo respondió. No es una acusación, es una pregunta sin respuesta, y es la primera cosa a probar si los sitios que obtienes están detrás de Cloudflare.
Cloudflare dice que planea lanzar Kitesurf como código abierto — la palabra usada es «esperemos que pronto» — con el objetivo de permitir que los clientes ejecuten su propia instancia en su propia cuenta. Ese es un plan, no un artefacto enviado. Hoy la única forma de ejecutarlo es el beta alojado, que es gratuito con límites de uso por cuenta.
Dónde se sienta esto
Cubrimos Browser Run cuando Cloudflare convirtió un Chrome headless en un endpoint HTTP, y Lightpanda cuando un equipo independiente argumentó que un navegador para agentes no debería ser un navegador para humanos con la pantalla apagada.
Kitesurf es Cloudflare concediendo ese argumento dentro de su propio producto. El argumento completo de Browser Run fue hacer que Chrome fuera fácil de llamar; el seguimiento es hacer que Chrome sea opcional. Lightpanda hizo el caso; lo interesante aquí es quién lo está haciendo ahora, y que adjuntaron números.
¿Y tú? Si intercambiaras un parámetro en tu pipeline de scraping más pesado hoy, ¿qué importaría más — la CPU que dejas de pagar, o el tiempo real que estarías agregando a cada solicitud?
Fuentes: