El 6 de agosto de 2026, Cloudflare lanzó Kitesurf, un navegador diseñado no para personas, sino para agentes. No hay Chromium en su interior: el motor está construido en Rust, compilado en WebAssembly y funciona completamente en aislamientos V8 en Workers. La compañía afirma que en tareas típicas de agentes consume de 3 a 7 veces menos CPU y memoria que Chromium. Cuatro meses antes, el proyecto de código abierto Obscura —también en Rust, también "para agentes"— había acumulado más de 22 mil estrellas en GitHub, y Cloudflare reconoció directamente que el primer prototipo de Kitesurf fue un puerto de Obscura en Workers.
El mercado de motores para automatización se ha dividido: por un lado, están los ligeros runtimes para agentes que ahorran recursos; por otro, las pesadas compilaciones de Chromium que pueden hacer de todo, incluyendo pasar verificaciones anti-bots. Analicemos los hechos sobre lo que cada clase realmente ofrece y dónde termina el ahorro.
¿Qué criterios usar para comparar?
Los benchmarks de motores suelen medir velocidad y memoria, pero para el scraping en producción y los agentes son importantes cuatro ejes independientes, y una ventaja en el primero no dice nada sobre los demás:
- Costo de inicio — CPU y memoria por página. Esto se traduce directamente en la factura de infraestructura con miles de sesiones paralelas.
- Completitud de la plataforma web — cuántos sitios modernos se renderizan correctamente. Aquí se mide con la cobertura de Web Platform Tests (WPT).
- Capacidad para superar anti-bots — si la sesión sobrevivirá al apretón de manos TLS, al desafío de JS y a la verificación de comportamiento.
- Control de salida a la red — si puedes gestionar desde qué IP y qué ASN el sitio ve la solicitud.
Kitesurf: ahorro frente a completitud
Kitesurf está compuesto por módulos: renderizado y análisis de HTML/CSS en Blitz, motor CSS Stylo de Firefox, runtime JS Boa en Rust, y formateo de texto a través de Parley. Según la compañía, el desarrollo tomó 12 semanas.
Números del benchmark propio de Cloudflare contra Chromium:
- CPU por captura de pantalla — 380 ms contra 1173 ms (3,1 veces menos);
- CPU para extracción de HTML — 229 ms contra 877 ms (3,8 veces menos);
- memoria por captura de pantalla — 57,8 MiB contra 271 MiB (4,7 veces menos);
- memoria para extracción de HTML — 39,4 MiB contra 273,7 MiB (7 veces menos);
- sin embargo, en tiempo de ejecución Kitesurf es más lento: 1148 ms contra 637 ms en la captura de pantalla y 820 ms contra 472 ms en HTML — de 1,7 a 1,8 veces.
Es un intercambio honesto: pagas con latencia, pero obtienes la posibilidad de mantener en una sola máquina muchas más sesiones paralelas. Según los estándares web, el motor se mantiene razonablemente bien para su edad — en el momento del anuncio, había pasado alrededor de 215 mil subpruebas de WPT, y en la documentación ahora se afirma que son más de 235 mil. Cobertura por secciones: DOM 97%, HTML 96%, Selection 99%, SVG 97%, Encoding 99%, CORS 95%, XHR 95%, URL 83%. Wikipedia, Hacker News y SPAs típicas se renderizan.
Kitesurf se conecta de manera habitual: punto final CDP (lo que significa que es compatible con Puppeteer y Playwright), MCP para agentes, puntos finales REST Quick Actions para captura de pantalla y extracción de HTML. Solo necesitas agregar el parámetro browser=kitesurf. La beta es gratuita, pero con límites por cuenta; prometen abrir el código fuente.
Lo que Kitesurf no puede hacer — y está escrito en su propia documentación
La lista de limitaciones es corta, pero abarca toda la línea de defensa de los sitios modernos. Kitesurf no soporta:
- reproducción de video;
- renderizado WebGL;
- apretón de manos del desafío anti-bots con huellas TLS reales;
- sesiones autorizadas largas que requieren un estado constante.
El tercer punto es clave. Cloudflare mismo escribe: si la tarea se enfrenta a un desafío anti-bots, utiliza el Chromium normal en Browser Run. Es decir, la compañía que establece estos desafíos en millones de sitios advierte honestamente que su propio navegador ligero no los supera. Esto no es una falta de la beta, sino una consecuencia de la arquitectura: la huella TLS (JA3/JA4) se genera en la pila de red, no en el renderizador, y el motor en Rust en el aislamiento de Workers se apretuja físicamente de manera diferente a como lo hace el verdadero Chrome.
Un efecto secundario del motor no estándar es la singularidad. Los scripts anti-bots se han calibrado durante años en los artefactos de Chromium: el orden de las propiedades, la especificidad de los errores, los tiempos de las API. Un motor que no tiene estos artefactos no se ve "más limpio", se ve diferente, y "diferente" en la puntuación anti-bots cuesta más que "como todos". Ya hemos analizado este efecto en la revisión de navegadores stealth de 2026: los benchmarks sobre la limpieza de la huella JS y los resultados en objetivos reales difieren, porque los objetivos reales consideran la suma de señales.
Obscura: la misma clase, pero en tu servidor
Obscura es el representante de código abierto principal de la clase. El repositorio fue creado el 13 de abril de 2026, licencia Apache-2.0, y a finales de agosto tenía más de 22 mil estrellas. En su interior hay un verdadero V8, y en el exterior — CDP, es decir, también es un reemplazo drop-in para headless Chrome para Puppeteer y Playwright.
La clave de la decisión arquitectónica: Obscura no tiene un pipeline de maquetación y renderizado, no dibuja la imagen en absoluto. De aquí los números del benchmark del autor — la mediana en 33 escenarios da aproximadamente 21 veces más velocidad y alrededor de una séptima parte de la memoria en comparación con headless Chrome. En carga continua de páginas React en cuatro workers, esto es 40 páginas por segundo con 112 MB de memoria contra 3 páginas por segundo con 4,2 GB en Chrome. Cobertura WPT en el "núcleo" (DOM, HTML, URL, fetch) — 83,3%, es decir, 318,916 subpruebas de 382,891.
La diferencia práctica con Kitesurf no está en la velocidad, sino en dónde se ejecuta todo esto. Obscura lo despliegas tú mismo — y tú decides a través de qué salida de red se conecta. Kitesurf vive en la red de otro, y esto nos lleva al punto principal.
¿Quién posee tu IP de salida?
Sobre el ahorro de CPU se ha escrito mucho, sobre la salida a la red — casi nadie. Sin embargo, Kitesurf se ejecuta en Workers, lo que significa que las solicitudes salen de la red de Cloudflare, con su ASN. No hay gestión de la IP de salida o conexión de un proxy propio en la documentación de Kitesurf. En el vecino Browser Rendering, los desarrolladores se encuentran con lo mismo: intentar establecer un proxy upstream a través de proxyServer en BrowserContext falla con net::ERR_PROXY_CONNECTION_FAILED, y no hay direcciones de egress fijas para Workers de forma estándar.
Para el escenario objetivo de Cloudflare, esto es normal: el agente navega por páginas abiertas, toma una captura de pantalla, extrae HTML. Pero tan pronto como el objetivo está algo protegido, obtienes la peor combinación de señales posible:
- la IP pertenece a un gran ASN en la nube, es decir, está marcada como servidor;
- la huella TLS no coincide con ningún navegador real;
- no puedes cambiar ni lo uno ni lo otro, porque no controlas ni la pila de red ni la salida.
Esta situación explica por qué la conversación sobre agentes en 2026 se centra cada vez más no en la optimización del runtime, sino en la cuestión del acceso legal y pagado — desde agentes firmados hasta solicitudes pagadas, sobre lo que hemos escrito en el análisis de billeteras para bots y HTTP 402. Si un sitio no te deja entrar, el motor más económico del mundo no ayudará: simplemente no puedes obtener la página que no te han dado.
Qué elegir para la tarea
Kitesurf — cuando los objetivos son abiertos y numerosos: monitoreo de páginas públicas, extracción de HTML para índices RAG, capturas de pantalla masivas, recorridos de documentación de agentes baratos. Además, beta gratuita y cero complicaciones con la infraestructura. No lo lleves a lugares donde haya inicio de sesión, anti-bots o requisitos de geolocalización específicos.
Obscura — el mismo perfil de carga, pero cuando se necesita control: tu propio hosting, tu propia salida de red, tus propios parches. Es útil como caballo de batalla en un parque de scraping, donde el costo por página es importante y la apariencia de la página no importa en absoluto. Se lleva bien con proxies de forma estándar, porque gestionas el proceso completamente.
Chromium normal bajo Playwright o Puppeteer — cuando se necesitan videos, WebGL, sesiones autorizadas complejas y un renderizado real. Costoso en recursos, pero predecible.
Compilaciones stealth de Chromium (Camoufox, nodriver, patchright, y de lo nuevo — CloakBrowser, que ha acumulado más de 30 mil estrellas desde febrero de 2026) — cuando el objetivo está protegido y no hay otras opciones. Los recursos son un poco más altos que los de Chromium normal, pero se mantiene lo principal: una verdadera pila de red, en la que puedes insertar la salida necesaria.
Y un denominador común para las tres últimas opciones: el motor decide cómo te ves a nivel de navegador, y los proxies residenciales deciden cómo te ves a nivel de red. Para objetivos abiertos y tareas internas, bastará con direcciones de servidor — son más baratas y rápidas. Para sitios con verdadera protección, el costo por página no se calcula en megabytes de memoria, sino en la proporción de respuestas exitosas.
Conclusión
Kitesurf y Obscura son una respuesta honesta y, según los números, exitosa a un dolor real: usar Chromium para extraer HTML es realmente derrochador, y el informe de Apify y The Web Scraping Club lo confirma: el 65,8% de los especialistas en 2025 usaron más proxies que el año anterior, y el 58,3% aumentaron su presupuesto para ellos. Los gastos en automatización están creciendo, y un ahorro de 3 a 7 veces en memoria es un argumento sólido.
Pero el ahorro funciona solo hasta el primer objetivo protegido. El motor ligero no supera el desafío anti-bots — así está escrito en la documentación de Cloudflare. El runtime en la nube no permite gestionar la IP de salida. Por lo tanto, el stack de agentes de 2026 se compone de dos capas independientes: un motor barato para páginas abiertas masivas y un navegador completo con salida de red controlada para todo lo demás. Intentar cerrar ambas capas con una sola herramienta termina ya sea en un sobrecosto por Chromium donde bastaría con Rust, o en una conversión nula del parser donde faltó IP.
```