Cheerio vs Puppeteer: Como escolher a ferramenta certa

Ambas são bibliotecas Node.js em camadas diferentes. O Cheerio pega no HTML que já tem e fornece-lhe seletores para extrair dados. O Puppeteer inicia um navegador Chromium real, executa o JavaScript da página e permite-lhe ler ou clicar no resultado.

O filtro mais rápido para comparar o Cheerio com o Puppeteer é o teste «view-source»: procure na fonte bruta os dados que pretende. Se estiverem lá, o Cheerio mais um cliente HTTP é suficiente. Se a fonte for um invólucro vazio com pacotes JS, precisa de um navegador.

O Cheerio é uma biblioteca apenas de análise. Passa-lhe uma cadeia HTML com cheerio.load(html) e ela devolve um $ objeto que imita o jQuery: $('h1').text(), $('a.product').each(...), pesquisas de atributos, percurso. Não há DOM, nem motor de layout, nem tempo de execução de JavaScript.

O Cheerio também não recupera HTML por si próprio, pelo que deve combiná-lo com o axios, o node-fetch ou o undici. Essa separação é uma característica: controla a camada de pedidos e o Cheerio concentra-se na análise.

O Puppeteer é uma API Node.js que controla o Chrome ou o Chromium através do Protocolo Chrome DevTools. Quando npm install puppeteer, ele fornece uma compilação do Chromium compatível, pelo que não precisa de gerir um binário de navegador separado.

Um script típico segue o mesmo ciclo de vida: puppeteer.launch(), browser.newPage(), page.goto(url), page.waitForSelector(...) para conteúdo assíncrono, depois page.content() ou page.evaluate(...) para ler o DOM renderizado.

Colocar o Cheerio e o Puppeteer lado a lado não é tanto para decidir o vencedor, mas sim para confirmar qual a tarefa que tem em mãos. A velocidade e a pegada favorecem o Cheerio. A renderização JavaScript, a interceção de rede e a simulação de utilizador pertencem ao Puppeteer.

O Cheerio analisa HTML em milésimos de segundo e utiliza alguns megabytes por worker, pelo que milhares de análises cabem num único processo Node.js ou numa pequena função sem servidor. Cada instância do navegador Puppeteer necessita normalmente de 150 a 300 MB de RAM (valores de referência da comunidade à data da redação; verifique em função da sua carga de trabalho). Num Lambda de 1 GB, isso limita rapidamente o paralelismo.

Se sabe escrever $('div.card .price').text(), sabe escrever Cheerio. A maioria das tarefas tem entre 10 e 20 linhas. O Puppeteer exige mais: familiaridade com async/await, ciclo de vida da página e depuração de erros de temporização em que um seletor é acionado antes que os dados cheguem.

Recorra ao Cheerio quando o corpo da resposta já contiver os dados. Isso abrange uma grande parte da web pública: blogs, notícias, páginas de marketing, RSS, mapas do site, resultados de pesquisa renderizados pelo servidor, documentação.

Na comparação entre Cheerio e Puppeteer para estes alvos, o Puppeteer é um exagero. Um pipeline de Cheerio mais axios extrai mais páginas por segundo e cabe em workers sem servidor baratos. Se curl URL | grep encontrar os teus dados, o Cheerio também os encontrará.

O Puppeteer justifica o seu uso quando a página é mais uma aplicação do que um documento. As SPAs construídas em React, Vue ou Angular costumam enviar um shell vazio e injetar conteúdo via XHR após o carregamento. Também é necessário um navegador real para rolagem infinita, painéis de controlo protegidos por login, gestão de cookies ou sessões e formulários de várias etapas.

O Puppeteer também é adequado quando o scraping é um efeito secundário de uma automação mais ampla: capturas de ecrã, PDFs, envios de formulários, verificações de posicionamento de anúncios.

A resposta mais clara à questão «Cheerio vs. Puppeteer» para a maioria dos sites não triviais é «ambos». Trate a renderização e a análise como questões separadas: o Puppeteer constrói o DOM final e, em seguida, entrega o HTML ao Cheerio.

Porquê separá-los? Executar querySelectorAll no page.evaluate envia uma chamada de retorno ao navegador para cada passagem do seletor, e cada ida e volta atravessa o Protocolo DevTools. Para dez campos em mil páginas, o custo acumula-se.

Capturar o HTML renderizado uma vez com page.content() e analisá-lo localmente com o Cheerio é mais rápido, e a sua lógica de seleção permanece depurável sem um navegador.

Após npm init -y && npm install puppeteer cheerio, um scraper híbrido contra quotes.toscrape.com tem este aspeto:

const puppeteer = require('puppeteer');
const cheerio = require('cheerio');

(async () => {
  const browser = await puppeteer.launch({ headless: 'new' });
  const page = await browser.newPage();
  await page.goto('https://quotes.toscrape.com/', { waitUntil: 'networkidle2' });

  const html = await page.content();
  await browser.close();

  const $ = cheerio.load(html);
  const quotes = [];
  $('div.quote').each((_, el) => {
    quotes.push({
      quote: $(el).find('span.text').text().trim(),
      author: $(el).find('.author').text().trim(),
    });
  });
  console.log(quotes);
})();

page.content() retorna o HTML serializado do documento atual, o equivalente moderno e mais limpo dos padrões mais antigos page.evaluate(() => document.documentElement.innerHTML) padrões. O bloco Cheerio é idêntico ao que escreveria se o axios tivesse obtido o HTML.

No localhost, todos os scrapers funcionam. Em produção, os modos de falha manifestam-se como erros 403, 429, desafios de identificação e CAPTCHAs no momento em que se ultrapassa um limite de taxa. Executar o Puppeteer sozinho não é uma solução discreta: o Chromium headless básico emite sinais detetáveis.

Escalar de forma realista significa alternar entre proxies residenciais ou móveis, randomizar os user agents, tentar novamente com backoff e encaminhar os pedidos mais complexos através de uma API de scraping gerida que devolve HTML renderizado para o Cheerio.

Nenhuma destas bibliotecas é a única opção. O Playwright é semelhante ao Puppeteer, mas suporta o Chromium, o Firefox e o WebKit, com espera automática que elimina muitos problemas de temporização. O Selenium é o velho cavalo de batalha poliglota, a escolha certa se a sua equipa já gere uma rede. No que diz respeito à análise, o jsdom oferece-lhe um DOM real e executa scripts, e o htmlparser2 é o analisador de streaming em que o Cheerio se baseia.

• A renderização e a análise são tarefas diferentes. O Cheerio analisa HTML; o Puppeteer renderiza páginas. Escolha a ferramenta adequada à tarefa, não ao seu hábito.
• Use o teste «view-source». Se os dados estiverem na resposta bruta, o Cheerio mais um cliente HTTP é mais rápido, mais barato e mais fácil de manter.
• Recorra ao Puppeteer quando o JavaScript constrói o DOM, quando precisar de cliques, rolagens ou inícios de sessão, ou quando a página for um shell SPA.
• O padrão híbrido é a melhor opção em páginas com muito JavaScript e muitos campos. Renderize uma vez com page.content(), depois analise o HTML no Node com o Cheerio.
• Planeie as defesas anti-bot desde cedo. Proxies, reforço de impressões digitais, tentativas de repetição e CAPTCHAs determinam se o seu scraper sobrevive à produção.

Sim, o Cheerio é significativamente mais rápido porque nunca inicia um navegador. Uma análise do Cheerio é executada em milésimos de segundo contra uma string na memória, enquanto o carregamento de uma página do Puppeteer é limitado pelo tempo de rede, renderização e execução de JavaScript, normalmente alguns segundos. Em hardware equivalente, pode normalmente executar 10 a 100 vezes mais workers do Cheerio em paralelo do que workers do Puppeteer.

Não. O Cheerio apenas vê o HTML que lhe fornece, por isso, se uma página construir o seu conteúdo a partir de JavaScript do lado do cliente, o Cheerio devolve uma estrutura vazia. Ou precisa de um navegador sem interface gráfica, como o Puppeteer ou o Playwright, à frente dele, ou, por vezes, pode aceder à API JSON subjacente que a SPA chama e saltar a renderização por completo.

Precisas de algum cliente HTTP, mas não tem de ser o axios. O Cheerio espera uma string HTML, por isso qualquer coisa que a recupere funciona: axios, node-fetch, undici, o fetch no Node.js moderno, ou até mesmo a leitura de um .html . Escolha o cliente que lhe oferecer o controlo de repetição, proxy e cabeçalhos de que o seu projeto necessita.

Tecnicamente sim, uma vez que o Puppeteer pode consultar o DOM com page.$$eval e auxiliares semelhantes. Na prática, é um desperdício: cada passagem do seletor atravessa o Protocolo DevTools, e paga o custo de memória do navegador por tarefas que nunca precisaram de JavaScript. A maioria das equipas mantém o Puppeteer para a renderização e deixa o Cheerio tratar da extração.

O Playwright é geralmente a escolha padrão mais segura atualmente. Suporta o Chromium, o Firefox e o WebKit através de uma única API, oferece uma melhor espera automática e possui ferramentas de depuração mais robustas de fábrica. Escolha o Puppeteer se a sua equipa já tiver experiência com o Puppeteer, se o seu alvo for apenas o Chromium ou se estiver a expandir uma base de código Puppeteer existente.

A escolha entre Cheerio e Puppeteer resume-se, na verdade, a saber se a página de destino precisa de um navegador para existir. Se a resposta HTML já contiver os dados, o Cheerio juntamente com um cliente HTTP é a solução mais simples, rápida e económica. Se uma estrutura JavaScript montar o DOM em tempo de execução, precisará do Puppeteer ou do Playwright para o renderizar primeiro. E quando uma página é pesada em JS, mas tem de extrair muita informação de cada visita, renderize uma vez com o Puppeteer e analise com o Cheerio.

A parte que nenhuma biblioteca resolve sozinha é a realidade da produção: bloqueios, IPs rotativas, identificação digital e CAPTCHAs. Se preferir manter o seu código Cheerio e deixar de lutar contra a camada de pedidos, a WebScrapingAPI devolve HTML renderizado e desbloqueado através de um único ponto de acesso, para que o seu analisador possa manter-se focado nos seletores em vez de na camuflagem. Escolha a ferramenta que melhor se adapta à sua página, planeie as defesas anti-bot com antecedência e passará muito menos tempo a depurar scrapers e mais tempo a utilizar os dados.