Análise do Scrapy 2.17: ele pula o navegador e vai direto à API

O Scrapy acaba sendo rotulado como uma ferramenta que “não dá conta de sites modernos” porque não executa JavaScript. Mas essa fama é justamente o contrário da realidade. Não renderizar a página é a proposta central — e, quando você vê isso funcionando na prática, deixa de parecer uma limitação.

Eu mesmo confirmei isso em uma única execução. Montei um catálogo de teste renderizado com JavaScript, apontei o Scrapy para a página que um navegador mostraria e recebi de volta 0 cards de produto. Depois, direcionei o mesmo spider para o endpoint JSON que a página chamava discretamente em segundo plano e obtive 8/8 itens, limpos. Mesma ferramenta, mesma sessão, resultados opostos — e a diferença entre esses dois números é justamente o tema desta análise.

O que o Scrapy realmente é — e o que ele não é

O Scrapy é um framework em Python para rastrear sites e extrair dados estruturados. Essa é, inclusive, a própria definição dos mantenedores na documentação geral, e depois de usar a ferramenta dá para ver que a descrição é precisa — sem exagero de marketing para corrigir. Ele já é antigo e consolidado o bastante para ser a resposta automática quando um desenvolvedor Python pergunta com o que profissionais sérios fazem scraping. E os números do repositório confirmam isso: cerca de 62.981 estrelas no GitHub em 2026-07-07 (scrapy/scrapy), além de 11.773 forks e 590 issues abertas na mesma data. A licença é BSD-3-Clause, exige Python 3.10 ou superior, e a versão que testei foi a 2.17.0, lançada justamente na manhã em que rodei os testes — ou seja, sem asterisco de versão desatualizada aqui.

A linha que o separa da nova turma de crawlers com IA é esta: por padrão, o Scrapy trabalha só com HTTP. Sem navegador. Sem motor de renderização. Ele baixa o HTML pela rede, entrega o conteúdo a um parser e permite extrair campos com seletores CSS ou XPath. Chamar isso de limitação é apenas metade da história e ignora a intenção de projeto. A premissa do Scrapy é que abrir um Chrome sem interface para um scraping rotineiro geralmente é a escolha errada — o caminho mais inteligente é localizar a requisição de dados que a própria página já faz e acessá-la diretamente.

E isso não é interpretação minha sobre a ferramenta. A própria documentação de conteúdo dinâmico diz isso claramente: primeiro localize e replique a requisição de dados subjacente; recorra a um navegador headless apenas como alternativa quando reproduzir essa requisição não for viável. A maioria dos scrapers abre o navegador primeiro e nem pensa na API. O Scrapy inverte essa lógica.

Principais recursos e a decisão de design por trás de cada um

Por baixo do capô, o Scrapy é um conjunto de componentes que parte de uma suposição sobre você: que você é um desenvolvedor que quer controle, não um assistente mágico de um clique.

Spiders. Você escreve uma classe, fornece URLs iniciais e define um callback parse que retorna itens ou segue links adicionais. Isso exige bem mais código do que um extrator no-code — as regras de extração são suas —, mas em troca você tem controle exato sobre o que é capturado e para onde o rastreamento vai em seguida.

Seletores. O parsing usa parsel, que por sua vez se apoia em lxml. CSS e XPath têm o mesmo peso aqui; não são adições de última hora. É justamente esse suporte via lxml que mantém as seleções rápidas e faz o código de extração parecer intenção clara, em vez de um emaranhado de cortes de string.

Exportação de feeds. Aponte um spider para um arquivo e o Scrapy serializa os itens em JSON, JSON Lines, CSV ou XML sem precisar de infraestrutura extra. No meu teste, um spider de catálogo estático gravou JSON e CSV sem que eu escrevesse uma única linha de código de exportação — o recurso de feed export funciona de verdade e entrega o que promete.

AutoThrottle e controles de rastreamento. As requisições são agendadas de forma assíncrona sobre Twisted, e você conta com limites de concorrência, atrasos entre downloads, restrição de profundidade, AutoThrottle para ajuste adaptativo de taxa e respeito ao robots.txt. Esses controles evitam que um crawl amplo vire um incidente de sobrecarga no servidor.

Só HTTP, agora como vantagem. Não usar navegador significa menor consumo de memória, maior throughput e nenhum motor de renderização para administrar — desde que os dados que você quer estejam acessíveis via HTTP puro. E, mais vezes do que a turma que pensa primeiro no navegador imagina, eles estão.

Configuração: a pilha de dependências que ninguém mostra em captura de tela

A instalação foi tão tranquila que quase não mereceria comentário — mas, para um framework desse porte, vale dizer de forma clara. pip install Scrapy==2.17.0 concluiu sem problemas em um ambiente virtual novo no macOS arm64, baixando wheels binários, sem compilar nada à força. Nada dramático para relatar — e esse é exatamente o ponto.

Mas veja o que veio junto. scrapy version -v mostrou o Scrapy 2.17.0 apoiado em lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 e cryptography 49.0.0, com parsel, cssselect e tldextract completando o pacote. É uma presença de peso — a pegada completa de um framework de crawl, não de um simples parser HTML de um arquivo só. Nesta máquina, havia wheels para tudo, então a instalação continuou sem atrito. Em outras configurações, a documentação oficial ainda alerta para fricções específicas de plataforma; historicamente, é a parte de cryptography e Twisted da pilha que costuma causar dor de cabeça. Então, se você estiver em um ambiente incomum, vale reservar tempo para isso. Aqui, a configuração foi suave; mas o tamanho do que é instalado ainda é algo importante de saber antes de decidir, porque você está puxando um framework inteiro — e ele pesa como um.

Teste prático: o que funcionou bem

Depois de instalado, o caminho estático funcionou sem problemas. Recall total, nada ficou de fora.

Teste	Resultado	Tempo de execução
Catálogo estático local + paginação	12/12 produtos	0.557s
Exportação CSV do catálogo estático	12 linhas gravadas	(mesma execução)
Extração de artigo	título + 3/3 parágrafos do corpo	0.416s
Grafo de crawl, DEPTH_LIMIT=2	11 páginas nas profundidades 0/1/2	0.904s
Página local 500	status 500 capturado, sem travar	0.424s
Books to Scrape (público)	20 produtos	2.053s
Spider Quotes to Scrape (público)	12 citações	3.465s

O spider do catálogo estático percorreu a paginação da primeira à segunda página e capturou 12/12 registros esperados, depois os exportou em JSON e CSV na mesma execução. O teste de artigo é o mais interessante. O Scrapy não tentou transformar a página automaticamente em Markdown limpo — em vez disso, me permitiu mirar os campos do article com seletores explícitos e separar o texto de navegação e rodapé em campos distintos. Resultado: recebi 3/3 parágrafos do corpo, com o conteúdo repetitivo isolado em vez de misturado à saída. Esse é o acordo: você escreve os seletores e recebe exatamente o que pediu, sem extras indesejados.

O controle de crawl também se comportou bem em pequena escala. Com DEPTH_LIMIT=2, um atraso curto entre downloads, concorrência por domínio e robots.txt ativado, o grafo de crawl percorreu 11 páginas nas profundidades 0, 1 e 2, e o controle de profundidade funcionou corretamente. O tratamento de falhas foi igualmente sem drama. A página 500 proposital retornou um item estruturado com status 500 exposto via handle_httpstatus_list — sem exceção, sem interromper a execução. O Scrapy trata status de erro como algo que você resolve na lógica do spider, e não como uma surpresa que derruba o crawl.

Teste prático: a barreira do JavaScript e a porta ao lado

Agora, o resultado em torno do qual esta análise foi construída.

Apontei o fetcher HTTP do Scrapy para um catálogo de teste renderizado com JavaScript. Ele baixou o HTML de origem, encontrou 0 nós .product-card e seguiu adiante — porque nunca executou o script que desenharia esses cards. A página pública Quotes to Scrape JS contou a mesma história: 0 nós de citação renderizados. Se você parasse o teste aí, descartaria o Scrapy como inadequado para qualquer coisa feita nesta década.

Mas não pare por aí. Esse catálogo em JavaScript era alimentado, em segundo plano, por uma API JSON — como acontece com a maioria deles. Eu apontei o mesmo spider para esse endpoint e obtive 8/8 produtos em 0.416s — sem navegador, sem renderização, apenas uma requisição para a URL que a página já chamava e o parsing do JSON que voltou.

Essa comparação lado a lado resume a filosofia de reproduzir a requisição. A página renderizada é uma distração; os dados estavam atrás de uma API o tempo todo, e o design do Scrapy te conduz a acessá-la diretamente em vez de pagar por um navegador headless para ficar observando a montagem da página. É mais rápido, mais leve e quebra menos — um contrato de API é muito mais estável do que um amontoado de DOM construído no cliente. O porém é que isso exige trabalho manual. Você precisa abrir a aba de rede, encontrar a requisição e reproduzir cabeçalhos e parâmetros por conta própria. O Scrapy não descobre a API para você; ele apenas torna o acesso trivial depois que você já a encontrou.

Duas fronteiras, deixadas bem claras. Quando realmente não existe uma requisição subjacente para reproduzir — ou seja, os dados são inseridos apenas pelo client-side rendering, sem nenhuma API por trás — o Scrapy precisa de uma integração com navegador headless que você mesmo conecta, e eu não testei esse caminho nesta rodada. Além disso, tudo o que descrevi acima foi executado em fixtures pequenas e páginas públicas de demonstração. Não rodei um crawl de 100 a 1.000 páginas, então não faço nenhuma afirmação sobre memória, throughput ou comportamento de retry em escala. O núcleo assíncrono e os controles de crawl são sinais fortes, mas sinal não é medição.

Prós e contras

Prós:

• Design só com HTTP: rápido e leve — 12/12 de recall estático em cerca de meio segundo, 8/8 via API JSON em 0.416s, sem custo de navegador.
• A abordagem de reproduzir a requisição realmente entrega: uma página JS que retornou 0 cedeu todos os 8 itens pela API de origem.
• Seletores CSS e XPath baseados em lxml deixam o código de extração legível e rápido.
• Exportação para JSON/CSV/XML sem precisar escrever infraestrutura extra.
• Tratamento explícito de erro — um 500 vem como status para você capturar, não como crash.
• Controles de crawl maduros: concorrência, atrasos, limite de profundidade, AutoThrottle e robots.txt.
• Licença BSD-3-Clause permissiva; instalação limpa em uma máquina atual.

Contras:

• Não renderiza JavaScript por projeto — 0 nós em uma página renderizada no cliente até você localizar a API por conta própria.
• Encontrar a requisição subjacente é manual; o Scrapy não aponta o endpoint para você.
• Pilha de dependências considerável (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — aqui foi tranquilo, mas historicamente pode causar atrito em plataformas incomuns.
• Exige mais código do que ferramentas no-code ou de extração automática; os spiders são seus para escrever e manter.
• Meus testes cobriram fixtures pequenas e sites de demonstração, não um crawl grande — a confiabilidade em escala ainda não foi comprovada nesta análise.

Para quem é — e quem deveria passar adiante

O Scrapy é para desenvolvedores que querem controle em nível de código e pensam em requisições, não em páginas. Se, ao encontrar um site JavaScript lento, sua primeira reação é “tem uma API escondida aqui em algum lugar”, a ferramenta foi feita exatamente para esse instinto. Ela recompensa quem se sente confortável escrevendo seletores, lendo a aba de rede e assumindo a lógica de extração do começo ao fim. Para sites estáticos, catálogos paginados e qualquer coisa suportada por um endpoint JSON descobrível, ele é rápido e preciso.

Passe adiante — ou, no mínimo, combine com outra solução — se escrever e manter spiders não é o tipo de trabalho em que você quer gastar seu tempo, ou se seus alvos rendem os dados apenas no lado do cliente, sem nenhuma requisição reproduzível, e você não quer acoplar um navegador headless por conta própria. E, se a expectativa era apontar uma ferramenta para uma URL e receber um output estruturado limpo sem escrever regras de extração, isso nunca foi o papel do Scrapy — e ele nunca fingiu o contrário.

Alternativas e onde o Thunderbit entra

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

Comece pelo que você está aceitando: um framework gratuito e open source que você mesmo executa e mantém. Você fica dono dos spiders, da pilha de dependências e do trabalho de descobrir a requisição de dados de cada site. Em troca, não paga por requisição, mantém tudo internamente e ganha controle total. Para muitas equipes, essa é a escolha certa — e esta análise não pretende convencer ninguém do contrário.

A troca real aparece no problema de renderização e mudanças no site, e a resposta do Scrapy é que você resolve isso: encontra a API, reproduz a requisição e trata o caso sem API conectando um navegador por conta própria. Uma API gerenciada de scraping com IA tira essa camada das suas costas. É aí que entra o Thunderbit para leitores técnicos: uma API de scraping com IA, mais servidor MCP e CLI — não a extensão de navegador que o público de vendas e operações usa. POST /distill transforma uma página em Markdown limpo, pronto para LLM; POST /extract devolve JSON estruturado com base em um schema definido por você; e ambos lidam com renderização JavaScript, anti-bot e conteúdo dinâmico no servidor — inclusive no caso client-rendered em que o Scrapy pede que você recorra a um navegador. Há um servidor MCP para agentes de IA e assistentes de programação (com um thunderbit_suggest_fields gratuito para mapear uma página antes de gastar qualquer coisa), além de uma CLI via npx @thunderbit/thunderbit-cli para terminal, CI ou tarefas agendadas.

A diferença não é qualidade — é responsabilidade. O Scrapy é um framework de engenharia explícito: você mantém o spider, o pipeline e a estratégia para JS, e ganha controle total sem custo por chamada. A stack do Thunderbit assume a camada de renderização e extração como serviço gerenciado, para que você não precise ficar vasculhando a aba de rede e pague por uso em vez disso. Pequeno, centrado em código e com vontade de controlar cada etapa? O Scrapy encaixa melhor. Vai escalar para centenas de sites e você não quer reproduzir manualmente uma requisição por site? O caminho gerenciado elimina essa categoria inteira de trabalho.

Para um panorama mais amplo, estes comparativos cobrem ferramentas próximas: a comparação completa de scrapers open source, a análise do crawler Go sem navegador, Colly e a análise do Scrapling com seletores adaptativos.

Veredito

Vale a pena usar o Scrapy? Sim — se você é desenvolvedor, quer controle e compra a filosofia: não renderize a página, encontre a requisição por trás dela. Nos testes, essa visão funcionou exatamente como prometido. Um catálogo em JavaScript entregou 0 cards ao fetcher HTTP; a API JSON que o alimentava entregou todos os 8 itens ao mesmo spider. A extração estática bateu 12/12, os seletores de artigo mantiveram 3/3 parágrafos livres de boilerplate, o grafo de crawl respeitou o limite de profundidade em 11 páginas e um 500 voltou como status tratado, não como falha.

Só dimensione as promessas corretamente. O Scrapy não renderiza JavaScript e não vai descobrir a API por você — esse reflexo precisa ser seu. A pilha de dependências é de um framework inteiro e pode causar problemas em plataformas fora do comum, embora aqui tenha rodado sem atrito. E como testei fixtures e páginas de demonstração, não um crawl de mil páginas, trate a história de escala como promissora, mas ainda não comprovada. Dentro desses limites, o Scrapy é a ferramenta que melhor abraça uma ideia discretamente radical: a forma mais rápida de atravessar uma página da web geralmente não passa pela página em si.

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

Perguntas frequentes

O Scrapy consegue raspar páginas renderizadas com JavaScript? Não com o fetcher HTTP padrão — ele retornou 0 nós tanto no fixture em JS quanto na página pública Quotes JS, porque baixa o HTML sem executar um navegador. O caminho pretendido é localizar a requisição de dados subjacente que a página faz e acessá-la diretamente; no meu teste, a API JSON por trás de um catálogo JS entregou todos os 8 itens. Para páginas sem requisição reproduzível, você precisa conectar um navegador headless por conta própria.

O que significa “reproduzir a requisição” na prática? A maioria das páginas dinâmicas carrega os dados a partir de uma API JSON em segundo plano e depois os renderiza no cliente. Em vez de abrir um navegador para assistir a isso acontecer, você abre a aba de rede, encontra essa chamada de API e aponta o Scrapy diretamente para ela. É mais rápido e mais estável do que renderizar — um contrato de API quebra menos que um DOM —, mas exige trabalho manual, e o Scrapy não localiza o endpoint por você.

O Scrapy é difícil de instalar? No meu caso foi tranquilo — pip install Scrapy==2.17.0 terminou sem erros de compilação em um venv novo no macOS usando wheels binários. Mas ele puxa uma pilha grande (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), e a documentação oficial ainda alerta para fricções específicas de plataforma em alguns sistemas. Então, se você estiver em um ambiente incomum, vale prever esse tempo extra.

Quais formatos de saída o Scrapy suporta? A exportação de feeds cobre JSON, JSON Lines, CSV e XML nativamente — basta apontar o spider para um arquivo e ele serializa os itens sem código adicional. No meu teste, um spider produziu JSON e CSV em uma única passada. Observe que ele exporta os campos que você selecionou; ele não transforma automaticamente a página em Markdown limpo.

O Scrapy é gratuito para uso comercial? Sim. A licença é BSD-3-Clause, que é permissiva e amigável ao uso comercial. Como sempre, confirme a licença atual no repositório antes de construir em cima dele e mantenha escolhas responsáveis de user-agent, proxy e limite de taxa — capacidade não é permissão.