Sök på "Colly" så dyker samma ord nästan alltid upp först: snabb. Snabb Go-crawler, snabb eftersom den kompileras, snabb eftersom det inte står någon webbläsare i vägen. Nästan ingen sätter en siffra på det.
Så jag valde att inte bara lita på ryktet. Jag satte upp en liten testsajt, kompilerade Colly mot den och tittade på vad biblioteket faktiskt gjorde — hur väl det hämtade verkliga sidor, hur det hanterade ett misslyckat anrop och hur långt en crawl med begränsat djup vandrade. Kortversionen, innan siffrorna: statisk extrahering gav full träffsäkerhet, ett 500-fel landade precis där det skulle, och en crawl med djupgräns nådde 17 sidor från en enda statisk binärfil utan någon webbläsare ansluten. Biblioteket gav också ett rent nollresultat på allt som renderades med JavaScript — vilket råkar vara den detalj som det där "snabb"-köret ofta hoppar över.
Vad Colly faktiskt är — och inte är
Colly beskriver sig själv som ett "elegant scraper and crawler framework for Golang", och den formuleringen väger mer än man först tror. Det här är ett Go-bibliotek — ungefär ~25,4k stjärnor per 2026-07-09 på gocolly/colly, licensierat under Apache-2.0. Det är inte ett kommandoverktyg du laddar ner och kör mot en URL. Du skriver Go-kod, importerar paketet, kopplar ihop några callbacks och kompilerar resultatet till ett enda körbart program.
Tänkesättet är eventdrivet, och det brukar ställa till det för folk som är vana vid att bara hämta och parsa rakt av. Du loopar inte igenom ett svar och plockar ut fält rad för rad. I stället registrerar du handlers på en Collector och låter biblioteket trigga dem medan det traverserar sidor. OnHTML kör din extraheringskod varje gång en matchande CSS-selector dyker upp. OnResponse ger dig rått svarsinnehåll, vilket är viktigt när payloaden är JSON i stället för HTML. OnError fångar de anrop som går fel. Crawlingen fungerar på samma sätt: i en handler för länkar anropar du Visit() på de URL:er du hittar, Colly lägger dem i kön och MaxDepth avgör hur långt den får vandra. Callbacks, visitkö, djupgräns, kompilerat och statiskt. Ingen interpreter, ingen runtime, ingen headless Chrome som ligger och tuggar minne.
Callback-modellen och varför den förändrar hur extrahering känns
Callbacks är hela verktygets personlighet, så de förtjänar att beskrivas lite noggrannare. Tre av dem bar i princip alla tester jag körde.
OnHTML(selector, handler) är den du kommer använda mest. Registrera den mot .product eller article p, och Colly kör din handler en gång per matchande element medan DOM:en parsaas. Det är här strukturerad extrahering hör hemma, och det läser väldigt naturligt — du beskriver vad du vill ha, inte loopen som hämtar det.
OnResponse(handler) ligger ett lager lägre och ger dig de råa byte som kom över nätet. När en målsida returnerar JSON i stället för markup rör du aldrig DOM:en — du avserialiserar kroppen själv. Den enda callbacken är anledningen till att Colly kunde hantera ett JSON-API i min körning utan att behöva tolka en enda bit HTML.
OnError(handler) är callbacken alla glömmer tills en scraper dör klockan tre på natten. Den triggas när ett anrop misslyckas och skickar med svaret så att du kan läsa statuskoden och avgöra vad som ska hända härnäst. En crawler som tyst sväljer fel är sämre än en som kraschar högljutt; Colly gör varken det ena eller det andra, och det spelar större roll än det låter som när jobbet körs obevakat.
Två fler funktioner ligger ovanpå callbacks och är viktiga i drift. MaxDepth sätter ett tak för hur djupt crawlen får gå, så en collector som följer länkar stannar efter två hopp i stället för att irra runt på hela webben. Och byggresultatet är en enda statisk Go-binär — kompilera en gång, få en fil utan runtime-beroenden, lägg den på en server eller in i ett CI-jobb och kör. Om du någon gång har förlorat en eftermiddag på en Python-virtualenv på en ny maskin känns den här distributionsmodellen som en funktion, inte en detalj i marginalen.
Setup — Go-toolchainen som ingen brukar nämna
Beroendekedjan är kort, men den har en riktig hake, så jag tar den först innan du installerar något alls. Maskinen jag testade på hade inte Go installerat, och Colly är ett Go-bibliotek, så steg noll var att lägga in en toolchain på datorn — jag installerade Go 1.26.5 via Homebrew. Om ditt team inte redan lever i Go är det här den verkliga tröskeln. Inte biblioteket. Utan den språkmiljö som krävs innan en enda rad kan kompileras.
När Go väl fanns på plats gick installationen av Colly smidigt. go get github.com/gocolly/colly/v2 landade på v2.3.0 utan krångel — ingen webbläsare, inget headless-läge, inget annat än den kompilerade binären i slutändan. Jämför det med Python-scrapers som installerar en parser och sedan faller sönder vid första hämtningen på grund av saknade extras, så framstod det här som ovanligt odramatiskt. Odramatiskt är en komplimang här.
En precisionsnotis, rakt och tydligt, eftersom den kommer förvirra dig totalt om du börjar gräva. Den senaste modulen på Go-proxyn är v2.3.0, publicerad i december 2025. Den nyaste taggade releasen på GitHub är v2.2.0, från mars 2025. Så koden jag testade — v2.3.0 — ligger före det som visas på repositoryts Releases-sida. Det är en egenhet i hur Go-moduler och GitHub-taggar glider isär över tid, inte ett tecken på att något är fel. Bli bara inte förvånad när go get och Releases-sidan visar olika nummer.
Praktiskt test — siffrorna bakom "snabb"
Jag körde Colly mot en egen kontrollerad testsajt byggd med Go:s httptest, plus två publika demosajter, så att beteendet går att upprepa i stället för att vara en historia jag berättar. Här är vad som kom tillbaka.
| Test | Mål | Resultat |
|---|---|---|
| Statisk katalog + paginering | lokal testmiljö | 12/12 produkter, träffsäkerhet 1.0 |
| Artikelutvinning | lokal testmiljö | titel + 3/3 stycken |
| Dynamiskt JSON-API | lokal testmiljö | 8/8 objekt via OnResponse, träffsäkerhet 1.0 |
| HTTP 500-hantering | lokal testmiljö | skickades till OnError, status 500 |
Crawl-graf (MaxDepth 2) | lokal testmiljö | 17 sidor |
| Books to Scrape | publik demo | 20 produkter |
| Dynamisk sida (utan JS) | lokal testmiljö | 0 kort (förväntat) |
| Quotes JS (utan rendering) | publik demo | 0 (förväntat) |
Läser man det uppifrån och ner håller bilden ihop. Statisk extrahering gick rent — 12 av 12 produkter från katalogen, alla tre stycken från artikeln, allt drivet av OnHTML-selectors. Testet mot JSON-API:t öppnade aldrig någon HTML-parser: OnResponse skickade över kroppen, jag avserialiserade den, och 8 av 8 objekt kom tillbaka. 500-testet är det jag lutar mig tyngst mot, eftersom det är gränsen mellan en crawler du kan låta gå över natten och en som du inte kan lämna ensam — Colly skickade felet till OnError och exponerade statusen tydligt, utan krasch och utan att tyst släppa bort något. På den publika demon Books to Scrape plockade den ut 20 produkter utan någon specialhantering.
Crawlresultatet är rubriken, och jag vill formulera det försiktigt. En MaxDepth(2)-collector som följde länkar och löste dem till absoluta URL:er nådde 17 sidor i min testgraf. Det är alltså den där "snabba Go-crawlern" äntligen förankrad i ett faktiskt sidantal i stället för en känsla. Men läs formuleringen noga — 17 sidor under en crawl med djup 2. Djupnumret där är min egen testharness-räknare, alltså hur jag konfigurerade körningen; jag påstår inte att Colly internt garanterar "exakt djup 2, inte ett länkhopp mer" som ett kontrakt. Det är den ärliga, verifierbara formuleringen: med ett djup tak på 2 traverserade crawlen grafen och nådde 17 sidor.
Och här kommer taket, där de där "den är ju så snabb"-inläggen brukar bli tysta. Colly kör inte JavaScript. Jag riktade den mot en testsida som renderas med JavaScript och fick 0 kort tillbaka; jag riktade den mot den publika Quotes to Scrape JS-sidan och fick 0 igen. Det är varken en bugg eller ett minus i sig. Colly är en HTTP-crawler — den hämtar och parsa HTML, men startar aldrig någon webbläsare för att köra klientscript. Precis som Scrapy och andra HTTP-först-crawlers gäller: om innehållet du vill åt bara finns efter att JavaScript har körts, då får Colly tillbaka ett tomt resultat varje gång, och ingen rå hastighet i världen ändrar på det. Koppla ihop den med en renderer, eller välj ett verktyg som har en inbyggd.
Jag ska också vara lika tydlig med vad jag inte testade, så att ingen drar ut resultaten längre än bevisen räcker. Jag pressade inte den asynkrona collectorn, konfigurationen för rate limiting och hövlighet, proxyrotation eller kö- och lagringsbackends. De finns i Colly. Jag körde kärnan för extrahering och crawl, inte infrastrukturen för att skala ut. README:n anger ett genomflöde på över tusen förfrågningar i sekunden på en enda kärna, men det är projektets egen siffra — jag mätte sidantal och träffsäkerhet, inte throughput, så när jag säger "snabb" menar jag den kompilerade Go-baserade extraheringsvägen jag faktiskt mätte, inte ett benchmark mot Scrapy som jag inte har kört.
För- och nackdelar
Fördelar:
- Full träffsäkerhet i statisk extrahering — 12/12 katalogprodukter och 3/3 artikelstycken via
OnHTML. - Ren hantering av JSON via
OnResponse, utan DOM-parsning — 8/8 API-objekt. - Korrekt felhantering — ett 500-fel hamnade i
OnErrormed statusen synlig, utan krasch. - En crawl med begränsat djup nådde 17 sidor från en enda collector.
- En statisk Go-binär, inga runtime-beroenden — mycket bra för drift och deployment.
- Generös Apache-2.0-licens.
Nackdelar:
- Ingen JavaScript-körning — klientrenderat innehåll kommer tillbaka som 0, punkt.
- Kräver en Go-toolchain; team som inte redan arbetar i Go får betala setup-kostnaden innan de ens skriver en scraper.
- Den senaste modulen (
v2.3.0) ligger före den nyaste taggade releasen (v2.2.0), vilket kan förvirra den som tittar på Releases-sidan. - Utdata är din egen kod — Colly ger dig callbacks, inte ett inbyggt dataset eller exporter som Scrapy gör.
- Async, rate limiting, proxy- och kö-backends finns, men testades inte här; "snabb" syftar på extraheringsvägen jag mätte, inte ett direkt throughput-jämförande test.
Vem Colly passar för — och vem som bör hoppa över den
Colly passar om du redan skriver Go och ska crawla sajter som bygger på HTML eller JSON i hög hastighet. Om din idé om en ren deployment är att kopiera en enda binärfil till en server och köra den — ingen interpreter, ingen virtualenv, inget beroendekaos — då är verktyget byggt precis för det. Callback-modellen gör nytta så fort din extrahering slutar vara trivial: OnHTML för struktur, OnResponse för rå payload, OnError för felen du annars aldrig hade sett. För en statisk eller API-baserad målsida som du kör enligt schema från CI är det här ett starkt, odramatiskt val.
Hoppa över det, eller lägg till ett andra verktyg, när dina mål lutar tungt på JavaScript. Colly gav 0 på varje klientrenderad sida jag testade, och det är avsiktligt, inte en inställning du kan slå på. Hoppa över det också om ditt team inte använder Go och du helst inte vill sätta upp en toolchain bara för att skrapa några sajter — språkåtagandet är på riktigt och det är du som får underhålla det. Och om du vill få strukturerad data serverad till dig i stället för att själv skriva kod som parserar den, då lägger Colly det arbetet helt på din sida av staketet.
Alternativ — var en hanterad AI-scraping-API passar in
Colly är ett gratis open source-bibliotek som du kompilerar och kör själv. Du äger Go-koden, callbacks:en, crawl-logiken och maskinen den körs på — och i gengäld betalar du inget per anrop och behåller hela lösningen internt. För ett Go-team är det ett fullt rimligt val, och deployment med en enda binär är faktiskt riktigt trevlig.
De två punkterna där det tar stopp är också de två punkter som är värda att jämföra med något annat. Först JavaScript — Colly renderar det inte, så allt som är klientside är uteslutet om du inte kopplar på en webbläsare. Sedan struktur — Colly ger dig callbacks och lämnar formateringen av ren output till din egen kod. En hanterad AI-scraping-API-lösning hanterar båda dessa saker på ett annat sätt. Thunderbits utvecklarstack tar hand om JavaScript-rendering och returnerar strukturerad data på serversidan. POST /distill gör om en sida till ren Markdown som är redo för LLM-användning, med dynamiskt innehåll och anti-bot-hantering inkluderat. POST /extract returnerar strukturerad JSON enligt ett JSON Schema du själv definierar, med ett renderMode som kan växlas upp till full webbläsarrendering när sidan kräver det. Det finns en Thunderbit MCP-server för AI-agenter och kodassistenter — thunderbit_suggest_fields är gratis, så du kan undersöka vad en sida faktiskt exponerar innan du bestämmer dig — och en CLI du kan köra med npx @thunderbit/thunderbit-cli för terminal, CI och cron.
Testa Thunderbit för webbdatastrahering
Avvägningen handlar inte om bättre eller sämre. Den handlar om var arbetet ska ske. Med Colly behåller du rendering (ingen), parsning och underhåll i din egen kompilerade binär, utan kostnad per anrop, och du får själv ta hand om det när en sajt ändrar form. Med ett hanterat API lämnar du över JavaScript-rendering, anti-bot och strukturerad output, och betalar per anrop för privilegiet. Små mål, Go-native, HTML- eller JSON-baserade sajter som du gärna äger och underhåller själv? Då vinner Collys kontroll och hastighet direkt. JavaScript-tunga sidor, eller om du helt enkelt hellre vill få schemaformad JSON än att skriva ännu en callback? Då talar det för den hanterade vägen. Om du vill se den större marknaden visar sammanställningarna över bästa web scraping-verktygen och bästa web scraping-projekten på GitHub var ett bibliotek som Colly passar jämfört med webbläsarbaserade och hanterade alternativ.
Slutsats
Ska du använda Colly? Ja — om du skriver Go och crawlar HTML eller JSON i hög hastighet gör den precis det som ryktet om en "snabb crawler" lovar, och nu finns det siffror bakom ryktet. Full träffsäkerhet i statisk extrahering. Ren JSON via OnResponse. Ett 500-fel som skickades rätt till OnError i stället för att försvinna. En crawl med djup 2 som nådde 17 sidor. Allt kompilerat till en enda statisk binär utan runtime-beroenden, vilket är ungefär den mest lättdrivna deploymenthistorien i hela den här kategorin.
Men man måste också hålla sig till verkliga gränser. Den renderar ingen JavaScript — varje klientside-sida i min körning gav 0, och det är permanent, inte en inställning du missat. Den kräver en Go-toolchain, så team som inte jobbar i Go får en uppstartsavgift direkt. Modulen du installerar (v2.3.0) ligger före den nyaste taggade releasen (v2.2.0), så få inte panik när sidorna visar olika nummer. Och "snabb" här betyder den extraheringsväg jag mätte, inte ett genomflödesbenchmark jag inte har kört. Inom de ramarna är Colly en snabb, pålitlig och faktiskt driftsättbar Go-crawler — och den lever upp till sitt rykte i samma ögonblick som du slutar be den att köra JavaScript.
Testa Thunderbit för webbdatastrahering Get Started Free
Vanliga frågor
Är Colly faktiskt snabb, och finns det en siffra bakom det? Den är snabb i den mening som spelar roll för kärnvägen jag mätte: kompilerad Go, full träffsäkerhet i statisk extrahering (12/12 katalogprodukter), ren JSON-hantering och en crawl med djup 2 som nådde 17 sidor — allt ur en enda statisk binär. Det jag inte körde är ett throughputbenchmark mot Scrapy, så se "snabb" som det uppmätta extraheringsbeteendet, inte som ett direkt hastighetsresultat i en head-to-head-jämförelse.
Kan Colly skrapa sidor som renderas med JavaScript? Nej. Colly är en HTTP-crawler — den hämtar och parsa HTML men kör aldrig någon webbläsare. En testsida som renderas med JavaScript gav 0 kort, och den publika Quotes JS-sidan gav också 0. För klientside-innehåll behöver du antingen koppla Colly till en renderer eller använda ett verktyg som har webbläsarrendering inbyggd.
Måste jag kunna Go för att använda Colly?
Ja. Colly är ett Go-bibliotek, inte ett fristående CLI-verktyg — du importerar det, registrerar callbacks (OnHTML, OnResponse, OnError) och kompilerar. Maskinen jag testade på hade inte Go installerat, så uppstarten började med att lägga in en toolchain (1.26.5). Om ditt team inte redan arbetar i Go är den miljön den verkliga startkostnaden.
Varför stämmer inte versionen jag installerar med Collys senaste GitHub-release?
För att Go-modulen och GitHub-taggen har glidit isär. Den senaste modulen på Go-proxyn är v2.3.0 (december 2025), medan den nyaste taggade releasen på GitHub är v2.2.0 (mars 2025). Jag testade v2.3.0. Det är en modul-och-taggar-grej, inte en trasig installation.
Är Colly gratis för kommersiellt bruk? Ja, den är licensierad under Apache-2.0, vilket är generöst och kommersiellt vänligt. Som alltid bör du dubbelkolla den aktuella licensen i repo:t innan du bygger vidare på den.
