Quase todo resumo de “melhor scraper open source” tem um detalhe silencioso: ninguém testa as ferramentas nas mesmas páginas. O Scrapy é avaliado em uma matéria de notícias, o Playwright em algum demo de e-commerce, o Colly no que quer que o autor tenha à mão — e depois tudo é colocado lado a lado, como se esses números significassem a mesma coisa. Esse tipo de ranking fala mais das páginas do que das ferramentas.
Então eu fiz o que era óbvio — e chato —, mas que essas listas quase nunca fazem. Montei um conjunto único de cenários e passei as nove ferramentas por ele: um catálogo estático, um catálogo renderizado por JavaScript, um artigo escondido em meio a navegação e rodapé, um erro HTTP 500 intencional, um pequeno grafo de crawl com links internos e mais dois sites públicos de अभ्यास/prática. Mesma verdade de referência, mesmas métricas, em todas as execuções. Os scripts e a saída bruta estão em um repositório público de benchmark, para você mesmo reproduzir tudo. O resultado não foi o ranking limpo que os resumos prometem — não existe vencedor absoluto. Existem três tipos de trabalho, e as nove ferramentas praticamente se organizam sozinhas entre eles.
Experimente Thunderbit para Extração de Dados da Web
Como o benchmark foi feito, e a única limitação que vou dizer em voz alta
Todas as ferramentas foram testadas nos mesmos tipos de cenário: 12 produtos estáticos distribuídos em duas páginas, 8 produtos inseridos por JavaScript após um atraso, um artigo cercado por menus e rodapé com ruído, um servidor propositalmente quebrado com HTTP 500 e um grafo de links internos. É justamente esse desenho que faz os resultados baterem — “8/8 produtos dinâmicos” quer dizer exatamente a mesma coisa, seja o gerador Puppeteer ou Crawlee.
Aqui está o limite que muitos resumos ignoram. Cada pacote de testes espelha os seus próprios cenários, então os totais absolutos de caracteres não são estritamente comparáveis entre ferramentas — leia isso como sinal interno de cada ferramenta, nunca como pontuação entre ferramentas. Os números que são comparáveis são recall (trate como taxa), aprovação/falha em JavaScript e comportamento estrutural. Um aviso de escopo na mesma linha: a execução do Crawl4AI no catálogo estático cobriu apenas a primeira página, então o 6/6 dele é recall total em um recorte menor, enquanto as outras ferramentas percorreram as duas páginas para chegar a 12/12 — escopo menor, não uma perda parcial. A explicação completa, cenário por cenário, está no texto de metodologia.
Mais uma observação antes dos números. Cada pacote também inclui uma pontuação provisória de pesquisa, mas eu não estou publicando isso como tabela ranqueada de propósito. Elas serviam só como apoio interno para validar cada ferramenta contra a própria evidência, não como uma liga oficial — e divulgar isso como ranking recriaria exatamente o problema de falsa precisão que este exercício quer evitar. O que vem aqui é uma síntese do que o benchmark mostrou, não um placar.
O cenário completo, em um único benchmark
Leia as duas colunas desta tabela — “Renders JS?” e “Built-in crawl queue” — e os três trabalhos praticamente se explicam sozinhos.
| Ferramenta | Linguagem | Renderiza JS? | Recall estático | Saída estruturada | Fila de crawl nativa | Peso de configuração | Licença |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Sim (browser) | 6/6 (página 1) | Esquema CSS | BFS/DFS nativo | Pesado (2 stacks de navegador) | Apache-2.0 |
| Firecrawl | Self-hosted | Sim (playwright-service) | Markdown completo | Sim | /v1/crawl | O mais pesado (6 containers) | AGPL-3.0 |
| trafilatura | Python | Não | 3/3 article | Não (apenas texto) | Não | Leve | Apache-2.0 |
| Crawlee | Node/TS | Opcional por engine | 12/12 | Via extração | Sim (RequestQueue) | Médio (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Sim | 12/12 | Manual | Não (BFS escrito à mão) | Médio (browser) | Apache-2.0 |
| Puppeteer | Node | Sim (Chrome) | 12/12 | Manual | Não (BFS escrito à mão) | Médio (Chrome) | Apache-2.0 |
| Scrapy | Python | Não | 12/12 | Exportação de feed (JSON/CSV/XML) | Sim (nativo) | Médio (deps do Twisted) | BSD-3 |
| Colly | Go | Não | 12/12 | Via callbacks | Controle de profundidade | Leve (1 binário + Go) | Apache-2.0 |
| Scrapling | Python | Não (HTTP fetcher) | 12/12 | Sim | Não | Médio ([fetchers]) | BSD-3 |
Uma nota sobre os metadados dessa tabela e de tudo abaixo: contagens de estrelas e números de versão foram capturados no início de julho de 2026, e ambos mudam rápido. Atualize nos respectivos GitHub e páginas de pacote antes de tratar qualquer um deles como dado corrente.
Índice de análises individuais
Cada projeto neste comparativo tem uma análise completa correspondente:
- Análise do Crawl4AI
- Análise do Firecrawl
- Análise do trafilatura
- Comparativo Playwright vs Puppeteer
- Análise do Crawlee
- Análise do Scrapy
- Análise do Colly
- Análise do Scrapling
Aqui estão as capas — além de duas capturas reais do teste de renderização em JavaScript, para que a afirmação de “8/8 dinâmicos” não fique só no papel.
Trabalho 1: transformar uma página em texto pronto para LLM
Se o que você quer é Markdown limpo para alimentar um pipeline de RAG, três ferramentas competem — e cada uma foi moldada de um jeito bem diferente.
Crawl4AI é, por baixo do marketing, um gerador de Markdown com navegador. Vale desmontar a história de “seletores com inteligência adaptativa e autoaprendizagem” que aparece nos resultados de busca: isso não existe ali — esse truque é de outra biblioteca (mais sobre isso quando chegarmos ao Scrapling). O que ele realmente faz, faz bem. No site de prática Books to Scrape, ele gerou 13.476 caracteres de Markdown, lida com extração via CSS schema para coletas estruturadas e, com a BFS integrada, percorreu 5 páginas no grafo de crawl enquanto renderizava uma página JavaScript e tirava uma captura de tela. Mas há dois pontos fracos. O Markdown bruto carrega o boilerplate da página, a menos que você ative um filtro de conteúdo, e o 500 intencional voltou com success=false — não porque o Crawl4AI tenha tratado o erro HTTP de forma limpa, mas porque sua própria heurística de conteúdo viu o corpo pequeno do erro e o marcou como minimal_text ... blocked. E a instalação coloca dois stacks de navegador no seu disco. Versão 0.9.0, Apache-2.0, cerca de 71 mil estrelas no início de julho.
Firecrawl é o peso-pesado, e fazer self-host dele realmente funciona — digo “realmente” porque o stack com seis containers (api, playwright-service, redis, rabbitmq, nuq-postgres e foundationdb) de fato subiu e produziu 9.222 caracteres de Markdown pronto para LLM a partir da mesma página Books to Scrape. Ele renderizou uma página JavaScript via o playwright-service empacotado, e a citação de Einstein inserida depois do script apareceu na saída, provando que a renderização foi real. Os dois problemas que encontrei foram culpa do ambiente, não do Firecrawl, e quero ser preciso para ninguém copiar a correção errada: um build a partir do código-fonte esbarrou em uma falha do snapshotter do containerd no colima (eu troquei para as imagens pré-compiladas), e a faixa DNS 198.18.x.x do colima acionou a proteção SSRF do Firecrawl, que eu contornei com ALLOW_LOCAL_WEBHOOKS=true — um ajuste para desenvolvimento local, não algo a desativar em produção. O core self-hosted também não inclui o Fire-engine, a camada antibloco da nuvem, e eu não testei a API cloud. O ponto mais delicado é a licença: o core self-hosted do Firecrawl é AGPL-3.0, o que exige revisão jurídica real antes de qualquer uso comercial, não apenas uma nota de rodapé. Cerca de 148 mil estrelas no início de julho.
trafilatura é o contraponto do grupo, e justamente a ferramenta que as listas de hype de IA costumam esquecer. Sem navegador. Sem linhas estruturadas. Só texto de artigo limpo e rápido em Python puro. No cenário de artigo, ele puxou o título mais todos os 3 de 3 parágrafos reais, eliminou completamente o boilerplate — nada de “Login”, “Subscribe” ou “Copyright” vazando — e ainda recuperou autor e data por cima. Em uma página pública de produto, devolveu 1.324 caracteres de texto limpo. O limite dele é exatamente o que o design sugere: aponte para um catálogo e ele devolve 12 nomes de produto em texto, mas 0 linhas estruturadas — o texto está lá, a estrutura não, e ele não renderiza JavaScript. Versão 2.1.0 (a atual), Apache-2.0, cerca de 6,2 mil estrelas. Para extração puramente de artigos, é o primeiro que eu consideraria.
Essas duas contagens de caracteres em Markdown — 13.476 do Crawl4AI e 9.222 do Firecrawl — vieram da mesma página pública, mas não leia isso como diferença de qualidade. Elas refletem estratégias diferentes de Markdown (quanto do “enfeite” da página cada uma preserva), e não um veredito sobre qual saída é melhor. É a regra do sinal interno de cada ferramenta, agindo à vista de todos.
Trabalho 2: renderizar JavaScript com confiabilidade
Alguns dados simplesmente não existem no HTML até os scripts rodarem, e é aí que um navegador de verdade deixa de ser opcional. Três ferramentas cobrem esse trabalho — e duas delas acabaram sendo quase a mesma ferramenta.
Playwright e Puppeteer empataram em todos os testes que eu apliquei. Ambos renderizaram 8/8 produtos dinâmicos no cenário local e 10 no site público Quotes JS, ambos chegaram a 12/12 de recall estático e ambos lidaram com o 500 sem confusão (o Puppeteer devolve um objeto de resposta em vez de lançar exceção). Nenhum dos dois traz fila de crawl, então ambos precisaram de BFS manual, que alcançou 12 páginas nas profundidades 0–2 do grafo de crawl. A diferença real é de alcance: o Playwright controla Chromium, Firefox e WebKit e fala Python e .NET, enquanto o Puppeteer é mais focado em Chrome e só Node. Dois avisos, porque essas versões mudam rápido: testei o Playwright 1.56.0 contra o 1.61.1 atual e usei apenas Chromium; e o Puppeteer 24.16.0 contra o 25.3.0 atual — então reproduza ou considere isso ao interpretar os dados. Ambos são Apache-2.0; cerca de 92 mil e 95 mil estrelas, respectivamente.
Crawlee é a ferramenta que resolve o problema da fila que as outras duas deixam em aberto. Ela empacota um engine Cheerio (HTTP) e um engine Playwright (browser) sob uma única API, e o contraste em uma mesma página resume bem a proposta: o engine Cheerio viu 0 itens inseridos por JavaScript, o engine Playwright viu 8/8 no cenário local (e 10 no site público), e trocar de um para o outro é uma mudança de uma linha. Ele também oferece uma RequestQueue de verdade, o que garante seu lugar neste grupo, e não no grupo 3. O detalhe que ninguém coloca no título: o engine de navegador exige um npx playwright install separado, cerca de 80 MiB que o npm install crawlee não baixa para você. Versão 3.17.0, TypeScript, Apache-2.0, cerca de 24,6 mil estrelas.
Trabalho 3: fazer crawl rápido, sem navegador
Se não há JavaScript na página, usar navegador é um exagero caro. Três ferramentas HTTP-first competem aqui, uma por filosofia de linguagem, e elas discordam de formas interessantes.
Scrapy é o framework mais robusto do grupo — spiders, exportação de feeds para JSON/CSV/XML, AutoThrottle, tudo isso. Ele acertou 12/12 de recall estático, puxou 3/3 parágrafos do artigo, percorreu 11 páginas nas profundidades 0–2 do grafo de crawl e capturou o 500 via handle_httpstatus_list. O mais interessante é a forma de pensar dele: ele não renderiza, ele reproduz a requisição. Quando foi jogado na página JavaScript, obteve 0 nós — e então a API JSON por trás da mesma página entregou 8/8. Essa é a filosofia do Scrapy em um único dado: encontre a requisição que a página faz e reexecute-a, em vez de dirigir um navegador. O custo é uma pilha de dependências considerável (Twisted, lxml, parsel), e eu só o testei em cenários pequenos. Versão 2.17.0, BSD-3-Clause, cerca de 63 mil estrelas.
Colly é a resposta em Go, e é revigorantemente literal sobre o que é: um binário estático, orientado por callbacks em OnHTML, OnResponse e OnError, com controle de profundidade. Ele acertou 12/12 no estático, puxou 8/8 da API JSON via OnResponse, capturou o 500 via OnError e alcançou 17 páginas em um crawl de profundidade 2 — e vou dizer assim de propósito, porque essa contagem de páginas vem do próprio harness, não de uma garantia de completude que o Colly faça. O que ele não faz é JavaScript: o cenário dinâmico e o site Quotes JS voltaram 0, por design. Você vai precisar do toolchain Go para compilá-lo, e a versão do módulo (v2.3.0) hoje está à frente do release tagueado (v2.2.0). Apache-2.0, cerca de 25 mil estrelas.
Scrapling é a especialista, e faz jus ao rótulo. Os seletores adaptativos dela foram feitos para reencontrar um elemento quando o HTML muda — então, quando eu renomeei a classe-alvo de product-name para product-title, um seletor simples encontrou 0, e o re-match adaptativo recuperou o elemento rastreado mesmo assim. Na extração HTTP pura, ela alcançou 12/12 no estático e 8/8 na API JSON. E aqui vai um detalhe que a própria documentação não esconde: em um teste sintético com vários elementos, ela recuperou 1 de 3 — isto é, rastreamento resiliente de elemento, não recuperação total, então não exagere mentalmente na promessa. O pip install scrapling base também precisa do extra [fetchers] para funcionar, e o StealthyFetcher é uma observação de compliance, não algo que eu colocaria em slide. Versão 0.4.10 (a atual), BSD-3-Clause, cerca de 68,7 mil estrelas.
O padrão por trás dos três trabalhos
Quando colocamos as nove lado a lado, surge algo bem claro. Recall estático completo — um 12/12 seco — é o mínimo esperado de qualquer ferramenta HTTP-first; nenhuma falhou no caso fácil, então isso não diferencia ninguém. As ferramentas com navegador só justificam o peso extra quando JavaScript realmente entra em cena, e todas pagam por isso na instalação: um stack de browser, uma instalação extra ou uma frota inteira de containers. E a coluna “fila de crawl nativa” é, na prática, a linha que separa framework de engine — Scrapy e Crawlee trazem orquestração, enquanto Playwright e Puppeteer exigem que você escreva a BFS manualmente. Esse é o formato do mercado. Ninguém vence no geral porque ninguém está jogando o mesmo jogo.
Então, qual você deveria escolher de verdade?
O benchmark se recusa a coroar um campeão porque a resposta certa não é uma ferramenta, e sim uma pergunta — qual dos três trabalhos você vai executar?
- Precisa de Markdown pronto para LLM? Vá de trafilatura quando a meta for texto limpo de artigo; de Crawl4AI quando você também quiser extração por CSS e renderização JavaScript na mesma biblioteca; e de Firecrawl quando a necessidade for um serviço self-hosted e você puder lidar tanto com a licença AGPL-3.0 quanto com o peso de seis containers.
- Precisa renderizar JavaScript? Use Playwright ou Puppeteer para a renderização bruta — escolha pelo engine e pela linguagem, já que fora isso eles empatam — e use Crawlee quando quiser que a orquestração do crawl venha pronta, em vez de ser escrita na mão.
- Vai fazer crawl de páginas estáticas ou APIs reproduzíveis em escala? Scrapy para um framework Python completo, Colly para velocidade bruta em Go com um único binário, e Scrapling quando sobreviver à mudança de markup for a dor recorrente do seu caso.
Combine a ferramenta com o trabalho e qualquer uma delas vira uma escolha defensável. Pegue a categoria errada — uma ferramenta de navegador para páginas estáticas, ou um parser HTTP para um app JavaScript — e até a biblioteca mais bem avaliada da internet vai te deixar na mão.
Onde uma API de IA gerenciada entra nessa história
Todas as ferramentas acima são gratuitas, open source e podem ser executadas por você. Mas esse também é o trade-off comum que o benchmark deixa evidente: você passa a ser dono do ambiente de navegador, do código de crawl, da corrida anti-bot e de toda a manutenção. Para muitas equipes, esse controle é exatamente o objetivo, e o mapa de licenças importa quando você assume isso — a maior parte do campo é permissiva (Apache-2.0 em Crawl4AI, Crawlee, Playwright, Puppeteer e Colly; BSD-3 em Scrapy e Scrapling), com o core self-hosted do Firecrawl em AGPL-3.0 sendo o caso que pede revisão séria antes de uso comercial.
Mas repare no que o benchmark também mostrou: o que essas ferramentas não fazem. Renderizar, fazer crawl, estruturar e driblar bloqueios — raramente tudo ao mesmo tempo, e nunca sem manutenção da sua parte. Uma API gerenciada de scraping com IA compacta essa pilha em uma chamada. Nossa própria superfície para desenvolvedores na Thunderbit é uma dessas opções, e, para um público técnico, o que importa é a API, o servidor MCP e a CLI — não a extensão de navegador. POST /distill retorna Markdown limpo e POST /extract retorna JSON definido por schema, com renderização JavaScript e anti-bot tratados no servidor, em vez de na sua máquina. Há um servidor MCP oficial para agentes e assistentes de programação — thunderbit_suggest_fields é gratuito para planejar a extração; depois thunderbit_distill (1 crédito) e thunderbit_extract (20 créditos) fazem o trabalho — e uma CLI que você pode instalar com npx @thunderbit/thunderbit-cli para uso no terminal e em jobs agendados. Para quem não é desenvolvedor no time, também existe a extensão Chrome sem código, e a página de preços cobre as duas frentes.
A troca é a mesma que atravessa todo este benchmark: manter até nove bibliotecas você mesmo, pagando zero por chamada, ou terceirizar a infraestrutura e pagar por requisição. Nenhuma opção está errada. Tudo depende de quanto da pilha você realmente quer assumir. Se preferir ver na prática como a extração funciona, o canal da Thunderbit no YouTube mostra o passo a passo.
Veredito
Não existe um único melhor scraper open source, e qualquer lista que entregue um com muita confiança está escondendo a pergunta que realmente decide isso: qual dos três trabalhos você vai fazer? Transformar página em texto, renderizar JavaScript ou fazer crawl rápido sem navegador — o campo se organiza nitidamente nesses blocos, e dentro de cada um a escolha depende da linguagem e do peso de configuração, não de um campeão universal.
Se você levar um hábito deste texto, leve este: teste nas suas próprias páginas antes de fechar com qualquer ferramenta. Todos os números aqui podem ser reproduzidos no repositório de benchmark justamente por isso — porque a ferramenta que lidera um resumo genérico e a ferramenta que sobrevive aos seus alvos reais nem sempre são a mesma.
Experimente Thunderbit para Extração de Dados da Web Get Started Free
FAQs
Qual é o melhor scraper web open source? Não existe um único melhor — depende do trabalho. Para texto pronto para LLM, trafilatura ou Crawl4AI; para renderização JavaScript, Playwright, Puppeteer ou Crawlee; para crawl HTTP rápido, Scrapy ou Colly. Em um banco de testes compartilhado, cada ferramenta foi mais forte dentro da própria categoria e claramente mais fraca fora dela, e é por isso que rankings genéricos enganam.
Quais scrapers open source renderizam JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer e o engine Playwright do Crawlee renderizam JavaScript. Scrapy, Colly, trafilatura e o fetcher HTTP padrão do Scrapling não renderizam — eles ou precisam de uma API reproduzível por trás da página (a abordagem do Scrapy, que chegou a 8/8 via endpoint JSON) ou de um modo separado com navegador.
Preciso de um navegador headless para raspar um site? Só se os dados aparecerem depois que o JavaScript roda. Se uma requisição HTTP simples mais um parser já alcançam o conteúdo, usar navegador é um exagero caro — Scrapy, Colly ou Scrapling serão bem mais leves e rápidos nesse caso.
Qual dessas ferramentas tem a licença mais amigável para uso comercial? A maioria é permissiva: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) ou BSD-3-Clause (Scrapy, Scrapling). A exceção é o core self-hosted do Firecrawl, que é AGPL-3.0 e merece revisão jurídica de verdade antes de você construir um produto comercial em cima dele.
Esses números de benchmark são reproduzíveis? Sim. Todos os runners, cenários e resultados brutos estão em um repositório público com licença MIT. Só vale manter uma ressalva em mente: recall e resultados estruturais são comparáveis entre ferramentas, mas contagens absolutas de caracteres valem apenas como sinal interno de cada ferramenta, porque cada pacote replica os cenários em vez de compartilhar uma cópia canônica única — então compare taxas e aprovado/reprovado, não o total bruto de caracteres.
