Caută „Colly” și primul adjectiv pe care îl vezi mereu este același: rapid. Un crawler Go rapid, rapid pentru că se compilează, rapid pentru că nu are un browser care să-l încurce. Aproape nimeni nu îi pune însă un număr în spate.
Așa că nu m-am mai bazat pe reputație. Am ridicat un mic site de test, am compilat Colly pe el și am urmărit ce face de fapt biblioteca — cât de bine extrage pe pagini reale, cum gestionează o cerere eșuată, cât de departe merge o parcurgere limitată prin adâncime. Varianta scurtă, înainte de cifre: extracția statică a revenit cu acoperire completă, un 500 a ajuns exact unde trebuia, iar un crawl cu limită de adâncime a ajuns la 17 pagini dintr-un singur binar static, fără browser atașat. Biblioteca a întors și un zero curat pe tot ce era randat cu JavaScript — partea pe care refrenul „rapid” tinde s-o ignore.
Ce este, de fapt, Colly — și ce nu este
Colly se descrie ca un „framework elegant de scraper și crawler pentru Golang”, iar această propoziție spune mai mult decât pare la prima vedere. Este o bibliotecă Go — aproximativ ~25,4k stele la 2026-07-09 pe gocolly/colly, cu licență Apache-2.0. Nu este un instrument de linie de comandă pe care îl descarci și îl rulezi direct pe un URL. Scrii cod Go, imporți pachetul, conectezi câteva callback-uri și compilezi rezultatul într-un singur executabil.
Modelul mental este unul bazat pe evenimente, iar asta îi încurcă pe cei obișnuiți cu fluxul „cerere și parsare”. Nu iterezi printr-un răspuns și nu scoți câmpurile unul câte unul. Atașezi handlers la un Collector și lași biblioteca să le declanșeze pe măsură ce parcurge paginile. OnHTML îți rulează codul de extracție de fiecare dată când apare un selector CSS care se potrivește. OnResponse îți oferă corpul brut al răspunsului, lucru important când payload-ul este JSON, nu HTML. OnError prinde cererile care eșuează. Parcurgerea funcționează la fel: într-un handler pentru linkuri, apelezi Visit() pe URL-urile găsite, Colly le pune în coadă, iar MaxDepth decide până unde are voie să ajungă crawlerul. Callback-uri, coadă de vizitare, limită de adâncime, binar static compilat. Fără interpreter, fără runtime, fără Chrome headless care să stea în memorie.
Modelul cu callback-uri și de ce schimbă senzația de lucru
Callback-urile sunt chiar personalitatea instrumentului, așa că merită explicate pe îndelete. Trei dintre ele au acoperit toate testele pe care le-am rulat.
OnHTML(selector, handler) este cel mai folosit. Îl înregistrezi pe .product sau article p, iar Colly îți cheamă handlerul o dată pentru fiecare element care se potrivește, pe măsură ce parsează DOM-ul. Aici trăiește extracția structurată și se citește bine — descrii ce vrei, nu bucla care îl adună.
OnResponse(handler) stă cu un nivel mai jos și îți dă octeții brut din rețea. Când o țintă returnează JSON în loc de markup, nu mai atingi deloc DOM-ul — deserialezi singur corpul. Tocmai acest callback este motivul pentru care Colly a gestionat în testul meu un API JSON fără să parseze nici măcar o bucățică de HTML.
OnError(handler) este callback-ul pe care toată lumea îl uită până când un scraper pică la 3 dimineața. Se declanșează când o cerere eșuează și îți oferă răspunsul, ca să poți citi codul de stare și să decizi ce urmează. Un crawler care înghite eșecurile în tăcere e mai rău decât unul care cade zgomotos; Colly nu face nici una, nici alta, iar asta contează mai mult decât pare când jobul rulează nesupravegheat.
Peste aceste callback-uri mai sunt două lucruri care contează operațional. MaxDepth limitează crawl-ul, astfel încât un collector care urmărește linkuri se oprește după două salturi în loc să se plimbe prin tot webul. Iar rezultatul build-ului este un singur binar Go static — compilezi o dată, obții un fișier fără dependențe de runtime, îl pui pe un server sau într-un job CI și îl rulezi. Dacă ai pierdut vreodată o după-amiază din cauza unui virtualenv Python pe un sistem proaspăt, acest mod de livrare pare o funcționalitate, nu un detaliu de notă de subsol.
Setup — lanțul de toolchain Go pe care nimeni nu-l menționează
Povestea dependențelor e scurtă, dar are o singură capcană reală, așa că o spun de la început, înainte să instalezi ceva. Mașina pe care am testat nu avea deloc Go, iar Colly este o bibliotecă Go, deci pasul zero a fost să pun un toolchain pe sistem — am instalat Go 1.26.5 prin Homebrew. Dacă echipa ta nu trăiește deja în Go, aceasta este fricțiunea reală. Nu biblioteca. Ci mediul de limbaj de care are nevoie înainte să poată fi compilat primul rând.
Cu Go instalat, adăugarea lui Colly a mers lin. go get github.com/gocolly/colly/v2 a rezolvat la v2.3.0 fără probleme — fără browser, fără headless, nimic în afară de binarul compilat la final. Compară asta cu scrapers Python care instalează un parser și apoi se rup la primul fetch din cauza unui șir întreg de extra-uri lipsă, iar experiența aceasta a fost plăcut de banală. Iar „banal” aici este un compliment.
Un detaliu important, spus foarte clar, pentru că altfel te va încurca dacă începi să cauți. Cea mai recentă versiune de pe Go proxy este v2.3.0, publicată în decembrie 2025. Cea mai nouă versiune tag-uită pe GitHub este v2.2.0, din martie 2025. Așadar, codul pe care l-am testat — v2.3.0 — este mai nou decât ce apare pe pagina Releases din repository. Este o particularitate a modului în care se desincronizează în timp modulele Go și tag-urile GitHub, nu un semn că ceva nu merge. Doar nu te mira când go get și pagina Releases îți arată numere diferite.
Test practic — cifrele din spatele lui „rapid”
Am rulat Colly pe un server fixture autonom construit cu httptest din Go, plus două site-uri demo publice, ca să poată fi reprodus comportamentul, nu doar povestit. Iată ce a ieșit.
| Test | Țintă | Rezultat |
|---|---|---|
| Catalog static + paginare | fixture local | 12/12 produse, acoperire 1.0 |
| Extracție articol | fixture local | titlu + 3/3 paragrafe |
| API JSON dinamic | fixture local | 8/8 elemente prin OnResponse, acoperire 1.0 |
| Gestionare HTTP 500 | fixture local | direcționat către OnError, status 500 |
Grafic de crawl (MaxDepth 2) | fixture local | 17 pagini |
| Books to Scrape | demo public | 20 produse |
| Pagină dinamică (fără JS) | fixture local | 0 carduri (așteptat) |
| Quotes JS (fără randare) | demo public | 0 (așteptat) |
Dacă citești de sus în jos, imaginea se leagă foarte bine. Extracția statică a fost curată — 12 din 12 produse din catalog, toate cele trei paragrafe din articol, totul condus de selectorii OnHTML. Testul API JSON n-a deschis niciodată un parser HTML: OnResponse a livrat corpul, eu l-am deserializat, iar 8 din 8 elemente s-au întors. Testul cu 500 este cel pe care mă bazez cel mai tare, pentru că aici se vede diferența dintre un crawler pe care îl poți lăsa să meargă peste noapte și unul pe care nu — Colly a trimis eșecul la OnError și a expus curat statusul, fără crash și fără pierdere tăcută. Pe demo-ul public Books to Scrape a extras 20 de produse fără vreo tratare specială.
Rezultatul de crawl este titlul principal și vreau să-l formulez atent. Un collector cu MaxDepth(2), care urmărește linkuri și le rezolvă la URL-uri absolute, a ajuns la 17 pagini în graful meu de fixture. Asta este linia „crawler Go rapid”, dar acum fixată pe un număr real de pagini, nu pe o impresie. Totuși, citește bine formularea — 17 pagini în cadrul unui crawl cu adâncime 2. Numărul de adâncime de acolo este contorul meu de test, care descrie cum am configurat rularea; nu afirm că Colly garantează intern „exact adâncime 2, nici un link în plus” ca și contract. Enunțul onest, verificabil, este acesta: cu limita de adâncime setată la 2, crawl-ul a traversat graful și a ajuns la 17 pagini.
Acum limita, zona în care postările despre „e atât de rapid” devin de obicei tăcute. Colly nu rulează JavaScript. L-am trimis pe un fixture randat cu JavaScript și am primit 0 carduri; l-am trimis și pe pagina publică Quotes to Scrape JS și am primit tot 0. Asta nu este nici bug, nici reproș. Colly este un crawler HTTP — descarcă și parsează HTML, dar nu pornește niciodată un browser pentru a rula scripturi pe client. La fel ca Scrapy și celelalte crawlere HTTP-first, dacă ceea ce cauți există doar după ce se execută JavaScript, Colly îți întoarce de fiecare dată un rezultat gol, iar viteza brută nu schimbă cu nimic acest lucru. Îl combini cu un renderer sau alegi un instrument care vine deja cu unul.
Voi spune la fel de direct și ce nu am testat, ca să nu împingă nimeni rezultatele mele dincolo de ce arată dovezile. Nu am împins collectorul async, nici configurarea de rate limiting și politețe, nici rotația proxy-urilor, nici backend-urile de coadă și storage. Acestea există în Colly. Eu am rulat nucleul de extracție și crawl, nu infrastructura de scalare. README-ul promite un throughput de peste o mie de cereri pe secundă pe un singur core, dar aceea este cifra proiectului — eu am măsurat număr de pagini și acoperire, nu throughput, așa că atunci când spun „rapid” mă refer la traseul de extracție compilat în Go pe care chiar l-am cronometrat, nu la un benchmark față în față cu Scrapy pe care nu l-am rulat.
Pro și contra
Pro:
- Acoperire completă pe extracția statică — 12/12 produse din catalog și 3/3 paragrafe din articol prin
OnHTML. - Gestionare curată a JSON prin
OnResponse, fără parsare DOM — 8/8 elemente din API. - Rutare corectă a erorilor — un 500 a ajuns în
OnErrorcu statusul expus, fără crash. - Un crawl limitat ca adâncime a ajuns la 17 pagini dintr-un singur collector.
- Un singur binar Go static, zero dependențe de runtime — un profil excelent de deploy și operare.
- Licență Apache-2.0 permisivă.
Contra:
- Fără execuție JavaScript — conținutul randat pe client revine cu 0, fără excepție.
- Necesită un toolchain Go; echipele care nu lucrează deja în Go plătesc costul de setup înainte să scrie vreun scraper.
- Cel mai nou modul (
v2.3.0) este înaintea celei mai noi versiuni tag-uite (v2.2.0), lucru care îi va deruta pe cei care se uită la pagina Releases. - Outputul este codul tău — Colly îți dă callback-uri, nu un set de date sau un exporter de feed integrat, cum face Scrapy.
- Backend-urile async, rate limiting, proxy și queue există, dar nu au fost testate aici; „rapid” este traseul de extracție pe care l-am măsurat, nu o cifră de throughput comparată direct.
Pentru cine este Colly — și cine ar trebui să-l sară
Colly se potrivește dacă scrii deja în Go și faci crawl pe site-uri bazate pe HTML sau JSON, la viteză. Dacă pentru tine un deploy curat înseamnă să copiezi un singur binar pe o mașină și să-l pornești — fără interpreter, fără virtualenv, fără loterie de dependențe — instrumentul a fost construit exact pentru această abordare. Modelul cu callback-uri își arată valoarea imediat ce extracția nu mai este trivială: OnHTML pentru structură, OnResponse pentru payload brut, OnError pentru eșecurile pe care altfel nu le-ai vedea. Pentru o țintă statică sau bazată pe API, pe care o rulezi la program din CI, este o alegere puternică și fără dramă.
Sari peste el, sau cel puțin adaugă un al doilea instrument, atunci când țintele tale se bazează pe JavaScript. Colly a întors 0 pe fiecare pagină randată pe client pe care i-am pus-o în față, iar asta este intenționat, nu o setare pe care să o activezi. Sari peste el și dacă echipa ta nu folosește Go și n-ai chef să ridici un toolchain doar ca să extragi date de pe câteva site-uri — angajamentul față de limbaj este real și îl vei întreține tu. Iar dacă vrei date structurate livrate direct, nu parsate de codul tău, callback-urile lui Colly pun munca asta exact pe partea ta de gard.
Alternative — unde se potrivește un API de scraping AI gestionat
Colly este o bibliotecă gratuită, open-source, pe care o compilezi și o rulezi singur. Tu deții codul Go, callback-urile, logica de crawl și mașina pe care rulează — iar în schimb nu plătești nimic per cerere și păstrezi operațiunea în interiorul companiei. Pentru o echipă Go, aceasta este o soluție perfect defensibilă, iar deploy-ul într-un singur binar chiar este plăcut.
Cele două puncte în care se oprește sunt exact cele pe care merită să le compari cu altceva. Primul: JavaScript — Colly nu îl randază, așa că orice conținut generat pe client iese din discuție, decât dacă adaugi tu un browser. Al doilea: structura — Colly îți oferă callback-uri și lasă modelarea outputului curat în seama codului tău. Un API de scraping AI gestionat răspunde diferit la ambele. Stack-ul pentru dezvoltatori de la Thunderbit se ocupă de randarea JavaScript și returnează date structurate server-side. POST /distill transformă o pagină în Markdown curat, gata pentru LLM, cu conținut dinamic și protecție anti-bot gestionate pentru tine. POST /extract returnează JSON structurat pe baza unei scheme JSON definite de tine, cu un renderMode pe care îl poți ridica până la randare completă în browser când o pagină are nevoie de asta. Există și un server Thunderbit MCP pentru agenți AI și asistenți de codare — thunderbit_suggest_fields este gratuit, așa că poți vedea ce expune o pagină înainte să te decizi — plus un CLI pe care îl poți rula cu npx @thunderbit/thunderbit-cli pentru terminal, CI și cron.
Încearcă Thunderbit pentru extragerea datelor web
Compromisul nu este mai bun versus mai slab. Este despre locul în care se face munca. Cu Colly, păstrezi randarea (zero), parsarea și mentenanța în propriul binar compilat, la cost zero per apel, și îl întreții tu când site-ul își schimbă forma. Cu un API gestionat, predai randarea JavaScript, protecția anti-bot și outputul structurat, iar pentru acest privilegiu plătești per apel. Ținte mici, native Go, bazate pe HTML sau JSON, pe care ești fericit să le deții și să le întreții? Controlul și viteza lui Colly câștigă clar. Pagini încărcate cu JavaScript sau pur și simplu preferi să primești JSON structurat după schemă, în loc să mai scrii încă un callback? Atunci route-ul gestionat are sens. Dacă vrei panorama mai largă, roundup-urile cu cele mai bune instrumente de web scraping și cele mai bune proiecte GitHub pentru web scraping arată unde se așază o bibliotecă precum Colly lângă opțiunile bazate pe browser și cele gestionate.
Verdict
Ar trebui să folosești Colly? Da — dacă scrii în Go și faci crawl pe HTML sau JSON la viteză, își respectă reputația de „crawler rapid”, iar acum există și cifre care să stea în spatele reputației. Acoperire completă pe extracția statică. JSON curat prin OnResponse. Un 500 direcționat corect către OnError, în loc să dispară. Un crawl cu adâncime 2 care a ajuns la 17 pagini. Totul compilat într-un singur binar static, fără dependențe de runtime, ceea ce este probabil cea mai prietenoasă poveste de deploy din toată categoria.
Totuși, limitele trebuie citite onest. Nu randază JavaScript — fiecare pagină cu randare pe client din testele mele a întors 0, și asta este permanent, nu o setare pe care ai ratat-o. Are nevoie de un toolchain Go, așa că echipele non-Go plătesc costul de setup din start. Modulul pe care îl instalezi (v2.3.0) este mai nou decât cea mai recentă versiune tag-uită (v2.2.0), așa că nu intra în panică dacă paginile îți arată numere diferite. Iar „rapid” aici înseamnă traseul de extracție pe care l-am măsurat, nu un benchmark de throughput pe care nu l-am rulat. În aceste limite, Colly este un crawler Go rapid, fiabil și cu adevărat deployabil — și își merită reputația în momentul în care încetezi să-i ceri să ruleze JavaScript.
Încearcă Thunderbit pentru extragerea datelor web Get Started Free
Întrebări frecvente
Este Colly chiar rapid și există o cifră în spatele afirmației? Este rapid în sensul care contează pentru traseul principal pe care l-am măsurat: Go compilat, acoperire completă pe extracția statică (12/12 produse din catalog), gestionare curată a JSON și un crawl cu adâncime 2 care a ajuns la 17 pagini — totul dintr-un singur binar static. Ce nu am rulat este un benchmark de throughput împotriva Scrapy, așa că tratează „rapid” ca pe un comportament de extracție măsurat, nu ca pe un scor direct de viteză.
Poate Colly să extragă pagini randate cu JavaScript? Nu. Colly este un crawler HTTP — descarcă și parsează HTML, dar nu rulează niciodată un browser. Un fixture randat cu JavaScript a întors 0 carduri, iar pagina publică Quotes JS a întors tot 0. Pentru conținutul randat pe client ai nevoie fie să îl combini cu un renderer, fie să folosești un instrument care include randarea în browser direct.
Trebuie să știu Go ca să folosesc Colly?
Da. Colly este o bibliotecă Go, nu un CLI autonom — o imporți, înregistrezi callback-urile (OnHTML, OnResponse, OnError) și compilezi. Mașina pe care am testat nu avea Go instalat, așa că setup-ul a început cu instalarea unui toolchain (1.26.5). Dacă echipa ta nu lucrează deja în Go, acel mediu este costul real de pornire.
De ce versiunea pe care o instalez nu se potrivește cu cea mai recentă versiune GitHub a lui Colly?
Pentru că modulul Go și tag-ul de release de pe GitHub s-au separat în timp. Cea mai recentă versiune din Go proxy este v2.3.0 (decembrie 2025), în timp ce cea mai nouă versiune tag-uită pe GitHub este v2.2.0 (martie 2025). Eu am testat v2.3.0. Este o particularitate module-versus-tag-uri, nu o instalare stricată.
Este Colly gratuit pentru uz comercial? Da, are licență Apache-2.0, deci este permisiv și prietenos pentru utilizare comercială. Ca întotdeauna, verifică licența actuală în repo înainte să construiești ceva pe baza ei.
