Puppeteer 24.16: review da automação de navegador com foco em Chrome, sem orquestração de crawl

Puppeteer é a biblioteca Node do Google para controlar um Chrome real a partir do JavaScript — você escreve a automação, o Chrome DevTools Protocol carrega os comandos, e um navegador completo renderiza a página antes de você ler qualquer byte. O projeto vive em puppeteer/puppeteer no GitHub: licença Apache-2.0, escrito em TypeScript e com cerca de 95,3 mil estrelas (95.307 no dia em que capturei o snapshot). O posicionamento oficial é propositalmente limitado — “uma API JavaScript para controlar o Chrome (e, experimentalmente, o Firefox)” — o que já deixa claro o que ele é e, tão importante quanto, o que ele não é.

Executei o Puppeteer 24.16.0 no mesmo servidor de fixtures e nas mesmas demos públicas que usamos em toda avaliação de bibliotecas de automação de navegador: um catálogo estático com paginação, um artigo, um catálogo renderizado em JavaScript, uma API JSON, uma rota que retorna 500, um pequeno grafo de crawl, além de Books to Scrape e Quotes to Scrape. O trabalho de renderização saiu limpo e sem cerimônia. Mas ele também deixou exatamente uma tarefa na minha mesa — a mesma tarefa que toda biblioteca de navegador headless deixa — e ser honesto sobre essa lacuna é, em grande parte, o que separa uma análise útil de um release promocional.

Um número chamou mais atenção do que as taxas de recall. Em uma página cujo conteúdo chega por um endpoint JSON, o Puppeteer coletou todos os 8 registros sem fazer scraping do DOM — ele executou o fetch dentro da página e leu o objeto de resposta diretamente. Isso, somado à renderização nativa com screenshots funcionando, define bem a ferramenta: um renderizador Chrome maduro, não um framework de crawl. E essa diferença importa antes mesmo de você escrever a primeira linha.

O que o Puppeteer realmente é — e com o que ele compete

O rótulo da categoria faz diferença aqui, então vamos começar por ele. Puppeteer é uma biblioteca de automação de navegador. Ela abre o Chrome, carrega páginas, deixa o JavaScript da página rodar e entrega o resultado renderizado para você ler ou capturar em screenshot. É justamente por isso que ele existe, em vez de um cliente HTTP com um parser HTML: você quer a página depois que os scripts executam, não o esqueleto vazio que o servidor envia de primeira.

Na prática, ele compete com outras bibliotecas de navegador real — Playwright e Selenium — e não com frameworks de crawl como Scrapy ou com ferramentas de Markdown para LLM. Se você apontar o Puppeteer para mil URLs esperando que ele coloque tudo em fila, faça deduplicação, respeite limites de forma educada e escreva um dataset, você levou um renderizador para um problema de crawling. Ele vai renderizar cada página lindamente, mas não vai cuidar da orquestração. Isso não é um defeito; é um limite de escopo — volto nisso porque é a coisa mais importante para internalizar antes de adotar a ferramenta.

O Puppeteer nasceu dentro da equipe do Chrome do Google, por isso ele é “Chrome-first” por design e sua API parece uma luva fina e bem gasta sobre o protocolo de depuração do navegador. Ele já está maduro o suficiente para ser “chato” no bom sentido: os métodos essenciais permanecem estáveis há anos, a documentação é robusta e o ecossistema ao redor é profundo.

Renderização nativa e o padrão de fetch dentro da página

Vale destacar dois comportamentos que aparecem na tabela de resultados porque eles definem como a ferramenta é usada no mundo real.

Primeiro, a renderização nativa. O catálogo renderizado em JavaScript — uma página que monta a grade de produtos no cliente depois do carregamento — voltou com 8/8, e ainda salvou um screenshot da página inteira em disco. A configuração foi minimalista, mas incluiu aguardar o conteúdo-alvo após goto. A página pública Quotes to Scrape em JS retornou as dez citações usando o mesmo padrão. Esses resultados são de fixtures, não uma nota geral de recall de renderização.

Segundo, o fixture da API JSON carregou produtos de /api/dynamic-products. Executar um fetch same-origin via page.evaluate retornou todos os oito registros sem precisar analisar linhas renderizadas. Isso é um padrão geral de avaliação dentro do navegador, não uma descoberta exclusiva do Puppeteer. Ele pode simplificar a extração quando o endpoint e o contrato da requisição são conhecidos; ainda assim, cabeçalhos de autenticação, tokens de runtime, política de credenciais, CORS/CSP, service workers e paginação podem fazer a requisição real da aplicação diferir do esperado.

A terceira coisa que vale levar adiante não é um número, mas o enquadramento: o Puppeteer é um renderizador Chrome maduro, e não um crawler. As duas partes são verdadeiras, e a segunda é a que muita análise pula.

Como o Puppeteer conversa com o Chrome

No Chrome, o Puppeteer usa o Chrome DevTools Protocol (CDP), o canal JSON sobre WebSocket usado pelas DevTools do navegador. puppeteer.launch() inicia o Chrome e abre essa conexão; chamadas como goto, $$eval e screenshot expõem operações do navegador por uma API de nível mais alto. O suporte a Firefox segue o caminho WebDriver BiDi descrito mais adiante, então nem toda operação do Puppeteer é universalmente um comando CDP.

page.evaluate executa uma função dentro do contexto da página, então um fetch('/api/...') relativo usa a origem daquela página e pode reaproveitar cookies e estado de sessão elegíveis. Isso não replica automaticamente cabeçalhos de autorização, opções de requisição, tokens ou comportamento de service worker criados pela aplicação. Neste fixture same-origin, ele retornou JSON diretamente; em produção, as requisições precisam ter o contrato real inspecionado.

Isso também explica por que o Puppeteer é pesado. Cada página é uma aba de navegador real com um motor de renderização real por trás. Isso compra correção em páginas pesadas de JavaScript, mas cobra em memória e tempo de inicialização em comparação com uma busca HTTP pura. Não existe renderização grátis; o CDP apenas torna a conta legível.

A questão do motor, sem rodeios

Há um resumo popular dizendo que o Puppeteer é “só Chrome”. Para a versão que testei, isso está errado — e acertar esse ponto muda a comparação.

Tanto o Chrome for Developers quanto a Mozilla explicaram a mudança para Firefox quando ela foi lançada. A build que rodei, 24.16.0, já está bem além da v23, então dizer “só Chrome” subestima o que vem no pacote. A ausência do WebKit, somada ao fato de a história multi-motor ser mais recente que a do Playwright, é a diferença real de amplitude — não “um motor versus três”.

O caminho Firefox/BiDi está documentado e disponível na versão que testei, mas eu não rodei meus fixtures por ele, então estou relatando capacidade, não medição. Se suporte a renderização no Firefox for crítico para seus alvos, valide isso nas suas próprias páginas antes de decidir. Para quem quer a comparação completa em motor e linguagem, nosso comparativo Playwright vs Puppeteer coloca as duas bibliotecas lado a lado nestes mesmos testes e resolve a pergunta “qual escolher” por ali; aqui o foco é apenas o Puppeteer.

Instalação e setup na prática: o peso está no navegador

O caminho padrão npm install puppeteer baixa uma build compatível do Chrome for Testing. Esse comportamento pode ser desativado ou redirecionado por configuração, e também dá para apontar o Puppeteer para outro executável, então o casamento de versões depende da decisão de implantação. O download do navegador foi a parte mais pesada dessa instalação; um snapshot de auditoria do gerenciador de pacotes não deve ser tratado como propriedade de segurança duradoura.

Esse empacotamento automático é, ao mesmo tempo, uma grande vantagem de usabilidade e um custo real de peso. O ganho: você não precisa caçar um navegador compatível nem travar versões manualmente; um npm install já entrega um par funcional. O custo: você está baixando um navegador, então reserve disco e banda para isso, especialmente em CI, onde um cache frio paga esse preço a cada executor novo.

Também é um contraste real com o Playwright, que separa as duas etapas — você instala a biblioteca e depois roda um npx playwright install separado para baixar suas builds de navegador. Nenhuma das abordagens é dolorosa; elas só falham de maneiras diferentes. O comando único do Puppeteer pode surpreender pelo tamanho em conexões medidas, enquanto a segunda etapa do Playwright pode ser simplesmente esquecida. É bom saber qual fluxo você está usando.

Resultados práticos

Todos os testes rodaram contra um servidor local de fixtures em 127.0.0.1 e duas sites públicos de prática, com Node v22.22.3, macOS arm64, Puppeteer 24.16.0 e o Chrome empacotado com ele. A verdade de referência de cada fixture foi anotada antes da execução, então o recall é medido contra um conjunto esperado fixo, e não contra o que o Puppeteer “achou” que deveria imprimir.

O pacote público de pesquisa inclui o servidor de fixtures, o runner de testes e a verdade de referência. O lock de dependências e o resumo bruto da execução foram deliberadamente omitidos do pacote de publicação porque a revisão de segurança rígida rejeitou dados de lockfile e material de endpoint específico do ambiente. Para reproduzir o fixture local com segurança, rode npm install e depois node run_puppeteer_material_tests.mjs dentro de tools/puppeteer/tests, e então compare o resultado com a verdade de referência publicada. Páginas demo públicas podem mudar, então o fixture local é a base estável para as checagens de contagem esperada.

Para uma reconstrução histórica exata das dependências, crie e audite localmente um lockfile novo, em vez de tratar um lock não publicado como evidência pública.

Alguns desses pontos merecem mais uma frase além da tabela.

O código de paginação escrito à mão recuperou todos os 12 itens esperados do catálogo. O seletor do artigo recuperou o título e os três parágrafos de corpo previstos; o boilerplate ao redor continuou disponível no DOM. O Puppeteer forneceu o DOM renderizado, enquanto a lógica dos seletores — não o Puppeteer em si — definiu o que contava como conteúdo do artigo.

Na rota HTTP 500 testada, goto retornou um objeto de resposta com status 500 inspecionável e não lançou exceção. Isso não diz nada sobre timeouts, falhas de DNS, crashes do navegador, frames desconectados ou outros erros de navegação, que ainda precisam de tratamento explícito.

O grafo de crawl é o caso que conta a história toda. Caminhar pelos links internos do fixture até 12 páginas, acompanhando a profundidade para não revisitar URLs, exigiu uma busca em largura escrita à mão — porque o Puppeteer não traz uma fila de crawl embutida. Ele encontrou as 12 páginas nas profundidades {0:1, 1:4, 2:7}, o que quer dizer que minha BFS funcionou. Mas a BFS era minha. O Puppeteer renderizou cada página; a lógica de caminhar pelo site foi código que eu mesmo escrevi. Para doze páginas, isso é questão de uma dúzia de linhas e nada demais. Para milhares de URLs, com deduplicação, retries e delays de cordialidade, essa dúzia de linhas vira um projeto.

Um aviso que vou repetir porque é fácil exagerar: os artefatos incluem tempos por teste, mas eles são observações de uma única execução, em uma única máquina, não benchmarks. Não estou ranqueando a velocidade do Puppeteer contra nada com base em um laptop e uma corrida só. O que os números sustentam é recall e comportamento em oito tipos diferentes de página — não uma afirmação de stopwatch.

O que eu não testei

Para que os resultados não sejam lidos como algo mais amplo do que realmente são, aqui está o que ficou fora da execução e, portanto, fora desses números:

Nada disso é uma crítica. São apenas os limites do que uma execução com fixtures pode afirmar com honestidade.

Prós e contras

Prós:

• Renderização nativa de JavaScript com espera explícita de conteúdo: 8/8 no fixture dinâmico e as 10 citações da demo pública, com screenshots.
• A paginação e os seletores do artigo, escritos à mão, recuperaram os itens esperados do fixture.
• fetch dentro da página retornou todos os oito registros do endpoint same-origin conhecido sem parsing do DOM.
• O HTTP 500 testado voltou como resposta inspecionável, sem exceção.
• A instalação padrão baixa uma build compatível do Chrome for Testing; ainda é possível usar outro executável ou pular o download.
• API madura e focada em Chrome sobre CDP, com ecossistema profundo e documentação sólida. Apache-2.0.
• Mais amplo do que sua reputação sugere: suporte documentado a Firefox via WebDriver BiDi desde a v23.

Contras:

• Não há fila de crawl, gravador de dataset nem controle de taxa embutidos — para crawl em escala, você precisa escrever isso ou usar um wrapper.
• Não há motor WebKit, e a história multi-motor é mais jovem do que a do Playwright.
• Peso de navegador real: um Chrome empacotado para baixar e custo de memória por página em comparação com ferramentas somente HTTP.
• Baseado em Node; usar a partir de outra linguagem significa construir e manter uma ponte.
• A versão testada (24.16.0) ficou atrás do latest do npm (25.3.0) por uma versão major — revalide na versão atual antes de confiar em números exatos.

Para quem ele serve — e quem deveria passar

Vale usar o Puppeteer se você trabalha em Node, seus alvos renderizam bem no Chrome (a maioria renderiza) e você quer uma biblioteca madura e focada que transforma “a página depois que o JavaScript roda” em algo que você pode ler e capturar. Para raspar um conjunto de páginas dinâmicas, puxar uma API JSON com a sessão da própria página ou capturar screenshots renderizados como prova, ele é um ótimo padrão com pouca dor de cabeça. A opção Firefox via BiDi existe caso você cresça nessa direção, e o ecossistema garante que a maioria dos problemas já foi encontrada antes.

Pense duas vezes se o seu problema é orquestração de crawl, e não renderização. Se você precisa percorrer centenas ou milhares de URLs com deduplicação, retries e limites de taxa, o Puppeteer sozinho vai fazer você reconstruir um crawler na mão — e isso está no nível errado para ele. Pule o navegador headless inteiro se suas páginas não precisarem de JavaScript para revelar os dados; quando uma requisição HTTP e um parser já entregam o conteúdo, um navegador real é um exagero caro que só consome memória e tempo de setup. E se você precisa de fidelidade de WebKit ou de um cliente em uma linguagem que não seja JavaScript, esta não é a ferramenta para esse eixo.

Alternativas e onde o Thunderbit entra

O enquadramento honesto primeiro: o Puppeteer é gratuito, Apache-2.0, self-hosted, e você é dono de tudo que envolve operá-lo — a frota de navegadores, o código de crawl que você acopla e a guerra contínua contra anti-bot. Para muitos projetos, essa posse é exatamente o que faz sentido, e nenhum serviço gerenciado vai renderizar uma página autorizada de forma mais barata do que um navegador que você já tem.

Dentro do open source, a comparação útil é por tarefa, não por marca. Em escala de crawl, Crawlee é o companheiro natural: o PuppeteerCrawler dele envolve o Puppeteer com a fila de requisições, dataset e throttling que a biblioteca omite de propósito, então você mantém a renderização e ganha a orquestração. Se o objetivo de saída é Markdown limpo para uma pipeline de LLM, e não um DOM renderizado, Crawl4AI usa um navegador real e entrega exatamente isso. Se suas páginas não precisam de navegador algum, um framework HTTP-first como Scrapy entra em uma categoria diferente, e mais leve. Quando você está comparando vários desses ao mesmo tempo, nosso resumo de scrapers open source coloca as categorias lado a lado.

Um serviço gerenciado como Thunderbit desloca a operação do navegador e a extração para dentro de uma API. Ele não foi executado nestes fixtures do Puppeteer, então esta análise não faz nenhuma afirmação pareada sobre renderização, bloqueio, qualidade da extração ou custo. A fronteira de decisão aqui é a responsabilidade operacional: manter você mesmo o navegador e o código de crawl, ou pagar um provedor para operar parte dessa camada.

Com Puppeteer não existe taxa de uso de fornecedor, mas computação, banda, manutenção do navegador, orquestração e operação continuam sendo seus. Um caminho gerenciado cobra pelo uso e transfere parte dessa responsabilidade para o fornecedor. Este experimento não comparou os resultados.

Experimente o Thunderbit para extração de dados da web

Veredito

O Puppeteer 24.16.0 vale a avaliação se você usa Node e precisa de automação de navegador com foco em Chrome. O código de fixture escrito para o teste recuperou 12 itens estáticos, 8 itens dinâmicos e 10 citações da demo pública; a API same-origin conhecida retornou 8 registros via page.evaluate; screenshots funcionaram; e o HTTP 500 testado permaneceu inspecionável. Esses resultados pertencem aos fixtures nomeados e a uma versão major mais antiga, não ao recall de extração em geral.

Ainda assim, dimensione as afirmações corretamente. O Puppeteer é um renderizador, não um crawler: minha caminhada de 12 páginas precisou de uma BFS manual porque não há fila embutida, e em escala essa lacuna vira trabalho real — entregue isso ao Crawlee ou escreva a infraestrutura você mesmo. Ele é Chrome-first, com suporte documentado ao Firefox via BiDi, mas sem WebKit, então não é a ferramenta para amplitude multi-motor. Ele carrega o peso de um navegador real. E eu testei 24.16.0 contra um latest 25.3.0, então reexecute na versão atual antes de confiar em números exatos. Entenda esses quatro pontos antes de começar, e o Puppeteer vira uma excelente biblioteca de automação para Chrome. Espere que ele faça crawl de um site para você, e você acabará escrevendo o crawler que imaginou estar baixando.

Experimente o Thunderbit para extração de dados da web Get Started Free

FAQs

O Puppeteer renderiza páginas em JavaScript ou eu preciso de plugin?
Ele renderiza nativamente, sem plugin. No meu fixture dinâmico, ele retornou 8 de 8 produtos montados no cliente com recall 1.0 e screenshot da página inteira; a página pública Quotes to Scrape em JS retornou as 10 citações do mesmo jeito — um goto simples, depois leitura do DOM renderizado. Como o Puppeteer controla um Chrome real via DevTools Protocol, os scripts da página realmente executam antes de você ler qualquer coisa.

O Puppeteer consegue raspar uma API JSON sem analisar HTML?
Sim, quando o endpoint e o contrato da requisição permitem isso. page.evaluate pode emitir uma requisição a partir da origem da página e pode reaproveitar cookies elegíveis, mas não reproduz automaticamente cabeçalhos, tokens, opções ou comportamento de service worker da aplicação. No fixture same-origin, ele retornou todos os oito registros sem parsing do DOM.

O Puppeteer é um web crawler?
Não — ele é uma biblioteca de automação de navegador, não um framework de crawler. Não existe fila de requisições, gravador de dataset nem throttling embutido, então meu crawl de 12 páginas (profundidades {0:1, 1:4, 2:7}) precisou de uma busca em largura escrita à mão. Isso é uma fronteira de escopo, não um defeito. Para crawl em escala, combine com um wrapper como o PuppeteerCrawler do Crawlee, que adiciona a fila e a infraestrutura de dataset que o Puppeteer deixa de fora.

O Puppeteer é só para Chrome?
Não mais. Ele é Chrome-first via CDP, mas desde a v23 tem suporte documentado ao Firefox via WebDriver BiDi, e a versão que testei (24.16.0) está bem além disso. O que ele não controla é o WebKit, e a história multi-motor dele é mais jovem do que a do Playwright — essa é a limitação correta, não “só Chrome”. Aqui eu só exercitei Chrome, então estou relatando Firefox via BiDi como recurso documentado, não como algo que medi.

O que a instalação do Puppeteer realmente baixa?
Por padrão, npm install puppeteer baixa uma build compatível do Chrome for Testing. O download pode ser pulado ou redirecionado, e outro executável pode ser configurado, então o pareamento de versões depende das escolhas de implantação. Reserve disco e banda para o navegador, especialmente em runners de CI sem cache. Esta análise testou a 24.16.0; rode novamente os fixtures principais na versão atual no momento da publicação.