Søg på "Colly", og det første adjektiv er næsten altid det samme: hurtig. En hurtig Go-crawler, hurtig fordi den kompilerer, hurtig fordi der ikke står en browser i vejen. Næsten ingen sætter tal på.
Så jeg valgte ikke bare at tro på påstanden. Jeg satte en lille testside op, kompilerede Colly mod den og kiggede på, hvad biblioteket faktisk gjorde — recall på rigtige sider, hvordan et fejlet request blev håndteret, og hvor langt en crawl med dybdebegrænsning kom. Den korte version, før tallene: statisk udtræk ramte fuld recall, en 500-fejl landede præcis, hvor den skulle, og en crawl med maxdybde nåede 17 sider fra én statisk binary uden browser tilknyttet. Biblioteket gav også et rent nul på alt, der var renderet med JavaScript — hvilket tilfældigvis er den del, "hurtig"-koret ofte springer over.
Hvad Colly egentlig er — og ikke er
Colly beskriver sig selv som et "elegant scraper and crawler framework for Golang", og den ene linje siger mere, end man lige tror. Det her er et Go-bibliotek — omkring ~25,4k stars pr. 2026-07-09 på gocolly/colly, med Apache-2.0-licens. Det er ikke et kommandoværktøj, du downloader og peger mod en URL. Du skriver Go, importerer pakken, kobler et par callbacks på og kompilerer resultatet til ét eksekverbart program.
Den mentale model er event-drevet, og det overrasker folk, der er vant til at hente en side og parse den bagefter. Du gennemløber ikke et svar og trækker felter ud linje for linje. Du kobler handlers til en Collector, og så fyrer biblioteket dem af, mens det bevæger sig gennem siderne. OnHTML kører din udtrækskode, hver gang en matchende CSS-selector dukker op. OnResponse giver dig det rå response-body, hvilket er vigtigt, når payloaden er JSON i stedet for HTML. OnError fanger de requests, der fejler. Crawl fungerer på samme måde: inde i en handler for links kalder du Visit() på de URLs, du finder, Colly køer dem, og MaxDepth bestemmer, hvor langt den må vandre. Callbacks, visit-kø, dybdebegrænsning, kompileret statisk. Ingen interpreter, intet runtime, ingen headless Chrome, der ligger og fylder i hukommelsen.
Callback-modellen, og hvorfor den ændrer, hvordan udtræk føles
Callbacks er hele værktøjets personlighed, så de er værd at dvæle ved. Tre af dem bar alle de tests, jeg kørte.
OnHTML(selector, handler) er den, du bruger mest. Registrér den på .product eller article p, og Colly kalder din handler én gang pr. matchet element, mens DOM’en parses. Det er her struktureret udtræk bor, og det læser fint — du beskriver, hvad du vil have, ikke løkken, der henter det.
OnResponse(handler) ligger et lag længere nede og giver dig de rå bytes direkte fra wire. Når et mål returnerer JSON i stedet for markup, rører du aldrig DOM’en — du unmarshaler selv body’et. Netop den callback er grunden til, at Colly håndterede en JSON-API i min test uden at parse en eneste stump HTML.
OnError(handler) er den callback, alle glemmer, indtil en scraper dør kl. 03 om natten. Den aktiveres, når en request fejler, og giver dig response’en, så du kan se statuskoden og beslutte, hvad der skal ske bagefter. En crawler, der stille sluger fejl, er værre end en, der falder tydeligt om; Colly gør ingen af delene, og det betyder mere, end det lyder, når jobbet kører uden opsyn.
To andre funktioner ligger oven på de callbacks og er vigtige i drift. MaxDepth sætter loft på crawl’en, så en collector, der følger links, stopper to hop ude i stedet for at tage en tur rundt på det åbne web. Og build-outputtet er én statisk Go-binary — kompilér én gang, få én fil uden runtime-afhængigheder, smid den på en server eller ind i et CI-job, og kør den. Hvis du nogensinde har mistet en eftermiddag på en Python virtualenv på en ny maskine, føles den deploymodel som en fordel, ikke som en fodnote.
Setup — Go-toolchainen, ingen nævner
Afhængighedshistorien er kort, men den har én reel hage, så her er den, før du installerer noget. Maskinen jeg testede på havde slet ikke Go installeret, og Colly er et Go-bibliotek, så første skridt var at lægge en toolchain på maskinen — jeg installerede Go 1.26.5 via Homebrew. Hvis dit team ikke allerede arbejder i Go, er det den reelle friktion. Ikke biblioteket. Det er sprogmiljøet, der skal være på plads, før en eneste linje vil kompilere.
Med Go på plads var det enkelt at hente Colly. go get github.com/gocolly/colly/v2 landede på v2.3.0 uden drama — ingen browser, intet headless, intet ud over den kompilerede binary til sidst. Sammenlignet med Python-scrapers, der installerer en parser og derefter går i stykker ved første fetch på grund af en kæde af manglende extras, var det her dejligt kedeligt. Kedeligt er en ros i den sammenhæng.
Et præcist note, lige ud ad posen, fordi det uden tvivl vil forvirre dig, hvis du begynder at grave. Den nyeste modulversion på Go Proxy er v2.3.0, udgivet i december 2025. Den nyeste taggede release på GitHub er v2.2.0, fra marts 2025. Så koden, jeg testede — v2.3.0 — ligger foran det, Releases-siden viser. Det er en detalje ved, hvordan Go-moduler og GitHub-tags over tid glider fra hinanden, ikke et tegn på, at noget er galt. Blot: blink ikke, når go get og Releases-siden fortæller dig forskellige versioner.
Hands-on — tallene bag "hurtig"
Jeg kørte Colly mod en selvstændig fixture-server bygget på Go's httptest, plus to offentlige demosites, så adfærden er reproducerbar og ikke bare en historie, jeg fortæller dig. Her er, hvad der kom tilbage.
| Test | Mål | Resultat |
|---|---|---|
| Statisk katalog + pagination | lokal fixture | 12/12 produkter, recall 1.0 |
| Artikeludtræk | lokal fixture | titel + 3/3 afsnit |
| Dynamisk JSON API | lokal fixture | 8/8 items via OnResponse, recall 1.0 |
| HTTP 500-håndtering | lokal fixture | sendt til OnError, status 500 |
Crawl-graf (MaxDepth 2) | lokal fixture | 17 sider |
| Books to Scrape | offentlig demo | 20 produkter |
| Dynamisk side (uden JS) | lokal fixture | 0 cards (som forventet) |
| Quotes JS (uden render) | offentlig demo | 0 (som forventet) |
Læs det oppefra og ned, og billedet hænger sammen. Det statiske udtræk var rent — 12 ud af 12 produkter fra kataloget, alle tre afsnit fra artiklen, og alt var drevet af OnHTML-selectors. JSON API-testen åbnede aldrig en HTML-parser: OnResponse leverede body’et, jeg unmarshaler det, og 8 ud af 8 items kom retur. 500-testen er den, jeg læner mig hårdest op ad, fordi den er skillelinjen mellem en crawler, du tør lade køre natten over, og en du ikke tør. Colly sendte fejlen til OnError og viste status tydeligt, uden crash og uden, at fejlen forsvandt i stilhed. På den offentlige Books to Scrape demo trak den 20 produkter uden nogen særlig håndtering.
Crawl-resultatet er overskriften, og jeg vil formulere det præcist. En MaxDepth(2) collector, der fulgte links og løste dem til absolutte URLs, nåede 17 sider i min fixture-graf. Det er endelig "hurtig Go crawler"-påstanden, hæftet op på et reelt sideantal i stedet for en fornemmelse. Men læs formuleringen nøje — 17 sider under en depth-2 crawl. Dybdetallet dér er min egen testhåndterings tæller, som beskriver, hvordan jeg konfigurerede kørslen; jeg påstår ikke, at Colly internt garanterer "præcis dybde 2, ikke ét link længere" som kontrakt. Den ærlige, verificerbare formulering er denne: med dybde sat til 2 traverserede crawl’en grafen og nåede 17 sider.
Og så loftet, hvor "den er bare så hurtig"-indlæg normalt bliver tavse. Colly kører ikke JavaScript. Jeg pegede den mod en fixture, der blev renderet med JavaScript, og fik 0 cards tilbage; jeg pegede den mod den offentlige Quotes to Scrape JS-side og fik 0 igen. Det er hverken en bug eller en kritik. Colly er en HTTP-crawler — den downloader og parser HTML og starter aldrig en browser for at køre client-side scripts. Ligesom Scrapy og andre HTTP-first crawlers gælder det, at hvis indholdet kun eksisterer efter JavaScript eksekveres, så giver Colly dig et tomt resultat hver gang, og ingen rå hastighed ændrer på det. Kombinér den med en renderer, eller vælg et værktøj, der leverer én indbygget.
Jeg vil også være helt klar på, hvad jeg ikke testede, så ingen strækker resultaterne længere end beviserne. Jeg pressede ikke async-collectoren, rate limiting og politeness-konfigurationen, proxy-rotation eller queue- og storage-backends. De ting findes i Colly. Jeg testede kernedelen til udtræk og crawl, ikke skaleringsplumbing. README’en lover throughput på over tusind requests i sekundet på én kerne, men det er projektets egen figur — jeg målte sideantal og recall, ikke throughput, så når jeg siger "hurtig", mener jeg den kompilerede Go-udtrækssti, jeg faktisk målte, ikke en benchmark mod Scrapy, jeg ikke har kørt.
Fordele og ulemper
Fordele:
- Fuld recall på statisk udtræk — 12/12 katalogprodukter og 3/3 artikelafsnit via
OnHTML. - Ren håndtering af JSON via
OnResponse, uden behov for DOM-parsing — 8/8 API-items. - Korrekt fejl-routing — en 500 landede i
OnErrormed status eksponeret, uden crash. - En crawl med dybdebegrænsning nåede 17 sider fra én collector.
- Én statisk Go-binary, ingen runtime-afhængigheder — en fremragende deploy- og driftspakke.
- Tilladende Apache-2.0-licens.
Ulemper:
- Ingen JavaScript-eksekvering — client-renderet indhold kommer tilbage som 0, punktum.
- Kræver en Go-toolchain; teams, der ikke allerede arbejder i Go, betaler den opsætningsomkostning, før de skriver en scraper.
- Den nyeste modulversion (
v2.3.0) ligger foran den nyeste taggede release (v2.2.0), hvilket vil forvirre enhver, der kigger på Releases-siden. - Output er din egen kode — Colly giver dig callbacks, ikke et indbygget datasæt eller eksport i feed-stil, som Scrapy gør.
- Async-, rate limiting-, proxy- og queue-backends findes, men blev ikke testet her; "hurtig" er den udtrækssti, jeg målte, ikke et direkte throughput-tal.
Hvem Colly er til — og hvem der bør springe over
Colly passer, hvis du allerede skriver Go og crawler sites, der bygger på HTML eller JSON, og du vil have fart. Hvis din definition af en ren deploy er at kopiere én binary over på en maskine og køre den — ingen interpreter, ingen virtualenv, ingen afhængighedslotteri — så er værktøjet bygget præcis til den tilgang. Callback-modellen tjener sig selv hjem, i det øjeblik udtrækket bliver mere end trivielt: OnHTML til struktur, OnResponse til rå payloads, OnError til de fejl, du ellers aldrig ville se. Til et statisk eller API-baseret mål, du kører på en tidsplan fra CI, er det et stærkt og ukompliceret valg.
Spring det over, eller læg i det mindste et andet værktøj ovenpå, når dine mål læner sig op ad JavaScript. Colly gav 0 på hver eneste client-renderede side, jeg kastede efter den, og det er designet sådan, ikke en indstilling du kan slå til. Spring det også over, hvis dit team ikke rører Go, og du helst ikke vil sætte en toolchain op bare for at scrape et par sites — sproginvesteringen er reel, og det er din opgave at vedligeholde den. Og hvis du vil have strukturerede data leveret til dig i stedet for at blive parsed af kode, du selv ejer, så placerer Colly’s callbacks arbejdet solidt på din side af hegnet.
Alternativer — hvor en managed AI scraping API passer ind
Colly er et gratis, open source-bibliotek, du selv kompilerer og kører. Du ejer Go-koden, callbacks, crawl-logikken og den maskine, det kører på — og til gengæld betaler du intet pr. request og beholder hele operationen internt. For en Go-butik er det et fuldt forsvarligt valg, og single-binary deploy er oprigtigt behagelig.
De to steder, hvor det stopper, er de to steder, det giver mening at sammenligne med noget andet. Først JavaScript — Colly renderer det ikke, så alt client-side er ude af billedet, medmindre du kobler en browser på. Dernæst struktur — Colly giver dig callbacks og overlader formningen af ren output til din egen kode. En managed AI scraping API løser de to ting anderledes. Thunderbit's developer stack håndterer JavaScript-rendering og returnerer strukturerede data server-side. POST /distill gør en side til ren, LLM-klar Markdown, med dynamisk indhold og anti-bot håndteret for dig. POST /extract returnerer struktureret JSON ud fra et JSON Schema, du selv definerer, med en renderMode, du kan skrue op til fuld browser-rendering, når en side har brug for det. Der findes en Thunderbit MCP-server til AI-agenter og kodeassistenter — thunderbit_suggest_fields er gratis, så du kan undersøge, hvad en side eksponerer, før du binder dig — og en CLI, du kan køre med npx @thunderbit/thunderbit-cli i terminalen, CI og cron.
Prøv Thunderbit til webdataudtræk
Afvejningen handler ikke om bedre eller dårligere. Det handler om, hvor arbejdet ligger. Med Colly holder du rendering (ingen), parsing og vedligeholdelse inde i din egen kompilerede binary, til nul pris pr. kald, og du skal selv passe den, når et site ændrer form. Med en managed API sender du JavaScript-rendering, anti-bot og struktureret output videre, og du betaler pr. kald for privilegiet. Små, Go-native, HTML- eller JSON-baserede targets, som du gerne selv ejer og vedligeholder? Collys kontrol og hastighed vinder klart. JavaScript-tunge sider, eller vil du bare hellere modtage schema-formet JSON end at skrive endnu en callback? Så er den managed løsning det rigtige valg. Hvis du vil have det bredere landskab, viser best web scraping tools og best web scraping GitHub projects, hvor et bibliotek som Colly ligger i forhold til browser-baserede og managed muligheder.
Konklusion
Bør du bruge Colly? Ja — hvis du skriver Go og crawler HTML eller JSON hurtigt, så leverer det præcis det, rygtet om en "fast crawler" lover, og nu står der tal bag rygtet. Fuld recall på statisk udtræk. Ren JSON via OnResponse. En 500, der blev routed korrekt til OnError i stedet for bare at forsvinde. En depth-2 crawl, der nåede 17 sider. Alt sammen kompileret til én statisk binary uden runtime-afhængigheder, hvilket er en af de mest venlige deploy-historier i hele den her kategori.
Tag dog påstandene alvorligt. Det renderer ikke JavaScript — hver client-side side i min test gav 0, og det er permanent, ikke en indstilling, du overså. Det kræver en Go-toolchain, så ikke-Go-teams betaler en opsætningsafgift på forhånd. Den version, du installerer (v2.3.0), ligger foran den nyeste taggede release (v2.2.0), så gå ikke i panik, når siderne er uenige. Og "hurtig" her betyder den udtrækssti, jeg målte, ikke en throughput-benchmark, jeg ikke har kørt. Inden for de rammer er Colly en hurtig, pålidelig og reelt deploybar Go-crawler — og den lever op til rygtet, i det øjeblik du holder op med at bede den om at køre JavaScript.
Prøv Thunderbit til webdataudtræk Get Started Free
Ofte stillede spørgsmål
Er Colly faktisk hurtig, og er der tal bag det? Ja, i den forstand der betyder noget for den kernevej, jeg målte: kompileret Go, fuld recall på statisk udtræk (12/12 katalogprodukter), ren JSON-håndtering og en crawl med dybde 2, der nåede 17 sider — alt sammen ud af én statisk binary. Det, jeg ikke kørte, var en throughput-benchmark mod Scrapy, så betragt "hurtig" som den målte udtræksadfærd, ikke en direkte hastighedsscore.
Kan Colly scrape sider, der er renderet med JavaScript? Nej. Colly er en HTTP-crawler — den downloader og parser HTML, men kører aldrig en browser. En JavaScript-renderet fixture gav 0 cards, og den offentlige Quotes JS-side gav også 0. Til client-side indhold skal du enten kombinere Colly med en renderer eller bruge et værktøj, der har browser-rendering indbygget.
Skal jeg kunne Go for at bruge Colly?
Ja. Colly er et Go-bibliotek, ikke et selvstændigt CLI-værktøj — du importerer det, registrerer callbacks (OnHTML, OnResponse, OnError) og kompilerer. Maskinen, jeg testede på, havde ikke Go installeret, så opsætningen startede med at installere en toolchain (1.26.5). Hvis dit team ikke allerede arbejder i Go, er det miljøet den reelle opsætningsomkostning.
Hvorfor matcher den version, jeg installerer, ikke Collys nyeste GitHub-release?
Fordi Go-modulet og GitHub-release-tagget er gledet fra hinanden. Den nyeste modulversion på Go Proxy er v2.3.0 (december 2025), mens den nyeste taggede release på GitHub er v2.2.0 (marts 2025). Jeg testede v2.3.0. Det er et modules-versus-tags-misforhold, ikke en defekt installation.
Er Colly gratis til kommerciel brug? Ja, det er Apache-2.0, hvilket er tilladende og kommercielt venligt. Som altid bør du bekræfte den aktuelle licens på repoet, før du bygger videre på det.
