Zoek op "Colly" en het eerste bijvoeglijk naamwoord is bijna altijd hetzelfde: snel. Snelle Go-crawler, snel omdat het compileert, snel omdat er geen browser in de weg zit. Bijna niemand plakt er een getal op.
Dus nam ik dat niet langer zomaar aan. Ik zette een kleine testsite op, compileerde Colly daartegen en keek wat de library in de praktijk deed — de recall op echte pagina's, hoe een mislukte request werd afgehandeld, hoe ver een crawl met dieptelimiet afweek. De korte versie, nog vóór de cijfers: statische extractie haalde een volledige recall, een 500 kwam precies terecht waar die hoorde, en een crawl met dieptelimiet bereikte 17 pagina's vanuit één statische binary zonder browser eraan gekoppeld. De library gaf ook keurig nul terug op alles wat met JavaScript werd gerenderd — en dat is precies het deel dat in de "snel"-hype vaak wordt overgeslagen.
Wat Colly eigenlijk is (en niet is)
Colly noemt zichzelf een "elegant scraper and crawler framework for Golang", en die ene regel zegt meer dan je op het eerste gezicht denkt. Dit is een Go-library — ongeveer ~25,4k sterren per 2026-07-09 op gocolly/colly, met een Apache-2.0-licentie. Het is geen command-line tool die je downloadt en op een URL loslaat. Je schrijft Go-code, importeert het pakket, koppelt een paar callbacks en compileert het geheel tot één uitvoerbaar bestand.
Het mentale model is event-driven, en daar lopen mensen uit de request-and-parse-wereld vaak op vast. Je loopt niet simpelweg door een response heen om er regel voor regel velden uit te halen. Je hangt handlers aan een Collector en laat de library die afvuren terwijl hij pagina's afgaat. OnHTML voert je extractiecode uit telkens wanneer een overeenkomende CSS-selector verschijnt. OnResponse geeft je de ruwe response body, wat handig is als de payload JSON is in plaats van HTML. OnError vangt requests op die mislukken. Crawlen werkt op dezelfde manier: in een handler voor links roep je Visit() aan op de URL's die je vindt, Colly zet ze in de wachtrij en MaxDepth bepaalt hoe ver de crawler mag rondlopen. Callback, visit-wachtrij, dieptelimiet, statisch gecompileerd. Geen interpreter, geen runtime, geen headless Chrome die in het geheugen hangt.
Het callback-model, en waarom dat de extractie anders laat voelen
Die callbacks zijn de hele persoonlijkheid van de tool, dus die verdienen wat extra aandacht. Drie ervan kwamen in elk testscenario dat ik draaide terug.
OnHTML(selector, handler) is degene die je het vaakst gebruikt. Koppel hem aan .product of article p, en Colly roept je handler één keer per gematcht element aan terwijl hij de DOM parseert. Hier leeft gestructureerde extractie, en dat leest prettig — je beschrijft wat je wilt, niet de loop die het ophaalt.
OnResponse(handler) zit een laag dieper en geeft je de ruwe bytes direct van de lijn. Als een doel JSON teruggeeft in plaats van markup, raak je de DOM nooit aan — je deserialiseert de body zelf. Die ene callback is de reden dat Colly in mijn run een JSON API aankon zonder ook maar een snippertje HTML te hoeven parsen.
OnError(handler) is de callback die iedereen vergeet tot een scraper om 3 uur 's nachts crasht. Hij vuurt af wanneer een request mislukt en geeft je de response, zodat je de statuscode kunt lezen en kunt beslissen wat er daarna gebeurt. Een crawler die fouten stilletjes inslikt is erger dan een crawler die luid laat horen wanneer hij omvalt; Colly doet geen van beide, en dat is belangrijker dan het klinkt wanneer de taak onbeheerd draait.
Twee extra functies zitten boven op die callbacks en zijn operationeel relevant. MaxDepth begrenst de crawl, zodat een link-volgende collector na twee stappen stopt in plaats van het hele web af te reizen. En de build-output is één statische Go-binary — één keer compileren, één bestand zonder runtime-afhankelijkheden, neerzetten op een server of in een CI-job en draaien. Als je ooit een middag hebt verloren aan een Python virtualenv op een kale machine, voelt dit deploy-profiel eerder als een pluspunt dan als een voetnoot.
Setup — de Go-toolchain die niemand noemt
Het verhaal rond dependencies is kort, maar er zit één echte hobbel in, dus die noem ik meteen voordat je iets installeert. De machine waarop ik testte had helemaal geen Go, en Colly is een Go-library, dus stap nul was een toolchain op het systeem zetten — ik installeerde Go 1.26.5 via Homebrew. Als je team niet al in Go werkt, is dát de echte frictie. Niet de library zelf. Maar de taalomgeving die je nodig hebt voordat er ook maar één regel compileert.
Met Go geïnstalleerd liep Colly verder soepel. go get github.com/gocolly/colly/v2 kwam zonder gedoe uit op v2.3.0 — geen browser, geen headless-gedoe, niets anders dan die gecompileerde binary aan het eind. Zet dat af tegen Python-scrapers die een parser installeren en vervolgens omvallen bij de eerste fetch door een keten aan ontbrekende extras, en dit was heerlijk saai. Saai is hier een compliment.
Eén nauwkeurige noot, helder geformuleerd, omdat dit je absoluut in de war brengt als je erin duikt. De nieuwste module op de Go-proxy is v2.3.0, gepubliceerd in december 2025. De nieuwste getagde release op GitHub is v2.2.0, van maart 2025. Dus de code die ik testte — v2.3.0 — loopt voor op wat je op de Releases-pagina ziet. Dat is een eigenaardigheid van hoe Go-modules en GitHub-tags in de loop van de tijd uit elkaar kunnen lopen, niet een teken dat er iets mis is. Kijk dus niet raar op als go get en de Releases-pagina verschillende versies laten zien.
Praktisch getest — de cijfers achter "snel"
Ik heb Colly getest tegen een zelfvoorzienende fixture-server op basis van Go's httptest, plus twee publieke demowebsites, zodat het gedrag reproduceerbaar is in plaats van een mooi verhaal van mijn hand. Dit kwam eruit.
| Test | Doel | Resultaat |
|---|---|---|
| Statische catalogus + paginering | lokale fixture | 12/12 producten, recall 1.0 |
| Artikel-extractie | lokale fixture | titel + 3/3 paragrafen |
| Dynamische JSON API | lokale fixture | 8/8 items via OnResponse, recall 1.0 |
| HTTP 500-afhandeling | lokale fixture | doorgestuurd naar OnError, status 500 |
Crawl-graph (MaxDepth 2) | lokale fixture | 17 pagina's |
| Books to Scrape | publieke demo | 20 producten |
| Dynamische pagina (zonder JS) | lokale fixture | 0 kaarten (verwacht) |
| Quotes JS (zonder render) | publieke demo | 0 (verwacht) |
Lees je dit van boven naar beneden, dan klopt het geheel. Statische extractie was strak — 12 van 12 producten uit de catalogus, alle drie paragrafen uit het artikel, alles gestuurd door OnHTML-selectors. De JSON-API-test opende nooit een HTML-parser: OnResponse gaf de body door, ik deserialiseerde die, en 8 van 8 items kwamen terug. De 500-test is degene waar ik het meest op leun, omdat die het verschil markeert tussen een crawler die je 's nachts kunt laten doorlopen en eentje die dat niet kan — Colly stuurde de fout naar OnError en gaf de status netjes door, zonder crash en zonder dat er iets stil verdween. Op de publieke Books to Scrape demo haalde hij 20 producten op zonder speciale trucjes.
Het crawlresultaat is de headline, en ik wil het zorgvuldig formuleren. Een collector met MaxDepth(2), die links volgde en ze naar absolute URL's oploste, bereikte 17 pagina's in mijn fixture-graph. Dat is eindelijk die "snelle Go-crawler"-claim, maar dan vastgepind op een concreet aantal pagina's in plaats van een gevoel. Let wel op de formulering — 17 pagina's binnen een crawl met dieptelimiet 2. Dat dieptegetal is de telling van mijn testopzet zelf en beschrijft hoe ik de run heb geconfigureerd; ik beweer dus niet dat Colly intern contractueel garandeert "exact diepte 2, geen link verder". De eerlijke, controleerbare uitspraak is deze: met een dieptelimiet op 2 doorliep de crawl de graph en bereikte 17 pagina's.
Dan het plafond, en daar worden de "zo snel is het"-posts meestal stil. Colly voert geen JavaScript uit. Ik zette hem op een JavaScript-gerenderde fixture en kreeg 0 kaarten terug; ik zette hem op de publieke Quotes to Scrape JS-pagina en kreeg opnieuw 0. Dat is geen bug en ook geen minpunt. Colly is een HTTP-crawler — hij downloadt en parseert HTML, maar start nooit een browser om client-side scripts uit te voeren. Net als Scrapy en andere HTTP-first crawlers: als de content die je zoekt alleen bestaat nadat JavaScript draait, dan geeft Colly je elke keer een leeg resultaat, en geen enkele hoeveelheid ruwe snelheid verandert daar iets aan. Koppel hem aan een renderer, of kies een tool die er standaard één meelevert.
Ik ben ook eerlijk over wat ik niet heb getest, zodat niemand mijn resultaten verder oprekt dan het bewijs toelaat. Ik heb de async collector, de rate-limiting- en politeness-config, proxy-rotatie, en de queue- en storage-backends niet doorgedrukt. Die bestaan wel in Colly. Ik testte de kern voor extractie en crawlen, niet de schaal-infrastructuur eromheen. De README claimt een throughput van meer dan duizend requests per seconde op één core, maar dat is de eigen projectcijfer; ik heb paginacounts en recall gemeten, geen throughput. Als ik dus "snel" zeg, bedoel ik het gecompileerde Go-extractiepad dat ik daadwerkelijk heb getest, niet een head-to-head throughputbenchmark tegen Scrapy die ik niet heb uitgevoerd.
Voor- en nadelen
Voordelen:
- Volledige recall bij statische extractie — 12/12 catalogusproducten en 3/3 artikelparagrafen via
OnHTML. - Strakke JSON-afhandeling via
OnResponse, zonder DOM-parsing nodig — 8/8 API-items. - Correcte foutafhandeling — een 500 kwam in
OnErrorterecht met zichtbare status, zonder crash. - Een crawl met dieptelimiet bereikte 17 pagina's vanuit één collector.
- Eén statische Go-binary, nul runtime-afhankelijkheden — uitstekend voor deployment en operations.
- Een permissieve Apache-2.0-licentie.
Nadelen:
- Geen JavaScript-uitvoering — client-gerenderde content komt simpelweg als 0 terug.
- Er is een Go-toolchain nodig; teams die niet al in Go werken betalen die setup-kost voordat ze ook maar één scraper schrijven.
- De nieuwste module (
v2.3.0) loopt voor op de nieuwste getagde release (v2.2.0), wat iedereen in verwarring brengt die naar de Releases-pagina kijkt. - De output is je eigen code — Colly geeft je callbacks, geen ingebouwde dataset of feed-exporter zoals Scrapy dat doet.
- Async, rate-limiting, proxy en queue-backends bestaan wel, maar heb ik hier niet getest; "snel" verwijst hier naar het extractiepad dat ik heb gemeten, niet naar een directe throughputvergelijking.
Voor wie Colly bedoeld is — en wie beter kan doorlopen
Colly past goed als je al Go schrijft en HTML- of JSON-gedreven sites op snelheid wilt crawlen. Als jouw definitie van een nette deploy is dat je één binary op een machine zet en hem draait — geen interpreter, geen virtualenv, geen dependency-loterij — dan is dit precies waarvoor de tool is gemaakt. Het callback-model bewijst zijn waarde zodra je extractie niet meer triviaal is: OnHTML voor structuur, OnResponse voor ruwe payloads, OnError voor fouten die je anders nooit ziet. Voor een statische of API-gedreven target die je op schema uit CI crawlt, is dit een sterke keuze zonder drama.
Sla hem over, of gebruik er in elk geval een tweede tool naast, zodra je targets sterk leunen op JavaScript. Colly gaf 0 terug op elke client-gerenderde pagina die ik hem voorlegde, en dat is by design — geen instelling die je even omzet. Sla hem ook over als je team niet met Go werkt en je liever geen toolchain opzet alleen om een paar sites te scrapen — de taalkeuze is echt en je moet die zelf onderhouden. En als je gestructureerde data liever kant-en-klaar ontvangt dan dat je die met eigen code moet parsen, dan ligt dat werk bij Colly volledig aan jouw kant van de lijn.
Alternatieven — waar een beheerde AI-scraping-API past
Colly is een gratis, open source library die je zelf compileert en draait. Jij beheert de Go-code, de callbacks, de crawl-logica en de machine waarop het draait — en in ruil daarvoor betaal je niets per request en houd je de hele operatie in eigen huis. Voor een Go-shop is dat een verdedigbare keuze, en die deploy als één binary is echt prettig.
De twee plekken waar het ophoudt, zijn precies de twee die het waard zijn om met iets anders te vergelijken. Ten eerste: JavaScript — Colly rendert dat niet, dus alles wat client-side is valt buiten bereik, tenzij je er een browser aan koppelt. Ten tweede: structuur — Colly geeft je callbacks en laat het netjes vormen van output aan je eigen code over. Een beheerde AI-scraping-API pakt beide zaken anders aan. De ontwikkelaarsstack van Thunderbit verwerkt JavaScript-rendering en geeft gestructureerde data server-side terug. POST /distill zet een pagina om in nette, LLM-klare Markdown, waarbij dynamische content en anti-botafhandeling voor je worden geregeld. POST /extract levert gestructureerde JSON op basis van een JSON Schema dat jij definieert, met een renderMode die je kunt opschalen naar volledige browser-rendering wanneer een pagina dat nodig heeft. Er is een Thunderbit MCP-server voor AI-agents en coding assistants — thunderbit_suggest_fields is gratis, zodat je kunt verkennen wat een pagina blootgeeft voordat je je vastlegt — en een CLI die je kunt draaien met npx @thunderbit/thunderbit-cli voor terminal, CI en cron.
Probeer Thunderbit voor webdata-extractie
De afweging is niet beter versus slechter. Het gaat erom waar het werk terechtkomt. Met Colly houd je rendering (geen), parsing en onderhoud in je eigen gecompileerde binary, zonder kosten per call, en je moet het zelf bijhouden wanneer een site verandert. Met een beheerde API besteed je JavaScript-rendering, anti-bot en gestructureerde output uit, en betaal je per call voor dat gemak. Kleine, Go-native, HTML- of JSON-gedreven targets die je graag zelf beheert en onderhoudt? Dan winnen Colly's controle en snelheid gewoon. JavaScript-zware pagina's, of wil je simpelweg schema-achtige JSON ontvangen in plaats van nog een callback te schrijven? Dan is de beheerde route logischer. Als je het bredere landschap wilt zien, zetten de overzichten van de beste web scraping tools en beste web scraping GitHub-projecten goed uiteen waar een library als Colly staat naast browsergebaseerde en beheerde opties.
Conclusie
Moet je Colly gebruiken? Ja — als je Go schrijft en HTML of JSON op snelheid wilt crawlen, doet hij wat de reputatie van "fast crawler" belooft, en nu staan daar ook cijfers achter. Volledige recall bij statische extractie. Strakke JSON via OnResponse. Een 500 die netjes naar OnError ging in plaats van te verdwijnen. Een crawl met dieptelimiet 2 die 17 pagina's bereikte. Alles gecompileerd in één statische binary zonder runtime-afhankelijkheden, en dat is ongeveer het vriendelijkste deploy-verhaal in deze hele categorie.
Wees wel eerlijk in hoe je de claims afbakent. Hij rendert geen JavaScript — elke client-side pagina in mijn run gaf 0 terug, en dat is permanent, geen vergeten instelling. Je hebt een Go-toolchain nodig, dus niet-Go-teams betalen vooraf een setup-taks. De module die je installeert (v2.3.0) loopt voor op de nieuwste getagde release (v2.2.0), dus raak niet in paniek als de pagina's het niet eens zijn. En "snel" betekent hier het extractiepad dat ik heb gemeten, niet een throughputbenchmark die ik niet heb uitgevoerd. Binnen die grenzen is Colly een snelle, betrouwbare, echt deploybare Go-crawler — en hij maakt zijn reputatie waar zodra je hem niet langer vraagt om JavaScript uit te voeren.
Probeer Thunderbit voor webdata-extractie Get Started Free
FAQ's
Is Colly echt snel, en zit daar een cijfer achter? Ja, in de betekenis die telt voor het kernpad dat ik heb gemeten: gecompileerde Go, volledige recall bij statische extractie (12/12 catalogusproducten), strakke JSON-afhandeling en een crawl met dieptelimiet 2 die 17 pagina's bereikte — allemaal uit één statische binary. Wat ik niet heb gedaan, is een throughputbenchmark tegen Scrapy draaien, dus zie "snel" als gemeten extractiegedrag en niet als een directe snelheidsvergelijking.
Kan Colly pagina's scrapen die met JavaScript worden gerenderd? Nee. Colly is een HTTP-crawler — hij downloadt en parseert HTML, maar start nooit een browser. Een JavaScript-gerenderde fixture gaf 0 kaarten terug, en de publieke Quotes JS-pagina gaf ook 0 terug. Voor client-side content moet je Colly koppelen aan een renderer of een tool gebruiken die browser-rendering standaard meelevert.
Moet ik Go kennen om Colly te gebruiken?
Ja. Colly is een Go-library, geen losse CLI — je importeert hem, registreert callbacks (OnHTML, OnResponse, OnError) en compileert vervolgens. De machine waarop ik testte had geen Go geïnstalleerd, dus de setup begon met het installeren van een toolchain (1.26.5). Als je team niet al in Go werkt, is die omgeving de echte setup-kost.
Waarom komt de versie die ik installeer niet overeen met de nieuwste GitHub-release van Colly?
Omdat de Go-module en de GitHub-release-tag uit elkaar zijn gaan lopen. De nieuwste module op de Go-proxy is v2.3.0 (december 2025), terwijl de nieuwste getagde release op GitHub v2.2.0 is (maart 2025). Ik heb v2.3.0 getest. Het is een modules-versus-tags-kwestie, geen kapotte installatie.
Is Colly gratis voor commercieel gebruik? Ja, het is Apache-2.0, dus permissief en commercieel vriendelijk. Controleer zoals altijd de actuele licentie in de repo voordat je erop voortbouwt.
