Colly को खोजिए, और उसके लिए जो पहला adjective मिलेगा, वह लगभग हमेशा यही होगा: fast. तेज़ Go crawler, तेज़ क्योंकि यह compile होता है, तेज़ क्योंकि बीच में browser नहीं आता। लेकिन लगभग कोई भी इसके साथ कोई संख्या नहीं जोड़ता।
इसलिए मैंने इसे सिर्फ़ बातों पर नहीं छोड़ा। मैंने एक छोटा test site तैयार किया, Colly को उस पर compile करके चलाया, और देखा कि library असल में क्या करती है — real pages पर recall कितना मिलता है, failed request को कैसे route करती है, depth-limited crawl कितना दूर तक जाता है। संक्षेप में, numbers से पहले ही बता दूँ: static extraction में पूरा recall मिला, एक 500 error ठीक उसी जगह पहुँचा जहाँ पहुँचना चाहिए था, और depth cap वाले crawl ने बिना किसी browser के, एक single static binary से 17 pages तक पहुँच बनाई। Library ने हर JavaScript-rendered page पर clean zero भी लौटाया — और यही वह हिस्सा है जिसे “fast” कहने वाले अक्सर छोड़ देते हैं।
Colly असल में क्या है — और क्या नहीं है
Colly खुद को “Golang के लिए एक elegant scraper and crawler framework” कहता है, और यह एक पंक्ति जितनी सामान्य लगती है, उससे कहीं ज़्यादा मायने रखती है। यह एक Go library है — लगभग ~25.4k stars (2026-07-09 तक), gocolly/colly पर, Apache-2.0 license के साथ। यह कोई ऐसा command-line tool नहीं है जिसे डाउनलोड करके सीधे किसी URL पर चला दें। आपको Go में code लिखना होता है, package import करना होता है, कुछ callbacks जोड़ने होते हैं, और फिर उसे एक executable में compile करना होता है।
इसका mental model event-driven है, और यही बात उन लोगों को चौंकाती है जो request-and-parse वाली आदत से आते हैं। आप response को line by line नहीं पढ़ते और fields नहीं निकालते। आप Collector पर handlers लगाते हैं और library को pages के साथ चलते हुए उन्हें trigger करने देते हैं। OnHTML हर matching CSS selector पर extraction code चलाता है। OnResponse आपको raw response body देता है, जो तब काम आता है जब payload HTML नहीं बल्कि JSON हो। OnError उन requests को पकड़ता है जो fail हो जाती हैं। Crawling भी इसी तरह काम करती है: links वाले handler के अंदर आप मिली हुई URLs पर Visit() करते हैं, Colly उन्हें queue करता है, और MaxDepth तय करता है कि crawl कितनी दूर तक जा सकता है। Callback, visit queue, depth limit, compiled static binary — न interpreter, न runtime, न memory में बैठा headless Chrome।
Callback model और extraction का अनुभव कैसे बदलता है
Callbacks ही इस tool की पूरी पहचान हैं, इसलिए इन्हें थोड़ा ध्यान से समझना चाहिए। मेरी हर test run में तीन callbacks सबसे ज़्यादा काम आए।
OnHTML(selector, handler) वही है जिसका आप सबसे ज़्यादा इस्तेमाल करेंगे। इसे .product या article p पर register कर दीजिए, और DOM parse होते समय हर matched element के लिए Colly आपका handler चला देता है। Structured extraction यहीं रहती है, और यह बहुत साफ़ पढ़ती है — आप बताते हैं कि आपको क्या चाहिए, न कि वह loop जो data लाएगा।
OnResponse(handler) एक स्तर नीचे काम करता है और आपको wire से सीधे raw bytes देता है। जब target markup की जगह JSON लौटाता है, तो DOM की ज़रूरत ही नहीं पड़ती — आप body को खुद unmarshal करते हैं। मेरे run में Colly ने एक JSON API इसी callback की वजह से HTML के एक भी टुकड़े को parse किए बिना संभाल लिया।
OnError(handler) वह callback है जिसे लोग तब तक भूल जाते हैं जब तक 3 बजे सुबह कोई scraper टूट न जाए। यह तब trigger होता है जब request fail होती है और response आपको सौंप देता है, ताकि आप status code पढ़कर अगला कदम तय कर सकें। ऐसा crawler जो fail को चुपचाप निगल जाए, उससे बेहतर है जो ज़ोर से गिर पड़े; Colly न तो failure छुपाता है, न dramatic तरीके से टूटता है — और unattended job चलाते समय यह मामूली बात नहीं है।
इन callbacks के ऊपर दो और चीज़ें हैं जो operational रूप से बहुत मायने रखती हैं। MaxDepth crawl को सीमित करता है, इसलिए link-following collector दो hops के बाद रुक जाता है, खुली web में घूमता नहीं रहता। और build output एक single static Go binary होता है — एक बार compile करो, runtime dependencies के बिना एक file मिलती है, server या CI job में डालो और चला दो। अगर आपने कभी fresh machine पर Python virtualenv की वजह से आधा दिन गंवाया है, तो यह deployment profile footnote नहीं, feature लगती है।
Setup — वह Go toolchain जिसे कोई ज़िक्र नहीं करता
Dependency story छोटी है, लेकिन इसमें एक असली catch है, इसलिए install करने से पहले ही बता देता हूँ। जिस machine पर मैंने test किया, उस पर Go पहले से था ही नहीं, और Colly एक Go library है, इसलिए पहला कदम मशीन पर toolchain डालना था — मैंने Homebrew के ज़रिए Go 1.26.5 install किया। अगर आपकी team पहले से Go में काम नहीं करती, तो यही असली friction है। Library नहीं। वह language environment, जिसकी इसे compile होने से पहले ज़रूरत पड़ती है।
Go होने के बाद Colly pull करना आसान था। go get github.com/gocolly/colly/v2 बिना किसी झंझट के v2.3.0 पर resolve हो गया — न browser, न headless कुछ, सिर्फ़ अंत में compiled binary। इसे उन Python scrapers के मुकाबले रखिए जो parser तो डाल लेते हैं, लेकिन missing extras की chain की वजह से पहली ही fetch पर बिखर जाते हैं — यह अनुभव सुखद रूप से साधारण था। और यहाँ साधारण होना तारीफ़ है।
एक precision note भी साफ़-साफ़: अगर आप जाकर खुद खोदेंगे तो यह बात आपको भ्रमित कर सकती है। Go proxy पर latest module v2.3.0 है, published December 2025 में। GitHub पर newest tagged release v2.2.0 है, March 2025 की। यानी मैंने जो code test किया — v2.3.0 — वह repository की Releases page से आगे है। यह Go modules और GitHub tags के समय के साथ अलग-अलग हो जाने की वजह से है, किसी खराबी की वजह से नहीं। बस go get और Releases page अलग-अलग numbers दिखाएँ तो चौंकिए मत।
Hands-on — “fast” के पीछे के numbers
मैंने Colly को Go के httptest पर बने एक self-contained fixture server पर, और दो public demo sites पर चलाया, ताकि behavior repeatable रहे, कोई मनगढ़ंत कहानी नहीं। ये नतीजे मिले।
| Test | Target | Result |
|---|---|---|
| Static catalog + pagination | local fixture | 12/12 products, recall 1.0 |
| Article extraction | local fixture | title + 3/3 paragraphs |
| Dynamic JSON API | local fixture | 8/8 items via OnResponse, recall 1.0 |
| HTTP 500 handling | local fixture | routed to OnError, status 500 |
Crawl graph (MaxDepth 2) | local fixture | 17 pages |
| Books to Scrape | public demo | 20 products |
| Dynamic page (no JS) | local fixture | 0 cards (expected) |
| Quotes JS (no render) | public demo | 0 (expected) |
इसे ऊपर से नीचे पढ़िए, तस्वीर साफ़ हो जाती है। Static extraction बिल्कुल ठीक रही — catalog से 12 में 12 products, article से तीनों paragraphs, सब OnHTML selectors से। JSON API test में HTML parser का इस्तेमाल ही नहीं हुआ: OnResponse ने body दी, मैंने उसे unmarshal किया, 8 में 8 items वापस आ गए। 500 test वह है जिस पर मैं सबसे ज़्यादा भरोसा करता हूँ, क्योंकि यही एक लाइन तय करती है कि crawler को रात भर चलने देना सुरक्षित है या नहीं — Colly ने failure को OnError में भेजा और status साफ़-साफ़ दिखाया, न crash हुआ, न silently drop किया। Public Books to Scrape demo पर इसने बिना किसी खास handling के 20 products निकाल लिए।
Crawl result सबसे अहम है, और इसे मैं सावधानी से कहना चाहूँगा। MaxDepth(2) collector, links follow करते हुए और उन्हें absolute URLs में resolve करते हुए, मेरे fixture graph में 17 pages तक पहुँचा। यही वह “fast Go crawler” वाली बात है, जो अब किसी mood की जगह एक असली page count से जुड़ती है। लेकिन wording को ध्यान से पढ़िए — 17 pages depth-2 crawl के भीतर। वहाँ depth number मेरे test harness का अपना counter है, यानी मैंने run को कैसे configure किया, उसे दिखाने के लिए। मैं यह दावा नहीं कर रहा कि Colly अपने भीतर “exactly depth 2, उससे एक लिंक आगे नहीं” जैसी कोई सख्त contract guarantee करता है। साफ़, जाँची जा सकने वाली बात यह है: depth cap 2 होने पर crawl ने graph traverse करके 17 pages तक पहुँच बनाई।
अब वह सीमा, जहाँ “यह तो बहुत fast है” वाले लेख अक्सर चुप हो जाते हैं। Colly JavaScript नहीं चलाता। मैंने इसे एक JavaScript-rendered fixture पर चलाया और 0 cards मिले; फिर public Quotes to Scrape JS page पर चलाया और फिर से 0। यह bug नहीं है, और न ही कोई कमी। Colly एक HTTP crawler है — यह HTML डाउनलोड करता है और parse करता है, लेकिन client-side scripts चलाने के लिए कभी browser नहीं खोलता। Scrapy और दूसरे HTTP-first crawlers की तरह, अगर आपको चाहिए हुआ content JavaScript execute होने के बाद ही मौजूद होता है, तो Colly हर बार खाली result देगा, और raw speed उस line को नहीं बदल सकती। ऐसे में इसे किसी renderer के साथ जोड़िए, या फिर ऐसा tool चुनिए जिसमें renderer पहले से built-in हो।
और मैं उतना ही साफ़ रहूँगा उन चीज़ों के बारे में जिन्हें मैंने test ही नहीं किया, ताकि कोई मेरे results को evidence से आगे न खींच ले। मैंने async collector, rate-limiting और politeness config, proxy rotation, या queue और storage backends को नहीं परखा। ये सब Colly में मौजूद हैं। मैंने extraction और crawl core चलाया, scale-out plumbing नहीं। README single core पर प्रति सेकंड एक हज़ार से ज़्यादा requests की throughput की बात करता है, लेकिन वह project का अपना आंकड़ा है — मैंने page counts और recall मापा, throughput नहीं। इसलिए जब मैं “fast” कहता हूँ, मेरा मतलब compiled-Go extraction path से है जिसे मैंने सच में clock किया, न कि Scrapy के खिलाफ़ कोई throughput benchmark जिससे मैं खुद अभी तक गुज़रा ही नहीं हूँ।
फायदे और नुकसान
फायदे:
- Static extraction में पूरा recall —
OnHTMLके जरिए catalog के 12/12 products और article के 3/3 paragraphs। OnResponseसे साफ़ JSON handling, DOM parsing की ज़रूरत नहीं — 8/8 API items।- Error routing सही — 500
OnErrorमें पहुँचा, status दिखा, crash नहीं हुआ। - Depth-limited crawl ने single collector से 17 pages तक पहुँच बनाई।
- एक static Go binary, runtime dependencies शून्य — deployment और operations के लिहाज़ से बहुत अच्छा profile।
- Permissive Apache-2.0 license।
नुकसान:
- JavaScript execution नहीं — client-rendered content सीधा 0 लौटाता है, बिना किसी अपवाद के।
- Go toolchain चाहिए; जो team पहले से Go में नहीं है, उसे scraper लिखने से पहले setup cost देनी पड़ती है।
- Latest module (
v2.3.0) newest tagged release (v2.2.0) से आगे है, जिससे Releases page पढ़ने वाला कोई भी व्यक्ति उलझ सकता है। - Output आपका अपना code है — Colly callbacks देता है, Scrapy की तरह built-in dataset या feed exporter नहीं।
- Async, rate-limiting, proxy, और queue backends मौजूद हैं, लेकिन यहाँ test नहीं हुए; “fast” वह extraction path है जिसे मैंने measure किया, कोई head-to-head throughput number नहीं।
Colly किसके लिए है — और किसे इससे बचना चाहिए
अगर आप पहले से Go लिखते हैं और HTML- या JSON-backed sites को तेज़ी से crawl करते हैं, तो Colly आपके लिए ठीक बैठता है। अगर आपकी clean deploy की परिभाषा एक binary को box पर copy करके चलाने की है — बिना interpreter, बिना virtualenv, बिना dependency roulette — तो यह tool ठीक उसी सोच के लिए बनाया गया है। Callback model तब अपनी कीमत वसूल करता है जब extraction trivial नहीं रहता: structure के लिए OnHTML, raw payload के लिए OnResponse, और उन failures के लिए OnError जिन्हें आप वरना कभी देख ही नहीं पाते। Static या API-backed target को अगर आप CI से schedule पर crawl करते हैं, तो यह एक मजबूत, बिना नाटक वाला विकल्प है।
लेकिन इसे छोड़ दीजिए, या कम से कम साथ में एक दूसरा tool जोड़ दीजिए, जब targets JavaScript पर निर्भर हों। मैंने जितने भी client-rendered pages Colly के सामने रखे, सभी पर 0 आया — और यह design की वजह से है, कोई toggle-able setting नहीं। इसे तब भी छोड़ दीजिए अगर आपकी team Go छूती भी नहीं, और आप सिर्फ़ कुछ sites scrape करने के लिए toolchain खड़ा नहीं करना चाहते — language commitment असली है और उसे बनाए रखना आपका काम होगा। और अगर आपको structured data code से parse करने के बजाय सीधे मिलना चाहिए, तो Colly के callbacks वह काम पूरी तरह आपकी तरफ़ डाल देते हैं।
Alternatives — managed AI scraping API कहाँ फिट होती है
Colly एक free, open-source library है जिसे आप compile करके खुद चलाते हैं। आप Go code, callbacks, crawl logic, और जिस machine पर यह चलता है — सब अपने पास रखते हैं — और बदले में प्रति request कोई खर्च नहीं देते, ऑपरेशन भी अंदर ही रहता है। Go shop के लिए यह एक मज़बूत जवाब है, और single-binary deployment सच में बहुत अच्छा है।
जहाँ यह रुकता है, वही दो जगहें किसी और चीज़ से तुलना करने लायक हैं। पहली, JavaScript — Colly इसे render नहीं करता, इसलिए browser जोड़ने के बिना client-side content बाहर ही रहेगा। दूसरी, structure — Colly callbacks देता है और clean output shaping का काम आपके code पर छोड़ देता है। Managed AI scraping API इन दोनों का अलग जवाब देती है। Thunderbit का developer stack JS rendering संभालता है और server-side पर structured data लौटाता है। POST /distill किसी page को साफ़, LLM-ready Markdown में बदल देता है, dynamic content और anti-bot handling के साथ। POST /extract आपके द्वारा तय किए गए JSON Schema के आधार पर structured JSON लौटाता है, और page को browser rendering चाहिए हो तो renderMode को full browser rendering तक बढ़ाया जा सकता है। AI agents और coding assistants के लिए Thunderbit MCP server भी है — thunderbit_suggest_fields free है, इसलिए commit करने से पहले देख सकते हैं कि page क्या expose करता है — और terminal, CI, और cron के लिए npx @thunderbit/thunderbit-cli से चलने वाला CLI भी।
वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ
यह trade-off “बेहतर” बनाम “खराब” का नहीं है। सवाल यह है कि काम कहाँ किया जाए। Colly के साथ rendering (जो है ही नहीं), parsing, और maintenance सब आपकी अपनी compiled binary के अंदर रहते हैं, per-call cost शून्य होता है, और साइट का ढाँचा बदलते ही आपको ही उसे संभालना पड़ता है। Managed API के साथ आप JS rendering, anti-bot, और structured output बाहर सौंप देते हैं, और इस सुविधा के लिए per call भुगतान करते हैं। छोटे, Go-native, HTML- या JSON-backed targets जिन्हें आप खुद own और maintain करना चाहते हैं? वहाँ Colly का control और speed साफ़ जीतते हैं। JavaScript-heavy pages, या अगर आप schema-shaped JSON सीधे लेना चाहते हैं और एक और callback लिखना नहीं चाहते? तब managed route बेहतर है। अगर आपको broader landscape चाहिए, तो best web scraping tools और best web scraping GitHub projects वाली roundups दिखाती हैं कि Colly जैसी library browser-based और managed options के बीच कहाँ बैठती है।
निष्कर्ष
क्या आपको Colly इस्तेमाल करना चाहिए? हाँ — अगर आप Go लिखते हैं और HTML या JSON को तेज़ी से crawl करते हैं, तो यह “fast crawler” वाली reputation पर खरा उतरता है, और अब उस reputation के पीछे numbers भी हैं। Static extraction में पूरा recall। OnResponse से साफ़ JSON। 500 सही तरीके से OnError में पहुँचा, गायब नहीं हुआ। Depth-2 crawl 17 pages तक पहुँचा। यह सब एक static binary में compile होकर आया, और runtime dependencies बिल्कुल नहीं थीं — इस category में deployment story के लिहाज़ से शायद सबसे आसान।
लेकिन claims को ईमानदारी से नापिए। यह JavaScript नहीं चलाता — मेरी run में हर client-side page ने 0 लौटाया, और यह स्थायी है, कोई missed setting नहीं। इसे Go toolchain चाहिए, इसलिए non-Go teams को upfront setup tax देना पड़ता है। जो module आप install करते हैं (v2.3.0), वह newest tagged release (v2.2.0) से आगे है, इसलिए pages के numbers अलग दिखें तो घबराइए नहीं। और यहाँ “fast” का मतलब वह extraction path है जिसे मैंने measure किया, न कि कोई throughput benchmark जिसे मैंने अभी तक चलाया ही नहीं। इन सीमाओं के भीतर Colly एक तेज़, भरोसेमंद, सच में deployable Go crawler है — और जिस पल आप इससे JavaScript चलाने की उम्मीद छोड़ देते हैं, यह अपनी reputation पर पूरी तरह खरा उतरता है।
वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ Get Started Free
FAQs
क्या Colly सच में तेज़ है, और क्या इसके पीछे कोई number है? हाँ, उस core path के लिए तेज़ है जिसे मैंने measure किया: compiled Go, static extraction में full recall (catalog के 12/12 products), clean JSON handling, और 17 pages तक पहुँचा depth-2 crawl — सब एक single static binary से। लेकिन मैंने Scrapy के खिलाफ़ कोई throughput benchmark नहीं चलाया, इसलिए “fast” को measured extraction behavior समझिए, कोई head-to-head speed score नहीं।
क्या Colly JavaScript-rendered pages scrape कर सकता है? नहीं। Colly एक HTTP crawler है — यह HTML डाउनलोड और parse करता है, लेकिन browser कभी नहीं चलाता। एक JavaScript-rendered fixture ने 0 cards लौटाए, और public Quotes JS page ने भी 0। Client-side content के लिए आपको Colly को किसी renderer के साथ जोड़ना होगा या ऐसा tool इस्तेमाल करना होगा जिसमें browser rendering पहले से मौजूद हो।
क्या Colly इस्तेमाल करने के लिए Go जानना ज़रूरी है?
हाँ। Colly कोई standalone CLI नहीं, बल्कि एक Go library है — आप इसे import करते हैं, callbacks (OnHTML, OnResponse, OnError) register करते हैं, और compile करते हैं। जिस machine पर मैंने test किया, उस पर Go पहले से नहीं था, इसलिए setup की शुरुआत toolchain install करने से हुई (1.26.5)। अगर आपकी team पहले से Go में काम नहीं करती, तो यही environment असली setup cost है।
जो version मैं install करता हूँ, वह Colly के latest GitHub release से match क्यों नहीं करता?
क्योंकि Go module और GitHub release tag समय के साथ अलग हो गए हैं। Go proxy पर latest module v2.3.0 है (December 2025), जबकि GitHub पर newest tagged release v2.2.0 है (March 2025)। मैंने v2.3.0 test किया। यह modules-versus-tags की quirk है, broken install नहीं।
क्या Colly commercial use के लिए free है? हाँ, यह Apache-2.0 license के तहत है, जो permissive और commercially friendly है। हमेशा की तरह, उस पर build करने से पहले repo पर current license ज़रूर confirm कर लें।
