Um Parâmetro, 3.8× Menos CPU: Kitesurf Remove o Chromium da Execução do Navegador (e Custa 1.7× em Tempo)
Por Devy · Categoria: Ferramentas de IA Dev — Geral (Cat 10)
Se você já tem algo rodando no Browser Run — um scraper, um pipeline de screenshot, um agente que lê páginas — a mudança que a Cloudflare enviou em 6 de agosto é uma string de consulta:
browser=kitesurf
Essa é a migração toda. Mesmo endpoint, mesmo Chrome DevTools Protocol, mesmo cliente Puppeteer ou Playwright. O que muda por baixo é que não há mais um Chrome por baixo. Kitesurf é um navegador que a Cloudflare construiu do zero sobre Workers — Rust e WebAssembly rodando dentro de isolates V8 — e explicitamente não está tentando ser um navegador para pessoas olharem.
Esse é o tradeoff, e é real em ambas as direções. Vamos medir antes de decidir qualquer coisa.
Os números, lado a lado
A Cloudflare publicou uma comparação contra uma instância Chromium aquecida. Esses são seus números, auto-reportados, em duas operações que pipelines de agentes realmente fazem:
| Kitesurf | Chromium (aquecido) | ||
|---|---|---|---|
| CPU — screenshot | 380 ms | 1.173 ms | 3.1× menos |
| CPU — extração de HTML | 229 ms | 877 ms | 3.8× menos |
| Memória — screenshot | 57,8 MiB | 271,0 MiB | 4.7× menos |
| Memória — extração de HTML | 39,4 MiB | 273,7 MiB | 7.0× menos |
| Wall time — screenshot | 1.148 ms | 637 ms | 1.8× mais lento |
| Wall time — extração de HTML | 820 ms | 472 ms | 1.7× mais lento |
Leia a coluna de memória primeiro, porque ela descreve uma coisa diferente das outras. 39 MiB versus 274 MiB por página não é “mais rápido” — é quantas páginas cabem ao mesmo tempo. Em um orçamento por página que diminui 7×, concorrência deixa de ser a coisa que limita seu pipeline. A coluna de CPU é o que aparece na conta. A coluna de wall time é o que seu agente sente.
E a coluna de wall time vai pelo caminho errado. A Cloudflare não esconde nem explica: um JIT aquecido vence um renderizador de software, e Kitesurf renderiza em software. Se sua carga de trabalho é uma página por vez e um humano está esperando, isso é um downgrade. Se sua carga de trabalho é dez mil páginas e ninguém está esperando, você acaba de cortar CPU em aproximadamente 3–4× e memória em 5–7× pelo preço de um parâmetro de consulta.
O tutorial: meça seu próprio antes e depois
Não confie na tabela — ela foi medida nas páginas da Cloudflare, não nas suas. O ponto todo de uma mudança de um parâmetro é que A/B testá-la é quase grátis.
Passo 1 — Execute a operação que você realmente se importa, no Chromium. O endpoint de ação rápida é suficiente para obter uma linha de 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"}'
Passo 2 — Adicione o parâmetro. Não mude nada mais.
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"}'
Passo 3 — Se você o direciona com Puppeteer ou Playwright, o parâmetro vai no endpoint WebSocket, não no código:
const browser = await puppeteer.connect({
browserWSEndpoint: `wss://…/v4/accounts/${accountId}/browser-run/…?browser=kitesurf`
});
Seus seletores, suas esperas, sua lógica de extração — nada disso muda. Kitesurf fala CDP, então chrome-remote-interface e clientes MCP funcionam do mesmo jeito: adicione a string de consulta a --wsEndpoint e pronto.
Passo 4 — Compare três coisas, não uma. Wall time (que vai piorar), tempo de CPU na invocação (que deve cair), e — aquela que as pessoas esquecem — se o resultado é o mesmo. Faça diff do HTML extraído. Veja os dois screenshots. Essa comparação é a decisão real, e leva uma tarde.
Também há um playground em kitesurf.cloudflare.app onde você pode apontá-lo para uma URL e inspecionar o resultado com Chrome DevTools, incluindo um painel de memória mostrando a pegada WebAssembly por isolate. Útil para um primeiro olhar antes de conectar qualquer coisa.
O que realmente quebra
Esta é a metade do artigo que decide se você migra. Kitesurf não suporta:
- WebGL — qualquer coisa que canvas-3D renderiza nada
- Reprodução de vídeo
- Fingerprinting TLS para desafios de bot — se seu site alvo restringe isso, você não passa
- Sessões autenticadas persistentes além de ~10 minutos — fluxos longos conectados estão fora
- Renderização pixel-perfeita — deliberadamente, essa é a premissa de design
- Scrolling a 60 fps
Note a forma dessa lista. Tudo nela é algo que um humano precisa de um navegador. Kitesurf passa em 215.000+ Web Platform Tests, então não é que o motor seja fino — é que as partes que ele pulou são as partes que um agente lendo uma página nunca pede. Ele é construído sobre Blitz, o engine de renderização modular de código aberto, com Stylo para CSS e Parley para text shaping.
A regra prática: a carga de trabalho que se move é aquela onde o resultado é texto ou uma imagem aproximada, em volume, sem supervisão. Scraping, extração de HTML, alimentar páginas para um modelo, geração de miniaturas. A carga de trabalho que permanece no Chromium é testes de regressão visual, qualquer coisa atrás de um login longo, qualquer coisa com um vídeo ou um canvas 3D, e qualquer coisa onde uma pessoa está observando um spinner.
Nada o impede de dividir os dois — é a mesma API, e o parâmetro é por solicitação.
Duas questões abertas que vale a pena considerar
Cold start não está na tabela. Toda figura Chromium que a Cloudflare publicou é contra uma instância aquecida, e eles dizem assim. Mas cold start é exatamente onde um isolate V8 deveria demolir um processo de navegador, e é a medição que falta em uma tabela de benchmark que de outra forma tem tudo. Sua ausência é estranha na direção que os lisonjearia. Se seu pipeline é intermitente em vez de constante, esse é o número que você quereria, e você terá que medir você mesmo.
Ninguém respondeu a questão do anti-bot. Um navegador rodando na própria rede da Cloudflare, buscando páginas protegidas pela Cloudflare — alguém em uma thread de lançamento perguntou se o tráfego do Kitesurf é tratado diferente de qualquer outro, e ninguém do time respondeu. Não é uma acusação, é uma questão sem resposta, e é a primeira coisa a testar se os sites que você busca ficam atrás da Cloudflare.
A Cloudflare diz que planeja lançar o Kitesurf como código aberto — a palavra usada é “esperançosamente em breve” — com o objetivo de permitir que clientes executem sua própria instância em sua própria conta. Esse é um plano, não um artefato enviado. Hoje a única forma de executá-lo é o beta hospedado, que é grátis com limites de uso por conta.
Onde isso se encaixa
Cobrimos Browser Run quando a Cloudflare transformou um Chrome headless em um endpoint HTTP, e Lightpanda quando uma equipe independente argumentou que um navegador para agentes não deveria ser um navegador para humanos com a tela desligada.
Kitesurf é a Cloudflare concordando com esse argumento dentro de seu próprio produto. O argumento todo do Browser Run era tornar Chrome fácil de chamar; o desdobramento é tornar Chrome opcional. Lightpanda fez o argumento; a coisa interessante aqui é quem está fazendo agora, e que eles anexaram números.
E você? Se você trocasse um parâmetro no seu pipeline de scraping mais pesado hoje, o que importaria mais para você — o CPU que você deixaria de pagar, ou o wall time que você estaria adicionando a cada solicitação?
Fontes: