Quase todo roundup de “melhor scraper open source” tem um defeito meio silencioso: ninguém roda as ferramentas nas mesmas páginas. O Scrapy é testado em uma notícia, o Playwright em uma demo qualquer de e-commerce, o Colly no que o autor tinha à mão — e depois tudo é comparado como se esses números realmente significassem a mesma coisa. Esse tipo de ranking diz mais sobre as páginas do que sobre as ferramentas.
Então eu fiz a coisa chata e óbvia que essas listas pulam. Montei um conjunto único de testes e passei as nove ferramentas por ele: um catálogo estático, um catálogo renderizado por JavaScript, um artigo escondido em meio a menu e rodapé, um HTTP 500 proposital, um pequeno grafo de links internos, além de dois sites públicos de teste/prática. Mesma verdade de referência, mesmas medições, todas as execuções. Os scripts e os dados brutos estão em um repositório público de benchmark, para você repetir tudo por conta própria. O resultado não foi o placar certinho que os roundups prometem — não existe um vencedor absoluto. Existem três trabalhos diferentes, e as nove ferramentas se distribuem quase sozinhas entre eles.
Experimente o Thunderbit para extração de dados web
Como o benchmark funcionou, e a única limitação que vou dizer em voz alta
Todas as ferramentas receberam os mesmos formatos de teste: 12 produtos estáticos distribuídos em duas páginas, 8 produtos inseridos por JavaScript depois de um atraso, um artigo cercado de boilerplate de navegação e rodapé em torno de três parágrafos reais, um erro 500 intencional e um grafo de links internos. Esse desenho é o que faz os resultados se alinharem — “8/8 produtos dinâmicos” quer dizer exatamente a mesma coisa, seja o resultado vindo de Puppeteer ou de Crawlee.
Aqui está o limite que a maioria dos roundups ignora. O conjunto de cada ferramenta espelha suas próprias cópias desses testes, então a contagem absoluta de caracteres não é estritamente comparável entre ferramentas — leia isso como um sinal interno de cada ferramenta, nunca como uma nota entre ferramentas. Os números que são comparáveis são o recall (trate como taxa), o sucesso/falha em JavaScript e o comportamento estrutural. Uma observação no mesmo espírito: a execução do Crawl4AI no catálogo estático cobriu só a página 1, então seu 6/6 é um recall total num recorte menor, enquanto as outras ferramentas rastrearam as duas páginas para chegar a 12/12 — um escopo menor, não uma perda parcial. A explicação completa, teste por teste, está no texto de metodologia.
Mais uma ressalva antes dos números. Cada pacote também traz uma pontuação provisória de pesquisa, mas eu estou deliberadamente sem mostrar isso em forma de ranking. Elas serviam como apoio interno para checar cada ferramenta contra a própria evidência, não como tabela de classificação — e publicá-las assim recriaria exatamente o problema de falsa precisão que este exercício tenta evitar. Isto é uma síntese do que o benchmark mostrou, não um placar.
O campo inteiro, em um único benchmark
Leia as duas colunas desta tabela — "Renderiza JS?" e "Fila de crawl integrada" — e os três trabalhos praticamente se revelam sozinhos.
| Ferramenta | Linguagem | Renderiza JS? | Recall estático | Saída estruturada | Fila de crawl integrada | Peso de configuração | Licença |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Sim (browser) | 6/6 (página 1) | Schema CSS | BFS/DFS integrado | Pesado (2 stacks de browser) | Apache-2.0 |
| Firecrawl | Self-hosted | Sim (serviço Playwright) | Markdown completo | Sim | /v1/crawl | O mais pesado (6 containers) | AGPL-3.0 |
| trafilatura | Python | Não | 3/3 do artigo | Não (apenas texto) | Não | Leve | Apache-2.0 |
| Crawlee | Node/TS | Opcional no motor | 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 (nativa) | Médio (dependências 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 (busca HTTP) | 12/12 | Sim | Não | Médio ([fetchers]) | BSD-3 |
Uma nota sobre os metadados dessa tabela e de tudo mais abaixo: contagem de estrelas e versões foram capturadas no início de julho de 2026, e ambas mudam rápido. Atualize esses dados no GitHub e na página do pacote de cada projeto antes de tratar qualquer um deles como atual.
Índice das análises individuais
Cada projeto neste roundup tem uma análise profunda correspondente:
- Análise do Crawl4AI
- Análise do Firecrawl
- Análise do trafilatura
- Comparação entre Playwright e Puppeteer
- Análise do Crawlee
- Análise do Scrapy
- Análise do Colly
- Análise do Scrapling
Aqui estão as capas deles — além de duas capturas reais do teste de renderização JavaScript, para que a afirmação de “8/8 dinâmico” não seja só um número na página.
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 elas não poderiam ser mais diferentes.
Crawl4AI é, por trás do marketing, um gerador de Markdown apoiado por browser. Vale a pena derrubar a história de “seletores de inteligência adaptativa com autoaprendizado” que aparece junto dele nos resultados de busca: isso não existe ali — esse truque pertence a 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 schema CSS para coletas estruturadas e seu crawl em BFS integrado percorreu 5 páginas no grafo de teste enquanto renderizava uma página JavaScript e capturava uma screenshot. 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 proposital voltou como success=false — não porque o Crawl4AI tenha capturado o erro HTTP de forma elegante, mas porque sua própria heurística de conteúdo olhou para o corpo minúsculo de erro e o marcou como minimal_text ... blocked. E a configuração ainda joga duas stacks de browser 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 hospedá-lo você mesmo realmente funciona — digo “realmente” porque a pilha com seis containers (api, playwright-service, redis, rabbitmq, nuq-postgres e foundationdb) subiu de fato 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 por meio do playwright-service incluído, e a citação do Einstein que aparece depois do script saiu no resultado, provando que a renderização foi real. Dois problemas que encontrei foram culpa do ambiente, não do Firecrawl, e quero ser preciso para ninguém copiar a correção errada: uma build a partir do código-fonte falhou por uma instabilidade do snapshotter do containerd no colima (troquei pelas imagens pré-compiladas), e a faixa de DNS 198.18.x.x do colima acionou a proteção SSRF do Firecrawl, que eu contornei com ALLOW_LOCAL_WEBHOOKS=true — um ajuste de desenvolvimento local, não algo para desativar em produção. O núcleo self-hosted também não inclui o Fire-engine, a camada anti-bloqueio da nuvem, e eu não testei a API cloud. O ponto mais importante é a licença: o core self-hosted do Firecrawl é AGPL-3.0, o que exige uma análise jurídica real antes de qualquer uso comercial, não é rodapé. Cerca de 148 mil estrelas no início de julho.
trafilatura é o dissidente do grupo — e o que as listas movidas a hype de IA vivem esquecendo. Sem browser. Sem linhas estruturadas. Só texto de artigo rápido e limpo em Python puro. No fixture de artigo, ele trouxe o título mais todos os 3 de 3 parágrafos reais, removeu completamente o boilerplate — sem vazar “Login”, “Subscribe” ou “Copyright” — e ainda recuperou autor e data. Em uma página pública de produto, retornou 1.324 caracteres de texto limpo. Seu limite é exatamente o que o desenho sugere: aponte para um catálogo e ele devolve 12 nomes de produtos como 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 pura de artigos, é a primeira opção que eu pegaria.
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 “chrome” da página cada uma preserva), não um veredito sobre qual saída é melhor. É a regra do sinal interno de cada ferramenta, de cima, acontecendo às claras.
Trabalho 2: renderizar JavaScript com confiabilidade
Alguns dados simplesmente não existem no HTML até os scripts rodarem, e é aí que um browser 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 joguei neles. Ambos renderizaram 8/8 produtos dinâmicos no fixture local e 10 no site público Quotes JS, ambos tiveram 12/12 de recall estático, e ambos lidaram com o 500 sem problemas (o Puppeteer devolve um objeto de resposta em vez de lançar exceção). Nenhum dos dois traz fila de crawl, então foi preciso escrever um BFS manual para percorrer o grafo de 12 páginas. A única diferença real é o alcance: o Playwright controla Chromium, Firefox e WebKit e fala Python e .NET, enquanto o Puppeteer é centrado em Chrome e só funciona com Node. Duas observações, porque as versões mudam rápido: eu testei Playwright 1.56.0 contra a versão atual 1.61.1 e usei apenas Chromium, e testei Puppeteer 24.16.0 contra a atual 25.3.0 — então reexecute ou considere isso ao interpretar os números. 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. Ele embrulha um motor Cheerio (HTTP) e um motor Playwright (browser) por trás de uma única API, e o contraste em uma página resume bem a proposta: o motor Cheerio viu 0 itens injetados por JavaScript, o motor Playwright viu todos os 8/8 localmente (e 10 no site público), e trocar entre eles é uma mudança de uma linha. Ele também oferece uma RequestQueue de verdade, e é isso que o coloca neste trabalho, em vez do trabalho 3. O detalhe que ninguém destaca: o motor de browser precisa de um npx playwright install separado, cerca de 80 MiB que 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: rastrear rápido, sem browser
Sem JavaScript na página, um browser vira exagero caro. Três ferramentas centradas em HTTP competem aqui, cada uma com sua filosofia de linguagem, e elas divergem de maneiras interessantes.
Scrapy é o framework mais robusto do grupo — spiders, exportação de feeds em JSON/CSV/XML, AutoThrottle, tudo. Ele bateu 12/12 no recall estático, coletou os 3/3 parágrafos do artigo, percorreu 11 páginas nas profundidades 0–2 do grafo de crawl e capturou o 500 por meio de handle_httpstatus_list. O mais interessante é a visão de mundo dele: ele não renderiza, ele reproduz a requisição. Quando jogado contra a página JavaScript, ele 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 reproduza-a, não dirija um browser. O custo é uma pilha de dependências maior (Twisted, lxml, parsel), e eu só o testei em fixtures pequenos. Versão 2.17.0, BSD-3-Clause, cerca de 63 mil estrelas.
Colly é a resposta do Go, e é refrescantemente literal sobre o que é: um único binário estático, orientado a callbacks via OnHTML, OnResponse e OnError, com controle de profundidade. Ele acertou 12/12 de recall estático, trouxe 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 eu vou dizer exatamente assim, porque essa contagem vem do próprio harness, não é uma garantia de completude que o Colly prometeu. O que ele não faz é JavaScript: o fixture dinâmico e o site Quotes JS voltaram 0, por design. Você vai precisar de toolchain Go para compilá-lo, e a versão do módulo (v2.3.0) hoje está à frente da release marcada (v2.2.0). Apache-2.0, cerca de 25 mil estrelas.
Scrapling é o especialista, e merece esse rótulo. Seus seletores adaptativos foram criados para reencontrar um elemento depois que o HTML muda — então, quando eu troquei a classe HTML de um alvo de product-name para product-title, um seletor comum marcou 0, e o re-match adaptativo recuperou o elemento acompanhado mesmo assim. Na extração HTTP simples, ele bateu 12/12 no estático e 8/8 na API JSON. O ponto que a própria documentação não esconde: em um teste sintético com múltiplos elementos, ele recuperou 1 de 3 — isso é rastreamento resiliente de elementos, não recuperação total, então não exagere na sua cabeça. O pip install scrapling base também precisa do extra [fetchers] para começar, e o StealthyFetcher é uma ressalva de conformidade, não uma feature que eu colocaria num 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
Coloque as nove lado a lado e algo limpo aparece. Recall estático total — um 12/12 seco — é o mínimo esperado para qualquer ferramenta HTTP-first; nenhuma delas falhou no caso fácil, então isso não diferencia. As ferramentas com browser só justificam o peso extra quando JavaScript realmente entra no jogo, e todas pagam por isso na configuração: uma stack de browser, uma instalação extra ou uma fazenda inteira de containers. E a coluna “fila de crawl integrada” é, na prática, a linha que separa um framework de um motor — Scrapy e Crawlee trazem a orquestração, enquanto Playwright e Puppeteer fazem você escrever o BFS manualmente. Essa é a forma do campo. 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 vencedor porque a resposta certa não é uma ferramenta — é uma pergunta: qual dos três trabalhos você está fazendo?
- Precisa de Markdown pronto para LLM? Use trafilatura quando a meta for texto de artigo limpo; Crawl4AI quando você também quiser extração CSS e renderização JavaScript em uma única biblioteca; e Firecrawl quando quiser especificamente um serviço self-hosted e puder aceitar tanto a licença AGPL-3.0 quanto o peso de seis containers.
- Precisa renderizar JavaScript? Playwright ou Puppeteer para a renderização bruta — escolha pelo engine e pela linguagem, porque fora isso eles empatam — e Crawlee quando você também quiser a orquestração do crawl pronta, em vez de escrevê-la à mão.
- Quer rastrear 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 é a sua dor recorrente específica.
Combine a ferramenta com o trabalho e todas elas são escolhas defensáveis. Pegue a categoria errada — uma ferramenta com browser 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 entra uma API de IA gerenciada
Todas as ferramentas acima são gratuitas, open source e ficam sob seu controle. Esse também é o trade-off que o benchmark mais deixa exposto: você assume o ambiente de browser, o código de crawl, a corrida contra bloqueios e 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, o único que merece análise jurídica séria antes de uso comercial.
Mas repare no que o benchmark também mostrou: o que essas ferramentas não fazem. Renderizar, rastrear, estruturar e contornar bloqueios — raramente tudo ao mesmo tempo, e nunca sem manutenção. Uma API gerenciada de scraping com IA reduz essa pilha a uma chamada. A nossa própria superfície para desenvolvedores no Thunderbit é uma opção nesse espaço, e para um público técnico o que importa é a API, o servidor MCP e a CLI, não a extensão de browser. POST /distill retorna Markdown limpo e POST /extract retorna JSON definido por schema, com renderização JavaScript e proteção anti-bot tratadas no servidor, não na sua máquina. Há um servidor MCP oficial para agentes e assistentes de código — thunderbit_suggest_fields roda grátis para planejar uma 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 terminal e jobs de cron. Para quem não é desenvolvedor na equipe, também existe uma extensão Chrome sem código, e a precificação cobre as duas frentes.
O trade-off é o mesmo que atravessa todo este benchmark: rodar e manter até nove bibliotecas por conta própria, com custo zero por chamada, ou terceirizar o encanamento e pagar por requisição. Nenhuma das escolhas está errada. Tudo depende de quanto da pilha você realmente quer assumir. Se preferir ver como a extração funciona na prática, o canal do Thunderbit no YouTube mostra o passo a passo.
{{INTERNAL_BLOG_LINKS}}
Veredito
Não existe um único melhor scraper open source, e qualquer lista que te entregue um com muita convicção está escondendo a pergunta que realmente decide tudo: qual dos três trabalhos você está fazendo? Transformar página em texto, renderizar JavaScript ou rastrear rápido sem browser — o campo se organiza claramente nesses grupos, e dentro de cada um a escolha depende de linguagem e peso de configuração, não de um campeão universal.
Se você levar um único hábito desta leitura, leve este: teste nas suas próprias páginas antes de se comprometer com qualquer coisa. Todos os números aqui são reproduzíveis no repositório de benchmark exatamente por esse motivo — porque a ferramenta que lidera um roundup genérico e a ferramenta que sobrevive aos seus alvos reais nem sempre são a mesma.
Experimente o Thunderbit para extração de dados web Get Started Free
Perguntas frequentes
Qual é o melhor scraper open source? Não existe um único — 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 benchmark compartilhado, cada ferramenta foi mais forte dentro da própria categoria e claramente mais fraca fora dela, por isso rankings “tamanho único” enganam.
Quais scrapers open source renderizam JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer e o motor Playwright do Crawlee renderizam JavaScript. Scrapy, Colly, trafilatura e o buscador HTTP padrão do Scrapling não renderizam — eles precisam de uma API reproduzível por trás da página (a abordagem do Scrapy, que conseguiu 8/8 no endpoint JSON) ou de um modo separado com browser.
Preciso de um browser headless para raspar um site? Só se os dados aparecerem depois que o JavaScript rodar. Se uma requisição HTTP comum mais um parser conseguem alcançar o conteúdo, um browser é um excesso caro — Scrapy, Colly ou Scrapling serão muito mais leves e rápidos nesse caso.
Qual deles 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. Todo runner, fixture e resultado bruto está em um repositório público com licença MIT. A única ressalva a manter em mente: recall e resultados estruturais são comparáveis entre ferramentas, mas a contagem absoluta de caracteres é apenas um sinal interno de cada ferramenta, porque cada pacote espelha os fixtures em vez de compartilhar uma cópia canônica única — então compare taxas e sucesso/falha, não totais brutos de caracteres.
