A maioria dos conselhos sobre sites com muito JavaScript para na primeira decisão: essa página precisa mesmo de um navegador? Essa pergunta importa, e ela é respondida em detalhes em when do you actually need a headless browser to scrape. Uma parcela surpreendente dos “sites com JavaScript” acaba não precisando de um.
Este guia começa onde aquele termina. Você já confirmou que o alvo realmente precisa de renderização. Agora existe uma segunda decisão que molda seu custo e sua escala de plantão muito mais do que a primeira: você mesmo roda os navegadores, ou envia a página para uma web scraping API que os roda por você?
Primeiro, confirme se a página realmente precisa de renderização
Uma checagem rápida antes de se comprometer com qualquer um dos caminhos, porque renderizar é sempre a opção mais lenta e mais pesada.
Compare a fonte com a página renderizada. Abra a resposta HTML bruta. Se os dados que você quer estão nela, você não precisa de um navegador.
Procure por estado incorporado. Muitos frameworks JavaScript enviam os dados iniciais da página como JSON dentro de uma tag script, para que o navegador possa hidratar a página sem uma requisição extra. Se seus dados estão nesse JSON, uma requisição HTTP simples mais um parse de JSON já bastam.
Observe as requisições de rede. Se a página busca seus dados de um endpoint JSON depois do carregamento, requisitar esse endpoint diretamente costuma ser mais barato do que renderizar a página em torno dele.
Se nenhuma das três opções trouxer os dados, ou se o endpoint for assinado, opaco ou protegido de formas que você não consegue reproduzir, você precisa de renderização. Continue lendo.
O que rodar seus próprios navegadores realmente envolve
Um navegador headless em um laptop é fácil. Uma frota deles em produção é um problema operacional, e os custos são fáceis de subestimar porque nenhum deles aparece em um protótipo.
Capacidade. Cada instância de navegador consome muita memória, o que limita quantas podem rodar em uma máquina e transforma a concorrência em uma conta de infraestrutura.
Estabilidade. Navegadores travam, vazam memória e caem em páginas hostis. Frotas de produção precisam de watchdogs, reciclagem e uma fila que sobreviva a um worker morrendo no meio de uma página.
Manutenção. Versões de navegador, bibliotecas de automação e a impressão digital de automação mudam constantemente. Uma frota que funcionava no trimestre passado pode começar a falhar sem que uma única linha do seu código mude.
Proxies. O tráfego renderizado ainda precisa de bons IPs, conectados corretamente ao navegador com autenticação e isolamento por contexto. Fazer isso corretamente é um trabalho à parte; veja using residential proxies with Playwright.
Bloqueios e desafios. CAPTCHAs e verificações anti-bot precisam de detecção, tratamento e novas tentativas, e uma tentativa falha ainda assim consumiu o tempo de navegador que levou.
Novas tentativas e espera. Saber quando uma página dinâmica terminou de carregar, e o que fazer quando não terminou, é uma lógica que você escreve e mantém por site.
Nada disso é exótico. É simplesmente trabalho que ninguém cobra de um cliente, e que cresce a cada novo alvo.
O que uma web scraping API tira das suas mãos
Uma web scraping API transforma essa lista em parâmetros de requisição. Com a Shifter Web Scraping API:
- Renderização.
render_js=1roda a página em Chrome headless, cobrado no mesmo um crédito de uma busca estática. - Espera.
wait_for_csssegura a captura até que um seletor apareça, etimeoutlimita o tempo de navegador por página. - Interação.
js_instructionsexecuta uma cadeia de passosscrollTo,clickewaitantes da captura, o que cobre banners de cookies, botões de carregar mais e conteúdo acionado por rolagem. - Saída estruturada.
extract_rulesretorna JSON a partir de seletores CSS, então não há parser para implantar. - Novas tentativas. Buscas falhas, CAPTCHAs e erros transitórios do alvo são tentados novamente automaticamente, até três vezes, com proxies diferentes.
- Desafios. O modo stealth vem ativado por padrão, e reCAPTCHA e hCaptcha são tratados durante a execução em requisições renderizadas.
- IPs. Planos Growth e superiores roteiam pelo pool residencial e móvel com geolocalização global. O Starter usa IPs de datacenter nos EUA e na UE, o que é suficiente para muitas páginas sem proteção.
- Sessões.
session_idmantém cookies, estado do navegador e o IP de origem ao longo de um fluxo de múltiplas etapas, expirando após 10 minutos de inatividade. - Cobrança. Um crédito por resposta bem-sucedida. Requisições falhas, erros do alvo e as próprias novas tentativas da API não são cobradas.
A concorrência tem um limite por plano, de 20 no Starter a 500 no Enterprise, e requisições acima do limite retornam 429. A referência completa de parâmetros começa em rendering JavaScript.
Quando seus próprios navegadores ainda são a escolha certa
Uma API nem sempre é a resposta, e vale ser claro sobre onde ela não é.
Sessões interativas longas. Um fluxo que precisa manter um navegador em um site por um tempo longo, com pausas maiores que a janela de inatividade de uma sessão, se encaixa melhor no seu próprio navegador.
Lógica arbitrária de navegador. Se uma página precisa de scripts personalizados, extensões ou interação além de rolar, clicar e esperar, um navegador que você controla é mais flexível.
Sua própria infraestrutura é um requisito. Algumas cargas de trabalho precisam rodar dentro de uma rede ou ambiente específico por motivos contratuais ou de segurança.
Volume muito grande e muito estável. Em escala suficiente sobre alvos que raramente mudam, infraestrutura própria pode custar menos por página, desde que você já tenha os engenheiros para operá-la.
Testes e depuração. Testes de regressão visual, depuração passo a passo e qualquer coisa em que um humano precise observar o navegador pertencem às suas próprias máquinas.
Uma tabela de decisão por alvo
Faça a escolha por alvo, não por empresa. A maioria dos stacks de scraping maduros usa os três caminhos.
| O alvo se parece com | Melhor caminho |
|---|---|
| Dados no HTML bruto ou no JSON incorporado | Requisição HTTP simples |
| Dados de um endpoint JSON reproduzível | Requisição HTTP simples ao endpoint |
| Conteúdo renderizado, sem proteção, baixo volume | Qualquer um; uma API dá menos trabalho |
| Conteúdo renderizado por trás de verificações anti-bot | Web scraping API |
| Conteúdo renderizado em muitos mercados | Web scraping API com país por requisição |
| Sessões autenticadas longas ou lógica de navegador personalizada | Seus próprios navegadores com proxies residenciais |
| Volume enorme e estável com equipe interna | Seus próprios navegadores, avaliados pelo custo total |
Compare pelo custo por página utilizável
O erro comum nessa decisão é comparar o preço por requisição de uma API com o custo de um servidor, e concluir que o servidor é mais barato.
A comparação justa é o custo por página utilizável. Para sua própria frota, isso inclui computação para navegadores que ficam ociosos ou travam, largura de banda de proxy para tentativas que falharam, e o tempo de engenharia gasto em manutenção, novas tentativas e tratamento de desafios, dividido pelas páginas que de fato produziram dados corretos. Para uma API cobrada apenas por respostas bem-sucedidas, falhas não são cobradas, então o preço por crédito fica muito mais próximo do custo real por página utilizável, embora você ainda pague por páginas bem-sucedidas que acabam sendo inúteis, como um seletor alterado retornando campos vazios.
Rode a mesma amostra de URLs reais de alvos pelos dois caminhos durante uma semana, conte as páginas que retornaram dados corretos e completos, e compare os dois custos por página utilizável. Esse número resolve o argumento mais rápido do que qualquer lista de recursos. Os planos da API estão na pricing page.
Onde os dois se encontram
A escolha não é binária nem mesmo para um único site. Um padrão comum e sensato é usar HTTP simples onde uma página não precisa de renderização, enviar páginas renderizadas e protegidas para a API, e manter uma pequena configuração de navegador para o punhado de fluxos que precisam de lógica personalizada.
Rolagem infinita e feeds de carregar mais ficam exatamente nessa fronteira, e as técnicas para tratá-los dentro de uma renderização são cobertas em how to handle infinite scroll and dynamic pagination. Como uma API monta tudo isso por trás de uma única requisição é explicado em how does a web scraping API work.
Perguntas frequentes
Renderizar é mais caro com uma API?
Em latência, sim, porque um navegador leva mais tempo do que uma requisição simples. Em créditos, não: uma requisição renderizada custa o mesmo um crédito de uma busca estática.
Uma API consegue lidar com todo sistema anti-bot?
Nem todos, sempre. A maioria das verificações é tratada, e um alvo que bloqueia de forma consistente é algo que o suporte pode ajustar. Meça sua própria taxa de sucesso nos seus próprios alvos antes de confiar nisso.
Ainda preciso de proxies se eu usar uma API?
Nenhuma configuração de proxy separada é necessária. A API roteia as requisições através dos seus próprios pools, residencial e móvel nos planos Growth e superiores.
Quando devo migrar de uma API para meus próprios navegadores?
Quando você precisa de um comportamento de navegador que a API não expõe, ou quando uma comparação medida de custo por página utilizável no seu volume real favorece a infraestrutura própria, incluindo a engenharia para operá-la.
Conclusão
Decidir que um site precisa de renderização JavaScript é a metade fácil. A metade cara é decidir quem roda os navegadores. Sua própria frota compra flexibilidade e paga por ela em capacidade, estabilidade, manutenção, proxies e tratamento de desafios. Uma API troca essa flexibilidade por parâmetros, novas tentativas e cobrança apenas em caso de sucesso.
Confirme que uma página realmente precisa de renderização, escolha por alvo em vez de por empresa, e resolva a questão de construir versus comprar com base no custo medido por página utilizável. O produto está na página Web Scraping API.