Análise do Colly: O scraper e crawler em Go valem a pena em 2025?

Construí um site de teste para validar aquilo que uma página de resultados ou um teste de velocidade do Colly não responde: se os callbacks extraem os registros esperados, se um erro HTTP é encaminhado corretamente, se ele percorre um grafo com limites definidos e se consegue acessar conteúdo entregue fora do HTML renderizado. Esta análise focou em correção e limites, não em benchmark de desempenho.

Nos fixtures controlados, ele extraiu todos os registros estáticos esperados, encaminhou uma resposta 500 para OnError e visitou 17 URLs no grafo configurado com limite de profundidade. Também retornou zero elementos de destino em duas páginas cujos elementos só apareciam depois da execução de JavaScript. Um endpoint JSON acessível diretamente continuou utilizável sem navegador, uma diferença importante em relação à renderização da interface no cliente.

O que o Colly realmente é

Colly se descreve como um "framework elegante de scraping e crawling para Golang", e essa definição faz mais trabalho do que parece. Ele é uma biblioteca Go — com cerca de 25.300 estrelas no GitHub e 1.850 forks — licenciada sob Apache-2.0. Não é uma CLI que você baixa e aponta para uma URL. Você escreve em Go, importa o Colly, registra alguns callbacks e compila tudo em um único executável.

O modelo mental é orientado a eventos. Você anexa handlers a um Collector: OnHTML executa a lógica de extração para seletores CSS correspondentes, OnResponse fornece o corpo bruto da resposta e OnError trata falhas de requisição. Os handlers de links chamam Visit() nas URLs descobertas, enquanto MaxDepth limita a navegação. Para esses caminhos apenas via HTTP, o host de destino não precisa de runtime Go separado nem de navegador; se o executável final será totalmente estático depende das flags de build e do uso de CGO, o que este teste não registrou.

Principais recursos e como funcionam por baixo dos panos

O modelo de callbacks é o ponto central aqui, porque é isso que faz o Colly parecer diferente de um script de request e parse. Três callbacks cobriram todos os testes que executei.

OnHTML(selector, handler) é o carro-chefe. Registre-o em .product ou article p e o Colly chama seu handler uma vez para cada elemento correspondente enquanto analisa o DOM. É aqui que vive a extração estruturada, e a leitura fica limpa — você descreve o que quer capturar, em vez de escrever um loop de parsing.

OnResponse(handler) fica um nível abaixo e entrega os bytes brutos. Quando o alvo retorna JSON em vez de HTML, você ignora o DOM por completo e faz o unmarshal do corpo manualmente. Esse único callback é o motivo de o Colly ter tratado uma API JSON com elegância nos meus testes, sem qualquer parsing de HTML.

OnError(handler) trata falhas de requisição e pode expor o status da resposta para o código chamador. Neste teste, uma resposta fixture com status 500 chegou ao callback registrado. Retries, timeouts, falhas de DNS, resets de conexão, panics em callbacks, persistência e alertas não foram testados.

Além dos callbacks, há dois recursos operacionais. MaxDepth limita a navegação de links de acordo com a semântica de profundidade do Colly. Um executável Go compilado também evita a necessidade de runtime da linguagem instalado separadamente no host de destino. Esta execução não registrou flags de build nem status de CGO, então não afirma que todo binário resultante seja totalmente estático.

Configuração: o toolchain Go necessário

A história da dependência é curta, mas real — então vale contar antes de instalar qualquer coisa. A máquina em que testei não tinha Go instalado, e o Colly é uma biblioteca Go — portanto, o passo zero foi colocar um toolchain Go na máquina (instalei Go 1.26.5 via Homebrew). Se sua equipe não vive em Go, essa é a fricção: não o Colly em si, mas o ambiente de linguagem que ele exige antes de compilar a primeira linha.

Com o Go instalado, go get github.com/gocolly/colly/v2 resolveu para a versão v2.3.0. Os caminhos testados não exigiram navegador nem Chrome headless.

Há uma diferença de versão que pode confundir o leitor. O módulo Go resolveu para v2.3.0 (publicado em dezembro de 2025), enquanto a entrada mais recente visível na interface de Releases do GitHub era v2.2.0 (março de 2025) no momento da consulta. A distinção é entre versão de módulo/repositório e entrada de Release no GitHub, não entre módulo e tag do Git. Testei v2.3.0.

Na prática: extração e limites operacionais

Executei o Colly contra um servidor fixture autônomo (httptest do Go) e também em dois sites públicos de demonstração. O atual diretório de benchmark e o arquivo results/colly-test-summary.json expõem os artefatos, mas ambos os links seguem uma branch mutável. O artigo não informa commit testado, comando exato, flags de build nem seed do fixture, então isso ainda não é uma receita imutável de reprodução.

Nos fixtures estáticos controlados, os seletores configurados produziram 12 de 12 registros de produto esperados e todos os três parágrafos esperados do artigo. A resposta JSON direta nunca passou por um parser de HTML: OnResponse forneceu o corpo e o harness decodificou todos os oito itens esperados. O único fixture com 500 chegou ao OnError com o status exposto e não derrubou essa execução; isso não comprova confiabilidade sem intervenção humana. Na página pública Books to Scrape, o seletor retornou 20 produtos como um teste rápido em site público.

Para a travessia, o collector foi configurado com MaxDepth(2) usando a convenção de seed-depth do harness e visitou 17 URLs no grafo de fixtures. O resultado é cobertura de crawl, não velocidade. O trace observado — e não uma afirmação mais ampla sobre grafos arbitrários — está em results/local_crawl_graph.json.

O Colly não executa JavaScript. O fixture com renderização via JavaScript produziu 0 cards de destino, e a página pública Quotes to Scrape JS também produziu 0 citações de destino. Se os elementos só existem após a execução no navegador e nenhum endpoint de apoio acessível os fornece, o caminho apenas via HTTP não consegue enxergar esses elementos como DOM renderizado. Use um renderer em conjunto ou acesse diretamente o endpoint de apoio quando houver um disponível, como o fixture JSON demonstra.

Não testei o collector assíncrono, configuração de rate limiting ou politeness, rotação de proxies, retries, nem backends de fila e armazenamento. Não medi tempo total, throughput, concorrência, CPU, memória, latência do alvo ou baseline comparativo. Portanto, este artigo não faz nenhuma afirmação de velocidade nem de confiabilidade sem intervenção.

Como interpretar os resultados dos fixtures

Os três caminhos de conteúdo bem-sucedidos exercitam contratos diferentes. Os casos de catálogo e artigo testam seleção CSS sobre HTML retornado pelo servidor. Seus denominadores são as expectativas do fixture definidas antes da extração: doze registros de produto e três parágrafos de artigo. Descrever isso como “registros esperados extraídos” é intencional. A execução não define matching fuzzy, tratamento de duplicatas, tolerância a campos parciais nem uma métrica de recall em todo o corpus, então o resultado não deve ser promovido a uma precisão geral de extração.

O caso JSON ignora a seleção de DOM. O Colly recebe os bytes da resposta por meio de OnResponse, e o harness faz a decodificação JSON. É por isso que “o Colly não renderiza JavaScript” não significa que todo site com frontend seja inacessível. Se a fonte de dados usada pelo cliente for um endpoint chamável diretamente e a requisição puder ser reproduzida fora do navegador, o crawler HTTP ainda pode ser suficiente. Autenticação, assinaturas geradas, estado exclusivo do navegador e controles anti-bot podem mudar essa resposta; nada disso foi exercitado aqui.

O roteamento do 500 testa despacho, não recuperação. Ele mostra que o callback OnError registrado recebeu essa resposta de fixture e seu status. Um crawler de produção ainda precisa de uma política explícita para códigos passíveis de retry, backoff, falhas terminais, persistência e alertas. O teste não fornece evidência para essas escolhas, e “o callback disparou” não deve ser lido como “o job pode ser confiável sem supervisão”.

O grafo de 17 URLs é igualmente restrito. Ele confirma o conjunto visitado produzido por este fixture, esta convenção de seed e MaxDepth(2). Não comprova páginas por segundo, justiça entre hosts, crescimento de memória nem comportamento em ciclos e formas duplicadas de URL. Isso exige testes separados de carga e de fila.

Uma checklist de seleção baseada neste teste

Comece olhando para a resposta que o Colly realmente recebe. Se os campos necessários estiverem no HTML retornado pelo servidor, use OnHTML e valide contagens de campos ou chaves obrigatórias antes de aceitar um registro. Se a resposta for JSON, trate o corpo por meio de OnResponse e valide o schema. Se o HTML for apenas uma casca da aplicação, verifique se uma requisição de apoio acessível contém os dados antes de adicionar um navegador.

Quando a execução no navegador for necessária, trate-a como outro componente, em vez de esperar que uma flag do Colly habilite renderização. O navegador precisa estabelecer prontidão, expor o conteúdo renderizado ou as respostas de apoio e passar os dados para o restante do pipeline. Esta revisão não testou essa integração.

Para implantação, registre a versão do Go, a versão do módulo, as flags de build, o status de CGO, o comando exato, a seed do fixture e o commit do repositório. Esses detalhes não aparecem nos links de publicação atuais e são a diferença entre artefatos inspecionáveis e uma reprodução durável. Em operações, adicione uma matriz de falhas e meça a carga que realmente importa antes de chamar o sistema de rápido ou confiável.

Prós e contras

Prós:

• Extraiu 12/12 produtos esperados do catálogo e 3/3 parágrafos esperados do artigo via OnHTML.
• Tratamento limpo de JSON por meio de OnResponse, sem necessidade de parsing do DOM — 8/8 itens da API.
• A resposta 500 testada chegou ao OnError com o status exposto.
• O crawl com profundidade limitada alcançou 17 páginas a partir de um único collector.
• Compila em um executável Go; o alvo não precisa de runtime Go instalado separadamente para os caminhos testados.
• Licença Apache-2.0 permissiva.

Contras:

• Sem execução de JavaScript — conteúdo renderizado no cliente retorna 0, sem exceção.
• Exige um toolchain Go; equipes fora do ecossistema Go pagam esse custo de configuração antes de escrever qualquer scraper.
• O módulo testado (v2.3.0) está à frente da entrada mais recente de GitHub Release observada (v2.2.0).
• O output é seu próprio código — o Colly fornece callbacks, não um dataset/feed exporter integrado como o Scrapy.
• Backends assíncronos, de rate limiting, proxy e fila existem, mas não foram testados aqui; throughput e escala continuam sem medição.

Para quem ele serve — e quem deve passar

O Colly faz sentido se você já escreve em Go e mira HTML renderizado pelo servidor ou JSON acessível diretamente. O modelo de callbacks separa correspondências estruturadas, payloads brutos e falhas de requisição. Um executável compilado também evita a necessidade de um ambiente de linguagem instalado separadamente na máquina de destino, embora o linking totalmente estático não tenha sido verificado aqui.

Adicione um renderer quando os elementos alvo só aparecerem após a execução no navegador e não existir um endpoint de apoio utilizável. Um endpoint JSON direto ainda pode ser solicitado sem renderização. O Colly também é uma opção menos adequada para equipes que não querem um toolchain Go ou que preferem que um serviço de extração cuide da modelagem de schema e da manutenção de seletores.

Alternativas, incluindo onde o Thunderbit se encaixa

O Colly é um software open-source que você executa por conta própria. Não há taxa de uso de fornecedor, mas computação, banda, proxies, armazenamento, observabilidade e engenharia continuam sendo seus custos. Você é dono do comportamento de requisição, dos callbacks de parsing, da lógica de crawl e da integração com navegador caso o alvo precise de renderização.

Um serviço gerenciado de extração transfere parte dessas responsabilidades para um fornecedor. Nós desenvolvemos o Thunderbit, mas não o testamos contra estes fixtures, então este artigo não faz comparação de renderização, anti-bot, qualidade, latência ou custo. A diferença relevante é a propriedade: o Colly expõe respostas HTTP e callbacks no seu processo Go; um serviço gerenciado pode assumir aquisição e modelagem de schema por uma taxa por chamada.

Leituras relacionadas de benchmark: a comparação completa de scrapers open-source, a análise do crawler Python Scrapy e a análise do seletor adaptativo Scrapling.

Experimente o Thunderbit para Extração de Dados da Web

Veredito

O Colly é um forte candidato para equipes em Go que miram HTML renderizado pelo servidor ou JSON direto e estão dispostas a assumir seu próprio código de extração. Os fixtures suportam extração de registros esperados, um trace de crawl com limites definidos e um callback 500 observado — não velocidade, escala nem confiabilidade sem supervisão. DOM renderizado no navegador exige outro caminho, a menos que o endpoint de dados subjacente possa ser acessado diretamente.

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

Perguntas frequentes

Esta análise mediu a velocidade do Colly? Não. Ela mediu extração de registros esperados, tratamento direto de JSON, um callback de erro e a cobertura de um grafo de crawl de fixtures. Não mediu tempo decorrido, throughput, concorrência, CPU, memória nem baseline comparativo.

O Colly consegue fazer scraping de páginas renderizadas com JavaScript? O Colly não executa o JavaScript da página. O caminho HTTP testado, portanto, não encontrou elementos de destino que só apareciam no DOM renderizado. Ele ainda pode solicitar diretamente um endpoint JSON de apoio acessível, como mostra o fixture JSON. Use um renderer quando a execução for necessária e não houver uma requisição de apoio reproduzível que forneça os dados.

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

Por que a versão que instalei não bate com o último release do Colly no GitHub? O módulo Go resolveu para v2.3.0 (dezembro de 2025), enquanto a entrada mais recente de GitHub Release observada era v2.2.0 (março de 2025). Testei v2.3.0; isso é uma distinção entre superfícies de versão, não evidência de instalação quebrada.

O Colly é gratuito para uso comercial? Ele usa Apache-2.0, uma licença permissiva e amigável para uso comercial. Como sempre, confirme a licença atual no repositório antes de construir em cima dele.

Antes da adoção em produção, adicione testes que correspondam ao risco operacional, em vez de estender por analogia o resultado dos fixtures. Meça crawls repetidos em alvos representativos, registre CPU e pico de memória, exercite falhas passíveis de retry e terminais, e verifique a politeness sob concorrência. Se persistência importar, interrompa e retome um crawl observando duplicatas e estado da fila. Se simplicidade de implantação importar, registre a configuração exata do compilador e linker e inspecione as dependências de runtime do executável gerado. Nada disso muda o que o fixture atual comprovou; isso apenas determina se a mesma configuração da biblioteca serve para um job de produção específico.