Søk på «Colly», og det første adjektivet du nesten alltid møter, er det samme: rask. Rask Go-crawler, rask fordi den kompileres, rask fordi den ikke trenger å forholde seg til en nettleser. Nesten ingen setter tall på påstanden.
Så jeg sluttet å ta det for god fisk. Jeg satte opp et lite testsystem, kompilerte Colly mot det, og så på hva biblioteket faktisk gjorde — treffrate på ekte sider, hvordan en mislykket forespørsel ble håndtert, og hvor langt en crawl med begrenset dybde kunne vandre. Kortversjonen, før tallene: statisk uthenting ga full treffrate, en 500-feil havnet akkurat der den skulle, og en crawl med dybdebegrensning nådde 17 sider fra én statisk binær uten nettleser. Biblioteket returnerte også en ren null på alt som var gjengitt med JavaScript — som tilfeldigvis er den delen «rask»-koret ofte hopper over.
Hva Colly faktisk er — og ikke er

Colly beskriver seg selv som et «elegant scraper- og crawler-rammeverk for Golang», og den ene setningen betyr mer enn den kanskje ser ut til ved første øyekast. Dette er et Go-bibliotek — rundt ~25,4k stjerner per 2026-07-09 på gocolly/colly, med Apache-2.0-lisens. Det er ikke et kommandolinjeverktøy du laster ned og peker mot en URL. Du skriver Go, importerer pakken, kobler opp noen få callbacks, og kompilerer resultatet til én kjørbar fil.
Tankemodellen er hendelsesdrevet, og det skaper ofte friksjon for folk som er vant til å hente én side, parse den og plukke ut feltene. Du itererer ikke over et svar og trekker ut data linje for linje. Du kobler håndterere til en Collector, og lar biblioteket trigge dem mens det går gjennom sidene. OnHTML kjører uthentingskoden din hver gang en matchende CSS-selector dukker opp. OnResponse gir deg rått responsinnhold, som er nyttig når payloaden er JSON og ikke HTML. OnError fanger opp forespørsler som feiler. Crawling fungerer på samme måte: inne i en handler for lenker kaller du Visit() på URL-ene du finner, Colly legger dem i kø, og MaxDepth avgjør hvor langt den får lov til å gå. Callbacks, besøkskø, dybdegrense, kompilert statisk binær. Ingen tolk, ingen runtime, ingen headless Chrome som ligger og spiser minne.
Callback-modellen, og hvorfor den endrer hvordan uthenting føles
Callbacks er hele personligheten til verktøyet, så de fortjener litt mer plass. Tre av dem bar alle testene jeg kjørte.
OnHTML(selector, handler) er den du kommer til å bruke mest. Registrer den på .product eller article p, og Colly kaller håndtereren din én gang per treff mens DOM-en parses. Det er her strukturert uthenting hører hjemme, og det er lett å lese — du beskriver hva du vil ha, ikke løkka som henter det.
OnResponse(handler) ligger et nivå under og gir deg de rå bytesene rett fra nettet. Når en kilde returnerer JSON i stedet for markup, trenger du aldri å røre DOM-en — du deserialiserer bare kroppen selv. Den ene callbacken er grunnen til at Colly håndterte et JSON-API i testen min uten å parse et eneste HTML-element.
OnError(handler) er callbacken alle glemmer helt til en scraper dør klokka tre om natten. Den trigges når en forespørsel feiler og gir deg responsen, slik at du kan lese statuskoden og avgjøre hva som skjer videre. En crawler som stille svelger feil er verre enn en som krasjer høyt og tydelig; Colly gjør ingen av delene, og det er viktigere enn det høres ut når jobben går uten tilsyn.
To flere funksjoner ligger oppå disse callbacksene og betyr mye i praksis. MaxDepth setter en grense for crawl, så en lenkefølgende collector stopper to hopp ute i stedet for å vandre rundt på hele nettet. Og byggresultatet er én statisk Go-binær — kompiler én gang, få én fil uten runtime-avhengigheter, legg den på en server eller inn i en CI-jobb, og kjør. Hvis du noen gang har mistet en ettermiddag på en Python-virtualenv på en ny maskin, føles denne deploy-modellen som en fordel, ikke en fotnote.
Oppsett — Go-verktøykjeden ingen nevner
Avhengighetshistorien er kort, men den har én reell hake, så jeg sier det før du installerer noe. Maskinen jeg testet på hadde ikke Go i det hele tatt, og Colly er et Go-bibliotek, så første steg var å legge inn en toolchain på maskinen — jeg installerte Go 1.26.5 via Homebrew. Hvis teamet ditt ikke allerede jobber i Go, er det dette som faktisk koster tid. Ikke biblioteket. Språk-miljøet som må være på plass før én eneste linje kan kompileres.
Med Go på plass gikk det smertefritt å hente Colly. go get github.com/gocolly/colly/v2 ga v2.3.0 uten drama — ingen nettleser, ingen headless-løsning, ingenting utover den kompilerte binæren til slutt. Sammenlignet med Python-scrapere som installerer en parser og så faller fra hverandre ved første kall fordi en ekstra pakke mangler, var dette overraskende udramatisk. Udramatisk er et kompliment her.
En presisjonsnotis, rett ut, fordi den garantert vil forvirre deg hvis du begynner å grave. Den nyeste modulen på Go-proxyen er v2.3.0, publisert i desember 2025. Den nyeste taggede utgivelsen på GitHub er v2.2.0, fra mars 2025. Så koden jeg testet — v2.3.0 — ligger foran det releases-siden i repositoriet viser. Det er en særhet i hvordan Go-moduler og GitHub-tagger sklir fra hverandre over tid, ikke et tegn på at noe er galt. Bare ikke bli overrasket når go get og Releases-siden viser ulike numre.
Praktisk test — tallene bak «rask»
Jeg kjørte Colly mot en egen, lukket testserver bygget med Go httptest, pluss to offentlige demosider, slik at resultatet er reproduserbart og ikke bare en historie jeg forteller. Her er hva som kom tilbake.

| Test | Mål | Resultat |
|---|---|---|
| Statisk katalog + paginering | lokal testside | 12/12 produkter, treffrate 1.0 |
| Artikkeluthenting | lokal testside | tittel + 3/3 avsnitt |
| Dynamisk JSON-API | lokal testside | 8/8 elementer via OnResponse, treffrate 1.0 |
| Håndtering av HTTP 500 | lokal testside | sendt til OnError, status 500 |
Crawl-graf (MaxDepth 2) | lokal testside | 17 sider |
| Books to Scrape | offentlig demo | 20 produkter |
| Dynamisk side (uten JS) | lokal testside | 0 kort (forventet) |
| Quotes JS (uten rendering) | offentlig demo | 0 (forventet) |

Leser du dette fra topp til bunn, holder bildet seg hele veien. Statisk uthenting var ren — 12 av 12 produkter fra katalogen, alle tre avsnittene fra artikkelen, alt styrt av OnHTML-selectors. JSON-API-testen åpnet aldri en HTML-parser: OnResponse ga meg kroppen, jeg deserialiserte den, og 8 av 8 elementer kom tilbake. 500-testen er den jeg stoler mest på, fordi den skiller en crawler du kan la gå over natta fra en du ikke kan stole på — Colly sendte feilen til OnError og eksponerte statusen tydelig, uten krasj og uten at noe forsvant stille. På den offentlige Books to Scrape demoen hentet den ut 20 produkter uten noen spesialbehandling.
Crawl-resultatet er hovedpoenget, og jeg vil formulere det nøye. En MaxDepth(2)-collector som fulgte lenker og løste dem til absolutte URL-er, nådde 17 sider gjennom testgrafen min. Det er altså «rask Go-crawler»-påstanden endelig festet til et faktisk sidetall, ikke bare en magefølelse. Men legg merke til formuleringen — 17 sider innenfor en crawl med dybde 2. Dybdetallet der er min egen test-håndterers teller, som beskriver hvordan jeg satte opp kjøringen; jeg påstår ikke at Colly internt garanterer «akkurat dybde 2, og ikke ett lenkehopp mer» som en kontrakt. Den ærlige, verifiserbare påstanden er denne: med dybden begrenset til 2, gikk crawlen gjennom grafen og nådde 17 sider.

Så kommer taket, der «det er så raskt»-innleggene som regel blir stille. Colly kjører ikke JavaScript. Jeg pekte den mot en JavaScript-rendret testside og fikk 0 kort tilbake; jeg pekte den mot den offentlige Quotes to Scrape JS-siden og fikk 0 igjen. Det er ikke en feil, og det er ikke et minus. Colly er en HTTP-crawler — den laster ned og parser HTML, men starter aldri en nettleser for å kjøre klientside-skript. Som Scrapy og andre HTTP-første crawlere: hvis innholdet du vil ha bare finnes etter at JavaScript har kjørt, får Colly tomt resultat hver gang, og ingen mengde rå fart endrer det. Koble den sammen med en renderer, eller velg et verktøy som leveres med en.
Jeg vil også være helt tydelig på hva jeg ikke testet, så ingen drar konklusjonene mine lenger enn bevisene tillater. Jeg presset ikke async-collectoren, rate limiting- og høflighetsinnstillingene, proxy-rotasjon eller kø- og lagringsbackendene. De finnes i Colly. Jeg testet kjernefunksjonen for uthenting og crawling, ikke skaleringsdelene. README-en hevder gjennomstrømning på over tusen forespørsler i sekundet på én kjerne, men det er prosjektets egen opplysning — jeg målte sidetall og treffrate, ikke throughput, så når jeg sier «rask» mener jeg den kompilerte Go-uthentingsbanen jeg faktisk målte, ikke en benchmark mot Scrapy jeg ikke kjørte.
Fordeler og ulemper
Fordeler:
- Full treffrate på statisk uthenting — 12/12 katalogprodukter og 3/3 artikkelavsnitt via
OnHTML. - Ren håndtering av JSON via
OnResponse, uten behov for DOM-parsing — 8/8 API-elementer. - Korrekt feilruting — en 500 havnet i
OnErrormed status synlig, uten krasj. - En crawl med begrenset dybde nådde 17 sider fra én collector.
- Én statisk Go-binær, null runtime-avhengigheter — svært god løsning for drift og deploy.
- Tillatende Apache-2.0-lisens.
Ulemper:
- Ingen JavaScript-kjøring — klientrendret innhold kommer tilbake som 0, punktum.
- Krever Go-verktøykjede; team som ikke allerede bruker Go må ta den oppstartskostnaden før de skriver en eneste scraper.
- Den nyeste modulen (
v2.3.0) ligger foran den nyeste taggede utgivelsen (v2.2.0), noe som kan forvirre alle som ser på Releases-siden. - Resultatet er koden din egen — Colly gir deg callbacks, ikke et innebygd datasett eller feed-eksport slik Scrapy gjør.
- Async-, rate limiting-, proxy- og kø-backendene finnes, men ble ikke testet her; «rask» er uthentingsbanen jeg målte, ikke et direkte sammenlignbart throughput-tall.
Hvem Colly passer for — og hvem bør styre unna

Colly passer hvis du allerede skriver Go og crawler nettsteder som bygger på HTML eller JSON, og du vil ha fart. Hvis din definisjon av en ryddig deploy er å kopiere én binær til en maskin og kjøre den — ingen tolk, ingen virtualenv, ingen avhengighetslotteri — er dette verktøyet laget for akkurat den typen oppsett. Callback-modellen viser verdien sin med én gang uthentingen blir mer enn trivielt enkel: OnHTML for struktur, OnResponse for rå payload, OnError for feilene du ellers aldri ville sett. For en statisk eller API-basert kilde du crawler etter plan fra CI, er dette et solid og lite dramatisk valg.
Styr unna, eller i det minste koble på et ekstra verktøy, når målene dine er avhengige av JavaScript. Colly ga 0 på hver eneste klientrendret side jeg testet, og det er design, ikke en innstilling du kan skru på. Styr unna også hvis teamet ditt ikke bruker Go og du helst ikke vil sette opp en toolchain bare for å hente data fra noen få nettsteder — språkforpliktelsen er reell, og det er du som må vedlikeholde den. Og hvis du vil ha strukturert data levert til deg i stedet for å måtte parse den selv i egen kode, legger Colly den jobben direkte på din side av bordet.
Alternativer — hvor en administrert AI-scraping-API passer inn
Colly er et gratis, åpen kildekode-bibliotek du kompilerer og kjører selv. Du eier Go-koden, callbacksene, crawl-logikken og maskinen som kjører det — og til gjengjeld betaler du ingenting per forespørsel og beholder hele oppsettet internt. For en Go-organisasjon er det et fullt forsvarlig svar, og deploy med én binær er faktisk veldig behagelig.
De to stedene der det stopper, er også de to som er verdt å sammenligne med noe annet. Først: JavaScript — Colly renderer det ikke, så alt som er klientside er ute av bildet med mindre du kobler på en nettleser. Deretter: struktur — Colly gir deg callbacks og overlater utformingen av ryddig output til din egen kode. En administrert AI-scraping-API håndterer begge deler annerledes. Thunderbit-stakken for utviklere tar seg av JavaScript-rendering og returnerer strukturert data på serversiden. POST /distill gjør en side om til ren, LLM-klar Markdown, med dynamisk innhold og anti-bot-håndtering inkludert. POST /extract returnerer strukturert JSON mot et JSON Schema du definerer, med renderMode du kan skru opp til full nettleserrendering når en side trenger det. Det finnes en Thunderbit MCP-server for AI-agenter og kodeassistenter — thunderbit_suggest_fields er gratis, så du kan se hva en side faktisk eksponerer før du bestemmer deg — og en CLI du kan kjøre med npx @thunderbit/thunderbit-cli for terminal, CI og cron.
Prøv Thunderbit for uthenting av webdata
Avveiningen handler ikke om bedre eller dårligere. Den handler om hvor arbeidet ligger. Med Colly beholder du rendering (ingen), parsing og vedlikehold i din egen kompilerte binær, uten kostnad per kall, og du må selv passe på når et nettsted endrer struktur. Med en administrert API-tjeneste overlater du JavaScript-rendering, anti-bot og strukturert output, og betaler per kall for den luksusen. Små, Go-native mål som bygger på HTML eller JSON, og som du gjerne vil eie og vedlikeholde selv? Da vinner Collys kontroll og fart. JavaScript-tunge sider, eller du vil rett og slett heller motta schema-formet JSON enn å skrive enda en callback? Da er den administrerte løsningen mer riktig. Hvis du vil ha et bredere overblikk, viser beste web scraping-verktøy og beste GitHub-prosjekter for web scraping hvor et bibliotek som Colly plasserer seg ved siden av nettleserbaserte og administrerte alternativer.
Konklusjon
Bør du bruke Colly? Ja — hvis du skriver Go og crawler HTML eller JSON i høy hastighet, gjør det det «rask crawler»-ryktet lover, og nå finnes det tall bak ryktet. Full treffrate på statisk uthenting. Ren JSON via OnResponse. En 500 som havnet riktig i OnError. En crawl med dybde 2 som nådde 17 sider. Alt sammen kompilert til én statisk binær uten runtime-avhengigheter, som er omtrent den mest problemfrie deploy-historien i denne kategorien.
Men vurder påstandene ærlig. Den rendrer ikke JavaScript — hver klientside-side i testen min returnerte 0, og det er permanent, ikke en innstilling du har oversett. Den krever en Go-verktøykjede, så team som ikke bruker Go må betale en oppstartskostnad. Modulen du installerer (v2.3.0) ligger foran den nyeste taggede utgivelsen (v2.2.0), så ikke få panikk når sidene ikke er enige. Og «rask» her betyr uthentingsbanen jeg målte, ikke en throughput-benchmark jeg ikke kjørte. Innenfor disse rammene er Colly en rask, pålitelig og genuint deploybar Go-crawler — og den lever opp til ryktet i det øyeblikket du slutter å be den om å kjøre JavaScript.
Prøv Thunderbit for uthenting av webdata Get Started Free
Vanlige spørsmål
Er Colly faktisk rask, og finnes det et tall bak påstanden? Den er rask i den forstand som betyr noe for kjernen jeg målte: kompilert Go, full treffrate på statisk uthenting (12/12 katalogprodukter), ren JSON-håndtering og en crawl med dybde 2 som nådde 17 sider — alt fra én statisk binær. Det jeg ikke kjørte, var en throughput-benchmark mot Scrapy, så se på «rask» som målt uthentingsatferd, ikke en direkte hastighetssammenligning.
Kan Colly scrape sider som rendres med JavaScript? Nei. Colly er en HTTP-crawler — den laster ned og parser HTML, men kjører aldri en nettleser. En JavaScript-rendret testside ga 0 kort, og den offentlige Quotes JS-siden ga også 0. For klientsideinnhold må du enten koble Colly til en renderer eller bruke et verktøy som har nettleserrendering innebygd.
Må jeg kunne Go for å bruke Colly?
Ja. Colly er et Go-bibliotek, ikke et frittstående CLI-verktøy — du importerer det, registrerer callbacks (OnHTML, OnResponse, OnError) og kompilerer. Maskinen jeg testet på hadde ikke Go installert, så oppsettet startet med å legge inn en toolchain (1.26.5). Hvis teamet ditt ikke allerede jobber i Go, er dette miljøet den reelle oppstartskostnaden.
Hvorfor matcher ikke versjonen jeg installerer den nyeste GitHub-utgivelsen til Colly?
Fordi Go-modulen og GitHub-release-taggen har sklidd fra hverandre. Den nyeste modulen på Go-proxyen er v2.3.0 (desember 2025), mens den nyeste taggede utgivelsen på GitHub er v2.2.0 (mars 2025). Jeg testet v2.3.0. Det er en modul-versus-tag-særhet, ikke en ødelagt installasjon.
Er Colly gratis til kommersiell bruk? Ja, den har Apache-2.0-lisens, som er permissiv og kommersielt vennlig. Som alltid bør du sjekke den gjeldende lisensen i repoet før du bygger videre på den.


