Eu Testei o Colly em 17 Páginas Sem Navegador — e é Isso que “Raspador Go Rápido” Realmente Quer Dizer

Pesquise por “Colly” e o primeiro adjetivo que sempre aparece é o mesmo: rápido. Um crawler Go rápido, rápido porque compila, rápido porque não há navegador atrapalhando. Quase ninguém coloca um número nessa história.

Então eu parei de acreditar só na palavra. Montei um pequeno site de testes, compilei o Colly contra ele e observei o que a biblioteca realmente fazia — a taxa de recuperação em páginas reais, como tratava uma requisição com falha, até onde um crawl com profundidade limitada conseguia ir. A versão curta, antes dos números: a extração estática voltou com recuperação total, um erro 500 caiu exatamente onde deveria, e um crawl com limite de profundidade alcançou 17 páginas a partir de um único binário estático, sem navegador acoplado. A biblioteca também retornou zero de forma limpa em tudo o que era renderizado em JavaScript — justamente a parte que a conversa sobre “rápido” costuma ignorar.

O que o Colly é, de fato — e o que ele não é

Colly se apresenta como um “framework elegante de scraper e crawler para Golang”, e essa frase diz mais do que parece. Trata-se de uma biblioteca Go — com cerca de ~25,4 mil estrelas em 2026-07-09 em gocolly/colly, sob licença Apache-2.0. Não é uma ferramenta de linha de comando que você baixa e aponta para uma URL. Você escreve Go, importa o pacote, conecta alguns callbacks e compila tudo em um único executável.

O modelo mental é orientado a eventos, e isso confunde quem está acostumado com o fluxo de requisição e parsing. Você não percorre uma resposta e extrai campos linha por linha. Você registra handlers em um Collector e deixa a biblioteca dispará-los enquanto navega pelas páginas. OnHTML executa sua lógica de extração toda vez que um seletor CSS correspondente aparece. OnResponse entrega o corpo bruto da resposta, o que faz diferença quando o payload é JSON e não HTML. OnError captura as requisições que falham. O crawl funciona do mesmo jeito: dentro de um handler de links, você chama Visit() nas URLs encontradas, o Colly as coloca na fila, e MaxDepth define até onde ele pode ir. Callbacks, fila de visitas, limite de profundidade, binário estático compilado. Sem interpretador, sem runtime, sem Chrome headless ocupando memória.

O modelo de callbacks — e por que ele muda a sensação de extrair dados

Os callbacks são a personalidade inteira da ferramenta, então vale desacelerar aqui. Três deles participaram de todos os testes que rodei.

OnHTML(selector, handler) é o que você vai usar com mais frequência. Registre em .product ou article p, e o Colly chama seu handler uma vez para cada elemento correspondente enquanto faz o parse do DOM. É aqui que mora a extração estruturada, e ela fica natural de ler — você descreve o que quer, não o loop que vai buscar aquilo.

OnResponse(handler) atua um nível abaixo e entrega os bytes crus que chegam pela rede. Quando o alvo devolve JSON em vez de marcação HTML, você nem encosta no DOM — faz o unmarshal do corpo você mesmo. Esse único callback foi o motivo de o Colly ter lidado com uma API JSON no meu teste sem precisar parsear uma linha de HTML.

OnError(handler) é o callback que todo mundo esquece até o scraper cair às 3 da manhã. Ele dispara quando uma requisição falha e entrega a resposta para você, para que possa ler o status code e decidir o próximo passo. Um crawler que engole falhas em silêncio é pior do que um que quebra de forma evidente; o Colly não faz nenhum dos dois, e isso importa mais do que parece quando o trabalho roda sem supervisão.

Dois recursos adicionais ficam acima desses callbacks e fazem diferença na operação. MaxDepth limita o crawl, então um coletor que segue links para duas camadas para em vez de sair passeando pela web inteira. E o resultado da compilação é um único binário Go estático — compila uma vez, gera um arquivo sem dependências de runtime, joga em um servidor ou em um job de CI e roda. Se você já perdeu uma tarde com um virtualenv Python em uma máquina recém-montada, esse perfil de implantação parece um recurso, não um detalhe.

Configuração — a stack Go que ninguém comenta

A história das dependências é curta, mas tem um detalhe importante, então vou deixar isso claro antes de você instalar qualquer coisa. A máquina que usei não tinha Go instalado, e o Colly é uma biblioteca Go, então o passo zero foi colocar uma toolchain no sistema — instalei o Go 1.26.5 via Homebrew. Se sua equipe não vive em Go, esse é o atrito real. Não é a biblioteca. É o ambiente de linguagem que ela exige antes de a primeira linha compilar.

Com o Go pronto, puxar o Colly foi tranquilo. go get github.com/gocolly/colly/v2 resolveu para a versão v2.3.0 sem drama — nada de navegador, nada de headless, nada além do binário compilado no final. Compare isso com scrapers em Python que instalam um parser e depois quebram na primeira requisição por causa de extras faltando, e essa experiência foi quase entediante. E isso, aqui, é um elogio.

Uma observação precisa, dita de forma direta, porque isso vai confundir você se for fuçar. O módulo mais recente no Go proxy é v2.3.0, publicado em dezembro de 2025. A release mais nova marcada no GitHub é v2.2.0, de março de 2025. Ou seja, o código que testei — v2.3.0 — está à frente do que a página de Releases do repositório mostra. Isso é uma peculiaridade de como módulos Go e tags do GitHub podem se desencontrar ao longo do tempo, não sinal de problema. Só não estranhe quando o go get e a página de Releases mostrarem números diferentes.

Na prática — os números por trás de “rápido”

Rodei o Colly contra um servidor de testes autônomo construído com httptest do Go, além de dois sites públicos de demonstração, para que o comportamento fosse reproduzível e não apenas uma história bonita. Veja o que voltou.

Teste	Alvo	Resultado
Catálogo estático + paginação	ambiente local	12/12 produtos, recuperação 1.0
Extração de artigo	ambiente local	título + 3/3 parágrafos
API JSON dinâmica	ambiente local	8/8 itens via OnResponse, recuperação 1.0
Tratamento de HTTP 500	ambiente local	roteado para OnError, status 500
Grafo de crawl (MaxDepth 2)	ambiente local	17 páginas
Books to Scrape	demo pública	20 produtos
Página dinâmica (sem JS)	ambiente local	0 cards (esperado)
Quotes JS (sem renderização)	demo pública	0 (esperado)

Leia de cima para baixo e o quadro se mantém coeso. A extração estática foi limpa — 12 de 12 produtos do catálogo, todos os três parágrafos do artigo, tudo guiado por seletores OnHTML. O teste da API JSON nem abriu um parser HTML: OnResponse entregou o corpo, eu fiz o unmarshal, e 8 de 8 itens apareceram. O teste do 500 é o que eu mais valorizo, porque ele separa um crawler que você pode deixar rodando durante a noite de um que não serve para isso — o Colly enviou a falha para OnError e expôs o status corretamente, sem crash e sem sumiço silencioso. Na demo pública Books to Scrape, ele puxou 20 produtos sem nenhuma adaptação especial.

O resultado do crawl é o destaque, e quero dizer isso com cuidado. Um coletor com MaxDepth(2), seguindo links e resolvendo URLs absolutas, alcançou 17 páginas no meu grafo de testes. É aí que a frase “crawler Go rápido” finalmente ganha um número real de páginas, em vez de depender de impressão subjetiva. Mas repare na formulação — 17 páginas num crawl com profundidade 2. O número de profundidade aí é um contador do meu próprio harness de testes, descrevendo como eu configurei a execução; não estou afirmando que o Colly garante internamente “exatamente profundidade 2, nunca mais um link” como contrato. A afirmação honesta e verificável é esta: com profundidade limitada a 2, o crawl percorreu o grafo e chegou a 17 páginas.

Agora o limite, que é onde normalmente os posts sobre “é tão rápido” ficam em silêncio. O Colly não executa JavaScript. Apontei-o para um ambiente de teste renderizado via JavaScript e recebi 0 cards; apontei para a página pública Quotes to Scrape JS e recebi 0 de novo. Isso não é bug e não é crítica gratuita. O Colly é um crawler HTTP — ele baixa e analisa HTML, mas nunca abre um navegador para rodar scripts do lado do cliente. Assim como Scrapy e outros crawlers baseados em HTTP, se o conteúdo só existe depois da execução de JavaScript, o Colly vai devolver resultado vazio sempre, e nenhuma velocidade bruta muda isso. Combine com um renderer, ou escolha uma ferramenta que já traga isso embutido.

Também vou ser igualmente direto sobre o que eu não testei, para ninguém esticar meus resultados além das evidências. Não forcei o coletor assíncrono, nem a configuração de rate limiting e polidez, nem rotação de proxy, nem os backends de fila e armazenamento. Esses recursos existem no Colly. Eu testei o núcleo de extração e crawl, não a infraestrutura de escala. O README fala em throughput acima de mil requisições por segundo em um único core, mas esse é o número do próprio projeto — eu medi contagem de páginas e recall, não throughput, então quando digo “rápido” estou falando do caminho de extração compilado em Go que de fato cronometrei, não de um benchmark contra Scrapy que eu não rodei.

Prós e contras

Prós:

• Recuperação total na extração estática — 12/12 produtos do catálogo e 3/3 parágrafos do artigo via OnHTML.
• Tratamento limpo de JSON via OnResponse, sem necessidade de parsear DOM — 8/8 itens da API.
• Roteamento correto de falhas — um 500 caiu em OnError com o status exposto, sem crash.
• Um crawl com profundidade limitada alcançou 17 páginas a partir de um único coletor.
• Um único binário Go estático, sem dependências de runtime — excelente perfil de deploy e operação.
• Licença permissiva Apache-2.0.

Contras:

• Não executa JavaScript — conteúdo renderizado no cliente volta como 0, ponto final.
• Exige toolchain Go; equipes que ainda não usam Go pagam esse custo de setup antes de escrever qualquer scraper.
• O módulo mais recente (v2.3.0) está à frente da release mais nova marcada (v2.2.0), o que confunde quem olha a página de Releases.
• O resultado depende do seu próprio código — o Colly fornece callbacks, não um dataset pronto nem exportação de feed integrada como o Scrapy faz.
• Backends de async, rate limiting, proxy e fila existem, mas não foram testados aqui; o “rápido” é o caminho de extração que medi, não um número de throughput frente a frente.

Para quem o Colly é indicado — e quem deve passar longe

O Colly faz sentido se você já escreve Go e está coletando sites baseados em HTML ou JSON com velocidade. Se sua definição de deploy limpo é copiar um único binário para uma máquina e executá-lo — sem interpretador, sem virtualenv, sem loteria de dependências — a ferramenta foi feita exatamente para esse cenário. O modelo de callbacks mostra seu valor assim que a extração deixa de ser trivial: OnHTML para estrutura, OnResponse para payload bruto, OnError para falhas que você não veria de outro jeito. Para um alvo estático ou baseado em API, rodando em intervalo por CI, é uma escolha forte e sem drama.

Vale pular, ou pelo menos acoplar uma segunda ferramenta, quando os alvos dependem de JavaScript. O Colly devolveu 0 em todas as páginas renderizadas no cliente que eu testei, e isso é por design, não uma opção que você pode ativar. Também não vale se o seu time não usa Go e você não quer subir uma toolchain só para raspar alguns sites — o compromisso com a linguagem é real e a manutenção também. E, se você quer receber dados estruturados prontos em vez de gerá-los com código próprio, os callbacks do Colly jogam esse trabalho para o seu lado da cerca.

Alternativas — onde entra uma API de scraping com IA gerenciada

O Colly é uma biblioteca gratuita e open source que você compila e executa por conta própria. Você fica com o código Go, os callbacks, a lógica de crawl e a máquina onde tudo roda — e, em troca, não paga por requisição e mantém toda a operação dentro de casa. Para uma equipe Go, essa é uma resposta perfeitamente defensável, e o deploy em binário único é realmente agradável.

Os dois pontos em que ele para são justamente os dois que valem comparar com outra abordagem. Primeiro, JavaScript — o Colly não renderiza, então qualquer coisa do lado do cliente fica fora do alcance, a menos que você acople um navegador. Segundo, estrutura — o Colly entrega callbacks e deixa a montagem de uma saída limpa por sua conta. Uma API de scraping com IA gerenciada responde a essas duas questões de outra forma. O stack de desenvolvedor do Thunderbit lida com renderização de JS e devolve dados estruturados no lado do servidor. POST /distill transforma uma página em Markdown limpo, pronto para LLM, com conteúdo dinâmico e anti-bot tratados para você. POST /extract retorna JSON estruturado com base em um JSON Schema que você definir, com um renderMode que pode ser elevado até renderização completa em navegador quando a página exigir. Há um servidor MCP do Thunderbit para agentes de IA e assistentes de programação — thunderbit_suggest_fields é gratuito, então você pode sondar o que uma página expõe antes de se comprometer — e também um CLI que pode ser executado com npx @thunderbit/thunderbit-cli no terminal, em CI e em cron.

Experimente Thunderbit para Extração de Dados da Web

A troca não é entre melhor e pior. É sobre onde o trabalho acontece. Com o Colly, você mantém renderização (nenhuma), parsing e manutenção dentro do seu próprio binário compilado, com custo zero por chamada, e precisa cuidar dele quando um site muda de formato. Com uma API gerenciada, você terceiriza renderização de JS, anti-bot e saída estruturada, e paga por requisição por essa conveniência. Alvos pequenos, nativos de Go, baseados em HTML ou JSON, que você aceita manter e operar? O controle e a velocidade do Colly ganham sem discussão. Páginas cheias de JavaScript, ou simplesmente a preferência por receber JSON já estruturado em vez de escrever mais um callback? Esse é o caso da rota gerenciada. Se quiser um panorama mais amplo, os levantamentos de melhores ferramentas de web scraping e melhores projetos de web scraping no GitHub mostram onde uma biblioteca como o Colly se encaixa ao lado das opções baseadas em navegador e das soluções gerenciadas.

Veredito

Vale a pena usar o Colly? Sim — se você escreve Go e está coletando HTML ou JSON com velocidade, ele entrega o que a fama de “crawler rápido” promete, e agora há números por trás dessa fama. Recuperação total na extração estática. JSON limpo via OnResponse. Um 500 roteado corretamente para OnError em vez de desaparecer. Um crawl com profundidade 2 que chegou a 17 páginas. Tudo compilado em um único binário estático sem dependências de runtime, o que é provavelmente a história de deploy mais amigável dessa categoria inteira.

Mas é preciso dimensionar as promessas com honestidade. Ele não renderiza JavaScript — todas as páginas do lado do cliente no meu teste voltaram 0, e isso é permanente, não uma configuração esquecida. Ele exige toolchain Go, então equipes fora de Go pagam uma taxa de setup adiantada. O módulo que você instala (v2.3.0) está à frente da release mais nova marcada (v2.2.0), então não entre em pânico se as páginas discordarem. E “rápido”, aqui, significa o caminho de extração que medi, não um benchmark de throughput que eu não rodei. Dentro desses limites, o Colly é um crawler Go rápido, confiável e realmente implantável — e faz jus à reputação no momento em que você para de pedir que ele execute JavaScript.

Experimente Thunderbit para Extração de Dados da Web Get Started Free

FAQs

O Colly é realmente rápido? Existe um número por trás disso? Ele é rápido no sentido que importa para o caminho principal que medi: Go compilado, recuperação total na extração estática (12/12 produtos do catálogo), tratamento limpo de JSON e um crawl com profundidade 2 que chegou a 17 páginas — tudo a partir de um único binário estático. O que eu não rodei foi um benchmark de throughput contra o Scrapy, então trate “rápido” como comportamento de extração medido, não como um placar de velocidade frente a frente.

O Colly consegue raspar páginas renderizadas com JavaScript? Não. O Colly é um crawler HTTP — ele baixa e analisa HTML, mas nunca executa um navegador. Um ambiente de teste renderizado em JavaScript retornou 0 cards, e a página pública Quotes JS também retornou 0. Para conteúdo do lado do cliente, você vai precisar combinar o Colly com um renderer ou usar uma ferramenta que já traga renderização de navegador embutida.

Preciso saber Go para usar o Colly? Sim. O Colly é uma biblioteca Go, não uma CLI independente — você o importa, registra callbacks (OnHTML, OnResponse, OnError) e compila. A máquina que usei não tinha Go instalado, então a configuração começou com a instalação da toolchain (1.26.5). Se sua equipe ainda não trabalha com Go, esse ambiente é o custo real de setup.

Por que a versão que eu instalo não bate com a release mais recente do Colly no GitHub? Porque o módulo do Go e a tag de release do GitHub se desencontraram. O módulo mais recente no Go proxy é v2.3.0 (dezembro de 2025), enquanto a release mais nova marcada no GitHub é v2.2.0 (março de 2025). Eu testei v2.3.0. É uma particularidade entre módulos e tags, não uma instalação quebrada.

O Colly é gratuito para uso comercial? Sim, ele é Apache-2.0, o que é permissivo e amigável para uso comercial. Como sempre, confirme a licença atual no repositório antes de construir em cima dele.