Cerca “Colly” e il primo aggettivo è sempre quello: veloce. Un crawler Go rapido, veloce perché si compila, veloce perché non passa da un browser. Però quasi nessuno accompagna questa definizione con un numero.
Così ho smesso di fidarmi solo delle parole. Ho preparato un piccolo sito di test, ho compilato Colly contro quel target e ho guardato cosa facesse davvero la libreria — il tasso di recupero sulle pagine reali, come gestiva una richiesta fallita, fin dove arrivava una scansione con profondità limitata. In breve, prima dei numeri: l’estrazione statica ha restituito un recupero completo, un errore 500 è finito esattamente dove doveva finire e una scansione con limite di profondità ha raggiunto 17 pagine partendo da un unico binario statico senza browser collegato. La libreria ha anche restituito uno zero pulito su tutto ciò che era renderizzato in JavaScript — che, guarda caso, è proprio la parte che il coro del “veloce” tende a saltare.
Cos’è davvero Colly — e cosa non è
Colly si presenta come un “elegant scraper and crawler framework for Golang”, e questa singola frase conta più di quanto sembri. Si tratta di una libreria Go — circa ~25,4k stelle al 2026-07-09 su gocolly/colly, con licenza Apache-2.0. Non è uno strumento da riga di comando da scaricare e puntare a un URL. Scrivi codice Go, importi il pacchetto, colleghi una manciata di callback e compili il risultato in un unico eseguibile.
Il modello mentale è event-driven, e questo spiazza chi arriva dal classico flusso richiesta-analisi. Non scorri una risposta riga per riga per estrarne i campi. Colleghi degli handler a un Collector e lasci che sia la libreria a chiamarli mentre attraversa le pagine. OnHTML esegue il codice di estrazione ogni volta che compare un selettore CSS corrispondente. OnResponse ti passa il corpo grezzo della risposta, cosa fondamentale quando il payload è JSON e non HTML. OnError intercetta le richieste andate male. Anche il crawling funziona allo stesso modo: dentro un handler dei link, chiami Visit() sugli URL trovati, Colly li mette in coda e MaxDepth decide fin dove può arrivare la scansione. Callback, coda di visite, limite di profondità, binario statico compilato. Nessun interprete, nessun runtime, nessun Chrome headless in memoria.
Il modello a callback, e perché cambia il modo in cui percepisci l’estrazione
Le callback sono l’anima del tool, quindi vale la pena soffermarsi un attimo. Tre di esse hanno retto tutti i test che ho eseguito.
OnHTML(selector, handler) è quella che userai più spesso. La registri su .product o article p, e Colly richiama il tuo handler una volta per ogni elemento corrispondente mentre analizza il DOM. Qui vive l’estrazione strutturata, e il flusso è molto leggibile: descrivi ciò che vuoi, non il ciclo con cui ottenerlo.
OnResponse(handler) sta un livello più in basso e ti consegna i byte grezzi ricevuti sulla rete. Quando il target restituisce JSON invece di markup, non tocchi mai il DOM — deserializzi tu stesso il corpo. Questa singola callback è il motivo per cui Colly, nella mia prova, ha gestito una API JSON senza dover interpretare neppure una riga di HTML.
OnError(handler) è la callback che tutti dimenticano fino a quando uno scraper si rompe alle 3 di notte. Si attiva quando una richiesta fallisce e ti passa la risposta, così puoi leggere lo status code e decidere cosa fare dopo. Un crawler che ingoia silenziosamente gli errori è peggiore di uno che va in errore in modo evidente; Colly non fa né l’uno né l’altro, e la differenza è più importante di quanto sembri quando il job gira senza supervisione.
Sopra queste callback ci sono altre due caratteristiche che contano sul piano operativo. MaxDepth limita la profondità della scansione, così un collector che segue i link si ferma a due passaggi invece di girare per il web aperto. E l’output della build è un singolo binario Go statico — compili una volta, ottieni un file senza dipendenze runtime, lo distribuisci su un server o in un job CI e lo esegui. Se ti è mai capitato di perdere un pomeriggio dietro a un virtualenv Python su una macchina appena configurata, questo profilo di deploy non è un dettaglio: è un vantaggio concreto.
Setup — la toolchain Go di cui nessuno parla
La storia delle dipendenze è breve, ma c’è un vero punto critico, quindi meglio dirlo subito prima di installare qualsiasi cosa. La macchina su cui ho testato non aveva Go installato, e Colly è una libreria Go; quindi il primo passo è stato aggiungere la toolchain al sistema — ho installato Go 1.26.5 tramite Homebrew. Se il tuo team non vive già in Go, questa è la vera frizione. Non la libreria. L’ambiente linguistico che serve prima ancora che una sola riga possa compilarsi.
Con Go installato, recuperare Colly è stato semplice. go get github.com/gocolly/colly/v2 ha risolto la versione v2.3.0 senza problemi — niente browser, niente headless, niente oltre il binario compilato alla fine. Se lo confronti con gli scraper Python che installano un parser e poi vanno in crisi alla prima richiesta perché manca qualche extra, qui è stato tutto piacevolmente noioso. E noioso, in questo caso, è un complimento.
Una nota di precisione, detta senza giri di parole, perché se vai a cercare ti confonderà di sicuro. L’ultima versione del modulo sul Go proxy è v2.3.0, pubblicata a dicembre 2025. L’ultimo release tag su GitHub è v2.2.0, datato marzo 2025. Quindi il codice che ho testato — v2.3.0 — è più avanti rispetto a quanto mostrato nella pagina Releases del repository. È una particolarità del modo in cui i moduli Go e i tag GitHub si allontanano nel tempo, non il segnale che qualcosa non vada. Basta non stupirsi se go get e la pagina Releases danno numeri diversi.
Prova pratica — i numeri dietro il “veloce”
Ho eseguito Colly contro un server di test autosufficiente costruito con httptest di Go, più due demo site pubblici, così il comportamento è riproducibile e non è solo un racconto. Ecco cosa è emerso.
| Test | Target | Risultato |
|---|---|---|
| Catalogo statico + paginazione | fixture locale | 12/12 prodotti, recall 1.0 |
| Estrazione articolo | fixture locale | titolo + 3/3 paragrafi |
| API JSON dinamica | fixture locale | 8/8 elementi tramite OnResponse, recall 1.0 |
| Gestione HTTP 500 | fixture locale | instradato su OnError, status 500 |
Grafo di crawling (MaxDepth 2) | fixture locale | 17 pagine |
| Books to Scrape | demo pubblica | 20 prodotti |
| Pagina dinamica (senza JS) | fixture locale | 0 card (atteso) |
| Quotes JS (senza rendering) | demo pubblica | 0 (atteso) |
Leggi la tabella dall’alto verso il basso e il quadro regge. L’estrazione statica è stata pulita — 12 prodotti su 12 dal catalogo, tutti e tre i paragrafi dall’articolo, tutto guidato da selettori OnHTML. Il test sull’API JSON non ha mai aperto un parser HTML: OnResponse ha passato il corpo, l’ho deserializzato e 8 elementi su 8 sono tornati correttamente. Il test sul 500 è quello su cui mi appoggio di più, perché è la linea di confine tra un crawler che puoi lasciare girare tutta la notte e uno di cui non ti puoi fidare: Colly ha instradato il fallimento verso OnError e ha esposto lo status in modo pulito, senza crash e senza nascondere l’errore. Sulla demo pubblica Books to Scrape ha estratto 20 prodotti senza bisogno di trattamenti speciali.
Il risultato della scansione è il dato più interessante, e voglio dirlo con precisione. Un collector con MaxDepth(2), che segue i link e li risolve in URL assoluti, ha raggiunto 17 pagine nel mio grafo di test. È la frase che finalmente mette un numero reale dietro l’etichetta “crawler Go veloce”, invece di lasciare tutto a una sensazione. Però attenzione a come va letta: 17 pagine all’interno di una scansione con profondità 2. Quel numero di profondità è il contatore del mio harness di test, cioè il modo in cui ho configurato l’esecuzione; non sto dicendo che Colly garantisca internamente “esattamente profondità 2 e non un link oltre” come contratto. L’affermazione corretta e verificabile è questa: con la profondità limitata a 2, la scansione ha attraversato il grafo e raggiunto 17 pagine.
Adesso il limite, cioè il punto in cui i post sul “quanto è veloce” di solito diventano muti. Colly non esegue JavaScript. L’ho puntato su una fixture renderizzata in JavaScript e ho ottenuto 0 card; l’ho puntato sulla pagina pubblica Quotes to Scrape JS e ho ottenuto di nuovo 0. Non è un bug e non è una critica. Colly è un crawler HTTP — scarica e analizza HTML, ma non avvia mai un browser per eseguire script lato client. Come Scrapy e gli altri crawler HTTP-first, se il contenuto che cerchi esiste solo dopo l’esecuzione di JavaScript, Colly ti restituisce sempre un risultato vuoto, e nessuna velocità pura cambia questo limite. Devi affiancarlo a un renderer, oppure scegliere uno strumento che lo includa già.
Sarò altrettanto chiaro su ciò che non ho testato, così nessuno allarghi i miei risultati oltre l’evidenza. Non ho spinto il collector asincrono, la configurazione di rate limiting e politeness, la rotazione dei proxy o i backend di coda e storage. Esistono in Colly. Io ho testato il nucleo estrazione+crawling, non l’infrastruttura per scalare. Il README dichiara una produttività superiore a mille richieste al secondo su un singolo core, ma quello è un dato del progetto; io ho misurato conteggi di pagine e recall, non throughput, quindi quando dico “veloce” intendo il percorso di estrazione compilato in Go che ho effettivamente osservato, non un benchmark contro Scrapy che non ho eseguito.
Pro e contro
Pro:
- Recall completo nell’estrazione statica — 12/12 prodotti del catalogo e 3/3 paragrafi dell’articolo tramite
OnHTML. - Gestione pulita del JSON tramite
OnResponse, senza bisogno di parsare il DOM — 8/8 elementi dell’API. - Instradamento corretto dei fallimenti — un 500 è finito in
OnErrorcon lo status esposto, senza crash. - Una scansione con profondità limitata ha raggiunto 17 pagine partendo da un solo collector.
- Un unico binario Go statico, zero dipendenze runtime — profilo ottimo per deploy e operatività.
- Licenza permissiva Apache-2.0.
Contro:
- Nessuna esecuzione JavaScript — il contenuto renderizzato lato client torna a 0, senza eccezioni.
- Richiede una toolchain Go; i team che non lavorano già in Go devono sostenere questo costo di setup prima ancora di scrivere uno scraper.
- L’ultima versione del modulo (
v2.3.0) è più avanti rispetto all’ultimo release tag (v2.2.0), e questo confonde chi guarda la pagina Releases. - L’output è codice tuo — Colly fornisce callback, non un dataset integrato o un esportatore di feed come fa Scrapy.
- I backend asincroni, di rate limiting, proxy e coda esistono ma qui non sono stati testati; il “veloce” è il percorso di estrazione che ho misurato, non un numero di throughput diretto.
Per chi è Colly — e chi dovrebbe evitarlo
Colly è adatto se scrivi già in Go e devi fare crawling di siti basati su HTML o JSON a buon ritmo. Se per te un deploy pulito significa copiare un solo binario su una macchina e avviarlo — niente interprete, niente virtualenv, niente roulette delle dipendenze — questo strumento è stato pensato esattamente per quel tipo di scenario. Il modello a callback dimostra il suo valore non appena l’estrazione smette di essere banale: OnHTML per la struttura, OnResponse per i payload grezzi, OnError per i fallimenti che altrimenti non vedresti mai. Per un target statico o API-backed che esegui in schedulazione da CI, è una scelta solida e senza troppi drammi.
Evitalo, o almeno affiancalo a un secondo strumento, quando i target dipendono da JavaScript. Colly ha restituito 0 su ogni pagina renderizzata lato client che gli ho sottoposto, e questo per design, non è un’impostazione che puoi attivare o disattivare. Evitalo anche se il tuo team non usa Go e non vuoi mettere in piedi una toolchain solo per estrarre dati da pochi siti — l’impegno verso il linguaggio è reale e va mantenuto. E se vuoi dati strutturati già pronti invece di doverli ricavare tu nel codice, le callback di Colly mettono quel lavoro interamente dalla tua parte della barricata.
Alternative — dove si colloca un’API di scraping AI gestita
Colly è una libreria open source gratuita che compili e gestisci in autonomia. Ti prendi in carico il codice Go, le callback, la logica di crawling e la macchina su cui gira — e in cambio non paghi nulla per richiesta e tieni l’intera operazione in casa. Per un’azienda già orientata a Go, è una risposta perfettamente difendibile, e il deploy in un solo binario è davvero piacevole.
I due punti in cui si ferma sono esattamente quelli da confrontare con qualcos’altro. Primo, JavaScript — Colly non lo renderizza, quindi tutto ciò che è lato client resta fuori, a meno che tu non aggiunga un browser. Secondo, la struttura — Colly ti dà callback e lascia al tuo codice il compito di produrre un output pulito. Un’API di scraping AI gestita risponde a entrambe le esigenze in modo diverso. Lo stack per sviluppatori di Thunderbit gestisce il rendering JS e restituisce dati strutturati lato server. POST /distill trasforma una pagina in Markdown pulito, pronto per LLM, con contenuti dinamici e anti-bot gestiti per te. POST /extract restituisce JSON strutturato in base a uno JSON Schema che definisci tu, con un renderMode che puoi portare fino al rendering completo nel browser quando una pagina lo richiede. Esiste anche un server Thunderbit MCP per agenti AI e assistenti di programmazione — thunderbit_suggest_fields è gratuito, così puoi capire cosa espone una pagina prima di impegnarti — e una CLI che puoi avviare con npx @thunderbit/thunderbit-cli per terminale, CI e cron.
Prova Thunderbit per l’estrazione di dati web
Il compromesso non è migliore contro peggiore. È dove vive il lavoro. Con Colly tieni rendering (nessuno), parsing e manutenzione dentro il tuo binario compilato, a costo zero per chiamata, e ti occupi tu di tutto quando un sito cambia forma. Con un’API gestita deleghi rendering JS, anti-bot e output strutturato, e paghi per chiamata per questo privilegio. Target piccoli, nativi Go, basati su HTML o JSON, che sei felice di possedere e mantenere? In quel caso, il controllo e la velocità di Colly vincono senza discussione. Pagine pesanti di JavaScript, oppure vuoi semplicemente ricevere JSON già conforme a uno schema senza scrivere un’altra callback? Allora ha senso la strada gestita. Se vuoi una visione più ampia del panorama, le raccolte sui migliori strumenti di web scraping e sui migliori progetti GitHub per il web scraping mostrano dove si colloca una libreria come Colly rispetto alle opzioni browser-based e gestite.
Verdetto
Conviene usare Colly? Sì — se scrivi in Go e devi fare crawling di HTML o JSON ad alta velocità, fa davvero ciò che la reputazione di “crawler veloce” promette, e ora ci sono dei numeri a sostenerla. Recall completo nell’estrazione statica. JSON gestito correttamente tramite OnResponse. Un 500 instradato su OnError invece di sparire. Una scansione a profondità 2 che ha raggiunto 17 pagine. Il tutto compilato in un unico binario statico senza dipendenze runtime, che in questa categoria è probabilmente la storia di deploy più semplice che tu possa desiderare.
Ma va calibrato con onestà. Non renderizza JavaScript — ogni pagina lato client nella mia prova ha restituito 0, e questo è un limite permanente, non un’impostazione che hai dimenticato. Richiede una toolchain Go, quindi i team non-Go pagano un costo di setup iniziale. La versione che installi (v2.3.0) è più avanti rispetto all’ultimo release tag (v2.2.0), quindi non andare in panico se le pagine non coincidono. E il “veloce” qui indica il percorso di estrazione che ho misurato, non un benchmark di throughput che non ho eseguito. Dentro questi confini, Colly è un crawler Go veloce, affidabile e davvero distribuibile — e mantiene la promessa non appena smetti di chiedergli di eseguire JavaScript.
Prova Thunderbit per l’estrazione di dati web Get Started Free
FAQ
Colly è davvero veloce, e c’è un numero a dimostrarlo? È veloce nel senso che conta per il percorso principale che ho misurato: Go compilato, recall completo nell’estrazione statica (12/12 prodotti del catalogo), gestione pulita del JSON e una scansione a profondità 2 che ha raggiunto 17 pagine — tutto da un unico binario statico. Quello che non ho eseguito è un benchmark di throughput contro Scrapy, quindi considera “veloce” come un comportamento di estrazione misurato, non come un punteggio di velocità in un confronto diretto.
Colly può estrarre pagine renderizzate in JavaScript? No. Colly è un crawler HTTP — scarica e analizza HTML ma non avvia mai un browser. Una fixture renderizzata in JavaScript ha restituito 0 card, e anche la pagina pubblica Quotes JS ha restituito 0. Per contenuti lato client devi affiancare Colly a un renderer o usare uno strumento che includa già il rendering del browser.
Devo conoscere Go per usare Colly?
Sì. Colly è una libreria Go, non un CLI autonomo — la importi, registri le callback (OnHTML, OnResponse, OnError) e compili. La macchina su cui ho testato non aveva Go installato, quindi il setup è iniziato con l’installazione di una toolchain (1.26.5). Se il tuo team non lavora già in Go, questo ambiente è il vero costo di avvio.
Perché la versione che installo non coincide con l’ultimo rilascio GitHub di Colly?
Perché il modulo Go e il tag di release GitHub si sono allontanati nel tempo. L’ultima versione del modulo sul Go proxy è v2.3.0 (dicembre 2025), mentre l’ultimo tag rilasciato su GitHub è v2.2.0 (marzo 2025). Io ho testato v2.3.0. È una particolarità tra moduli e tag, non un’installazione rotta.
Colly è gratuito per uso commerciale? Sì, è Apache-2.0, quindi permissivo e adatto all’uso commerciale. Come sempre, verifica la licenza corrente nel repository prima di costruirci sopra qualcosa.
