.4UVmK5aw_1uGpNi.svg){kind=small}
.AzQB9McO_PVSYK.svg){kind=small}
.DjhlE8MO_Z1DYVxU.svg){kind=small}
.DM2pllEO_1cxFXE.svg){kind=small}
.CvN5042A_Z10D5qc.svg){kind=small}
.Dcqs_gC__NRL3p.svg){kind=small}
<div id="root"></div> <!-- dados ainda no bundle -->
As sessões são gratuitas — pague apenas pelo tráfego
Navegador na nuvem para web scraping
Uma sessão de navegador na nuvem carrega a página como faria para um visitante real, com todos os scripts — quando o seu código a lê, o conteúdo já está lá.
- Páginas em React, Vue e Angular são renderizadas por completo — sem HTML vazio
- IPs residenciais, móveis ou de datacenter — fixos (sticky) ou rotativos
- Playwright e Puppeteer — normalmente basta alterar uma linha
Web scraping
Seu código controla
o navegador.
Conecte-se via CDP ao nosso Chromium em vez de buscar o HTML. Ele carrega a página como um visitante real — com todo o JS, nossos proxies e um fingerprint convincente — e você lê o DOM renderizado.
Por que usar o navegador na nuvem em vez de requisições HTTP comuns?
Uma requisição HTTP simples baixa o HTML que o servidor enviar e nada além disso. Funciona bem para uma página estática. Mas falha na maior parte da web moderna, porque sites criados com React, Vue ou Angular não enviam o conteúdo nessa primeira resposta – eles o montam no navegador, depois que o JS é executado. Aponte um scraper que só faz requisições para uma dessas páginas e você receberá uma casca vazia, com os dados reais ainda dentro de um bundle que ninguém executou.
O web scraping com sessões de navegador na nuvem elimina esse problema. A página carrega como carregaria para um visitante real, com todos os scripts, e quando o seu código a lê, o conteúdo já está lá. Sem ficar adivinhando qual endpoint alimenta a página, sem desmontar um bundle para descobrir o padrão das requisições – só o resultado final, pronto para ser coletado.
Como contornar bloqueios e a proteção anti-bot no nível do navegador
Antes bastava enviar os cabeçalhos certos para receber a página. Hoje não mais – os sites avaliam dezenas de pequenos sinais antes de decidir se uma requisição parece real:
-
A ordem dos cabeçalhos, e não apenas quais cabeçalhos estão presentes
-
Os intervalos de tempo entre as ações
-
Se o mouse ou a rolagem se comportaram como os de uma pessoa
-
Particularidades do fingerprint: fontes instaladas, saída do canvas e coisas do tipo
Renderização dinâmica de JavaScript e aplicações de página única (SPA)
Aplicações de página única carregam uma vez e depois se reescrevem conforme você clica – abas abrem, filtros são aplicados, resultados são atualizados – e nada disso aparece nessa primeira resposta. Um navegador na nuvem passa pelo mesmo processo que um visitante e só lê a página depois que ela se estabiliza. Sem essa etapa, uma quantidade surpreendente de scraping falha silenciosamente em qualquer site com muita lógica no lado do cliente.
Resolução automática de CAPTCHA e gerenciamento de fingerprint
Fontes, saída do canvas, comportamento de áudio, tamanho da tela – juntos, esses elementos formam um fingerprint, que é comparado com o que um navegador real deveria apresentar. Se algo estiver errado, os sites o sinalizam rápido, às vezes depois de uma ou duas requisições. Chame de navegador na nuvem antidetecção, de configuração antidetecção ou apenas de modo indetectável: o objetivo é o mesmo – manter esse fingerprint convincente sem que ninguém precise mexer nele manualmente. A resolução de CAPTCHA geralmente acompanha a mesma sessão, para que uma tarefa não fique parada esperando uma resolução manual a cada CAPTCHA que aparecer.
Integração com proxies rotativos (residenciais e de datacenter)
Uma sessão pode passar por IPs residenciais, móveis ou de datacenter, dependendo do quão sensível é o site de destino. A rotação pode ser fixa durante toda a sessão ou trocar por temporizador – e essa escolha faz diferença. O scraping atrás de um login exige o mesmo IP o tempo todo, para que cookies e estado da sessão se mantenham coerentes. O scraping em grande volume pede o oposto: distribuir as requisições para que nenhum endereço concentre toda a pressão.
Funciona com Playwright e Puppeteer
Você não precisa descartar o código de scraping que já tem para usar nada disso. Playwright e Puppeteer se conectam via CDP em vez de iniciar um binário local do Chrome, e todo o resto – seletores, esperas, extração – continua exatamente como foi escrito. Um crawler criado há dois anos para o Chrome headless local geralmente precisa de uma única linha alterada, não de uma reescrita.
- Playwright
- Puppeteer
- Python
- Node.js
Início rápido: código de exemplo para conectar
Colocar uma sessão em funcionamento leva poucas linhas:
Adicione um tipo de proxy e um país ao abrir a sessão, e o restante do script mal muda em relação ao que rodaria localmente.
scrape.js
const browser = await chromium.connectOverCDP(connectUrl);const page = await browser.newPage();await page.goto('https://example.com');const data = await page.textContent('body');scrape.js
const browser = await puppeteer.connect({ browserWSEndpoint: connectUrl });const page = await browser.newPage();await page.goto('https://example.com');const data = await page.evaluate(() => document.body.innerText);Comparação de eficiência: scraping com requisições vs. navegador na nuvem
O scraping com navegador na nuvem custa mais por página do que uma requisição simples – não há como evitar, pois uma sessão completa de navegador faz mais trabalho. Veja onde os dois realmente se diferenciam:
| Requisições HTTP simples | Scraping com o Cloud Browser da Floppydata | |
|---|---|---|
| Páginas renderizadas por JavaScript | Retorna vazio | Renderiza por completo, como para um visitante real |
| Custo por página | Menor | Maior, mas bloquear recursos desnecessários reduz o custo |
| Conteúdo protegido por login | Sem sessão para manter | Cookies e sessão persistem entre as páginas |
| Fingerprint anti-bot | Nenhum, fácil de sinalizar | Tratado automaticamente |
| Largura de banda | Carrega tudo | Pode ignorar imagens, fontes e CSS |
Para conteúdo estático, sem JavaScript e sem proteção contra bots, as requisições simples ainda saem na frente em custo – não há motivo para iniciar um navegador completo para uma página que nunca precisou dele. Fora esse caso, o scraping com navegador na nuvem costuma sair mais barato quando você soma as novas tentativas, os proxies e os ajustes manuais que uma configuração baseada apenas em requisições acaba exigindo de qualquer forma. A conta raramente favorece as requisições quando o site de destino começa a reagir ativamente.