ज्यादातर लोग Crawlee से तब मिलते हैं जब वे एक अलग सवाल का जवाब ढूंढ रहे होते हैं: “मुझे कौन-सा headless browser इस्तेमाल करना चाहिए?” असल में यह सही सवाल नहीं है, और Crawlee इसकी वजह है। यह खुद browser नहीं है। यह एक Node/TypeScript फ्रेमवर्क है, जो जरूरत पड़ने पर browser को इस्तेमाल करता है और जरूरत न हो तो उसे छोड़ देता है।
मैंने कुछ दिनों तक Crawlee 3.17.0 को नियंत्रित fixtures और कुछ सार्वजनिक demo sites के साथ टेस्ट किया — Node v22.22.3 और macOS पर। इसका मुख्य दावा — एक लाइब्रेरी, एक API, और नीचे either HTTP crawler या real browser — वही चीज थी जिसे मैं सबसे ज्यादा परखना चाहता था। क्योंकि यही तय करता है कि Crawlee आपकी stack में जोड़ने लायक है या नहीं, या फिर सीधे Playwright इस्तेमाल करना बेहतर होगा। संक्षेप में: दो-engine वाली कहानी काफी हद तक सही निकली, हालांकि कुछ बारीक बातें भी हैं, जिन पर मैं आगे आऊँगा।
Crawlee असल में है क्या, और क्या नहीं
Crawlee खुद को Node.js के लिए web scraping और browser automation library बताता है, जिसे reliable crawlers बनाने के लिए तैयार किया गया है। इसकी official positioning काफी व्यापक है: AI, LLMs, RAG, या GPTs के लिए data निकालना; HTML, PDF, JPG, PNG और दूसरी files डाउनलोड करना; Puppeteer, Playwright, Cheerio, JSDOM और raw HTTP के साथ काम करना; headful या headless mode; proxy rotation भी शामिल है। दायरा काफी बड़ा है, इसलिए यह साफ समझना मददगार है कि Crawlee क्या नहीं है।
यह rendering engine नहीं है। इसका अपना browser नहीं होता। जब आपको JavaScript चलवाना होता है, Crawlee Playwright या Puppeteer को चलाता है, और वे आगे Chromium (या किसी दूसरे browser) को drive करते हैं। यह कोई hosted service भी नहीं है जिसे आप network के जरिए call करें — यह एक dependency है जिसे आप खुद install करके चलाते हैं। असल में Crawlee fetcher के ऊपर वाली layer है: crawler classes, request queue, storage, और link-following logic। इसे crawl framework की तरह समझिए, जिसके नीचे plug-in होने वाला engine slot है।
संदर्भ के लिए: जिस version को मैंने टेस्ट किया वह 3.17.0 था (released 2026-06-04), यह TypeScript में है, license Apache-2.0 है, और repo का आकार लगभग 24.6k stars था 2026-07-09 तक, apify/crawlee पर। Star count बदलते रहते हैं — जिन दो दिनों में मैं इसे देख रहा था, repo को 53 stars मिले — इसलिए इस संख्या को snapshot समझें, स्थायी तथ्य नहीं।
दो Engine: CheerioCrawler बनाम PlaywrightCrawler
यहीं पर इस design की असली उपयोगिता दिखती है, और यहीं मैंने सबसे ज्यादा समय बिताया।
CheerioCrawler HTTP वाला रास्ता है। यह raw HTML को wire के जरिए fetch करता है और उसे Cheerio से parse करता है — न browser, न JavaScript execution, न rendering। यह तेज़ भी है और सस्ता भी। PlaywrightCrawler browser वाला रास्ता है। यह असली Chromium launch करता है, JavaScript से DOM बनने तक पेज render करता है, और screenshot भी ले सकता है।
दो अलग engines, और उनकी क्षमताएँ भी अलग हैं। Crawlee का point यह है कि दोनों की shape एक जैसी है। दोनों requestHandler लेते हैं। दोनों run() expose करते हैं। दोनों enqueueLinks से links crawl करते हैं। एक engine से दूसरे पर जाना rewrite नहीं, बस class बदलना है — मैंने अपने extraction logic को byte-identical रखकर और सिर्फ crawler class बदलकर इसे verify किया।
एक बात साफ़-साफ़ कहना ज़रूरी है, क्योंकि यहीं parity खत्म होती है: content handle अलग होता है। CheerioCrawler handler के अंदर आपको $ मिलता है — एक static, पहले से parsed DOM जिसे आप jQuery की तरह query करते हैं। Browser handler में आपको live page object मिलता है। यानी queue, routing, और “यह data push करो, ये links follow करो” वाला plumbing समान रहता है, लेकिन page पढ़ने की जगह पर interface बदल जाता है। Crawlee की अपनी docs भी यही कहती हैं — shared interface को crawl operations तक सीमित रखा गया है, और content access को वही हिस्सा बताया गया है जो बदलता है।
| Engine | यह कैसे fetch करता है | JavaScript चलाता है? | मेरा test (1 dynamic page) | सबसे अच्छा किसके लिए |
|---|---|---|---|---|
CheerioCrawler | Raw HTTP + Cheerio parse | नहीं | ~0.035s | Static HTML, JSON APIs, speed |
PlaywrightCrawler | Playwright के जरिए real Chromium | हाँ | ~4.967s | JS-rendered pages, screenshots |
ये timings एक ही machine और एक ही run से हैं — benchmark नहीं, सिर्फ tradeoff का स्वरूप दिखाने के लिए। Browser path ने उसी URL पर लगभग दो orders of magnitude ज़्यादा समय लिया। Rendering की यही कीमत होती है, इसलिए इसे default के रूप में नहीं चुनते।
टेस्ट: वही URL, 0 बनाम 8/8
दावे सस्ते होते हैं। मुझे दो-engine वाली बात इसलिए भरोसेमंद लगी क्योंकि मैं इसे fail करवा सकता था, और फिर सिर्फ एक class बदलकर ठीक भी कर सकता था।
मैंने एक local dynamic fixture बनाया — एक catalog page जहाँ product cards load होने के बाद JavaScript से inject होते हैं, यानी modern web की आम स्थिति। मैंने उस पर CheerioCrawler चलाया। उसने 0 product cards लौटाए। यह bug नहीं, physics है। Cheerio ने JavaScript चलाया ही नहीं, इसलिए cards उस HTML में मौजूद ही नहीं थे जिसे उसने parse किया। फिर मैंने उसी exact URL पर PlaywrightCrawler चलाया, बाकी कुछ नहीं बदला, और उसने 8 में से 8 products render किए और proof के लिए screenshot भी लिया।
यह सिर्फ मेरे fixture की खासियत नहीं है, यह सुनिश्चित करने के लिए मैंने वही pattern एक public site पर भी चलाया — Quotes to Scrape का JavaScript demo page, जो quotes को client-side बनाता है। नतीजा फिर वही रहा: CheerioCrawler ने 0 quotes देखे, PlaywrightCrawler ने 10 recovered किए।
मैं यह साफ रखना चाहता हूँ कि इससे क्या साबित होता है। यह Crawlee के documents में लिखी बात का clean reproduction है — version 3.0 से framework ने अपने crawler types के लिए वही base class और interface साझा किया है। इसलिए यह discovery नहीं, verification है। लेकिन यही तो असली value है: marketing line “one interface, HTTP या browser” सच है, और यहाँ मेरे control वाले fixture और एक बाहरी site दोनों पर 0 से full-data तक का सबूत भी है।
HTTP Path कहाँ जीतता है
ऊपर वाला हिस्सा पढ़कर यह निष्कर्ष निकालना आसान है कि “हमेशा browser इस्तेमाल करो।” ऐसा मत कीजिए। पूरे two-engine design का मतलब यही है कि browser expensive fallback है, default नहीं।
Static content पर CheerioCrawler तेज़ और सटीक था। मेरे static catalog fixture ने 12 में से 12 products full recall के साथ दिए, pagination को enqueueLinks({ selector: '.next-page' }) से follow करते हुए, और यह सब करीब 0.155 seconds में हुआ। एक article page ने अपना title और 3 में से 3 body paragraphs दे दिए, जबकि login/subscribe/copyright जैसी boilerplate content से साफ अलग रही।
सबसे अहम बात: जिस page का data JavaScript से load होता है, उसके पीछे अक्सर एक JSON API छिपी होती है। मेरे dynamic fixture का data एक endpoint पर मौजूद था, और जब मैंने CheerioCrawler को सीधे उसी API पर भेजा, उसने 8 में से 8 products वापस निकाल लिए — बिना browser, लगभग 0.035 seconds में। वही data browser path को render करने में करीब पाँच seconds लगे थे। सीख वही पुरानी है, पर आज भी सही है: अगर underlying request reproduce हो सकती है, तो Chromium launch करने के बजाय वही करें। Crawlee आपको यह चुनाव हर crawler के हिसाब से करने देता है, framework बदले बिना।
Crawl Framework वाला हिस्सा — यही वजह है कि Crawlee सिर्फ bare browser lib से बेहतर है
अगर आपको सिर्फ एक page render करना होता, तो Crawlee की जरूरत नहीं पड़ती — आप Playwright या Puppeteer अकेले इस्तेमाल कर लेते। लेकिन bare browser library आपको crawl नहीं देती: queue, deduplication, depth control, retries — यह सब Crawlee का हिस्सा है, और यही वह भाग है जो engines से अलग है।
मैंने एक fixture root से same-hostname crawl चलाया, depth tracking के साथ enqueueLinks इस्तेमाल किया। Crawlee ने 11 pages क्रॉल किए, depths {0:1, 1:3, 2:7} के साथ — एक root, तीन pages एक hop बाहर, और सात pages दो hops बाहर — और maxRequestsPerCrawl को stop condition की तरह honor किया। RequestQueue ने bookkeeping संभाली। जब मैंने एक ऐसे page पर request भेजी जो HTTP 500 लौटाता था, Crawlee ने retry किया और फिर failure को failedRequestHandler के जरिए surface किया, न कि silently ignore किया या run crash कर दिया।
Standalone browser tool की तुलना में Crawlee के पक्ष में सबसे मजबूत तर्क यही है: crawl orchestration built-in है, और सबसे अहम बात यह है कि orchestration HTTP engine हो या browser engine — दोनों में वही रहती है। आप queue और follow logic एक बार लिखते हैं। यह अलग तय करते हैं कि कौन-सा crawler JavaScript render करेगा।
Setup और hidden browser download
Installation ज़्यादातर आसान रही, लेकिन एक trap है जो पहली बार इस्तेमाल करने वालों को जरूर पकड़ता है।
npm install crawlee playwright बिना किसी दिक्कत के चला — 0 vulnerabilities report हुईं। लेकिन PlaywrightCrawler तब तक launch नहीं होगा जब तक आप npx playwright install chromium भी नहीं चलाते, जो लगभग 81.7 MiB का Chromium binary download करता है। सिर्फ crawlee package install करने से browser download नहीं होता। अगर आप यह step छोड़कर सीधे browser crawler चलाएँगे, तो launch error मिलेगा — खासकर तब, जब आपको Playwright का packaging model पहले से पता न हो। यह Playwright का inherited behavior है, Crawlee की defect नहीं, लेकिन first-run friction point जरूर है, जिसे note करना चाहिए।
एक और operational बात: default रूप से Crawlee local storage/ directory में लिखता है। मेरे test harness ने इसे scratch temp dir में redirect किया और persistence बंद कर दी ताकि environment साफ रहे, लेकिन plain-vanilla run आपके project में storage/ folder छोड़ देगा। कोई समस्या नहीं, बस इतना जान लें ताकि वह git status में अचानक न दिखे।
संक्षेप में एक तीसरा Engine
Crawlee की parity story सिर्फ Cheerio और Playwright तक सीमित नहीं है। इसमें PuppeteerCrawler भी है, और मैंने देखा कि “same interface” का दावा वहाँ तक कितना जाता है — class और API surface level पर, live crawl के बिना।
तीनों crawler classes एक ही BasicCrawler base तक पहुँचती हैं। CheerioCrawler HttpCrawler के जरिए route होता है; PlaywrightCrawler और PuppeteerCrawler दोनों एक shared BrowserCrawler पर जाते हैं। Installed package introspect करने पर, तीनों engines के बीच 24 public methods साझा मिले — जिनमें queue और storage operations भी शामिल हैं, जिन पर पूरा design टिका है: run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop। PuppeteerCrawler और PlaywrightCrawler का public method set तो बिल्कुल identical है। Cross-engine differences सिर्फ HTTP-versus-browser seam पर हैं, और यही अपेक्षित भी है।
एक सीमा साफ़ कह देना बेहतर है: मैंने live PuppeteerCrawler crawl नहीं चलाया। puppeteer peer dependency optional थी और मेरे test pack में install नहीं थी, और उसे exercise करने का मतलब एक और browser download होता। इसलिए यहाँ Puppeteer parity structure के स्तर पर verify हुई है — same base class, same shared methods, same handler context shape — executed run से नहीं। और interface match होने के बावजूद behavior बिल्कुल एक जैसा नहीं होता: Crawlee की own guidance बताती है कि Playwright elements के लिए auto-wait करता है, जबकि Puppeteer में आपको explicit wait करना पड़ता है। यह engine trait है, Crawlee की कमी नहीं, लेकिन इसका मतलब है कि “same API” का मतलब हर handler के अंदर एक ही code path नहीं होता।
मैंने क्या टेस्ट नहीं किया
इस round में जानबूझकर कुछ चीजें छोड़ दी गईं, ताकि मेरे नतीजों को उससे बड़ा न समझ लिया जाए जितना वे हैं।
- Scale. सब कुछ छोटे fixtures और छोटे public crawls पर चला। 100–1,000 page की लंबी run नहीं हुई, इसलिए Crawlee की autoscaling या real load पर stability के बारे में कुछ नहीं कह सकता।
- Queue persistence और resume. मैंने कभी crawl को बीच में kill नहीं किया यह देखने के लिए कि crash के बाद
RequestQueueसाफ़ तरीके से resume करता है या नहीं। long jobs के लिए यह एक बड़ी capability है, लेकिन यहाँ test नहीं हुई। - Dataset और KeyValueStore export. मैंने अपने harness में JSON/CSV exports खुद लिखे। Crawlee के built-in
Dataset/KeyValueStoreexport ergonomics — जो शायद framework इस्तेमाल करने का बड़ा फायदा हैं — मैंने नहीं आज़माए। - Proxy और session pools. Crawlee proxy rotation और fingerprinting features देता है। मैं इन्हें केवल compliance और operations के संदर्भ में देखता हूँ, “anti-bot bypass” selling point के रूप में नहीं, और दोनों तरफ से stress-test नहीं किया।
और पूरे लेख में दिए गए timings single-machine, single-run हैं। वे HTTP-versus-browser cost का स्वरूप दिखाते हैं। Benchmark नहीं हैं, और मैं इन्हें वैसा quote नहीं करूँगा।
फायदे और कमियाँ
फायदे
- HTTP और browser crawling के लिए एक ही API surface — engine बदलना सचमुच class change है, और local fixture तथा public site दोनों पर 0 → full-data से verify हुआ।
- असली crawl framework:
RequestQueue,enqueueLinksके साथ depth control, retries, औरfailedRequestHandler— सिर्फ page renderer नहीं। - जब JavaScript बाधा नहीं बनता, तो HTTP extraction सटीक है (12/12 static, 3/3 article paragraphs, 8/8 via JSON API)।
- Browser path वह content वापस लाता है जो HTTP path physically नहीं देख सकता, और screenshots भी लेता है।
- Apache-2.0, TypeScript, और actively maintained।
कमियाँ
- Browser crawlers के लिए अलग से
npx playwright install chromium(~81.7 MiB) चाहिए, जोnpm install crawleeखुद नहीं करता — इसे miss करना आसान है। - Browser rendering में हर page पर वास्तविक समय लागत आती है (~5s बनाम sub-second मेरे one-page test में)।
- Plain run में default
storage/directory बनती है। - Scale, queue persistence/resume, और Dataset export ergonomics मेरे testing में prove नहीं हुए।
- Proxy और fingerprinting features का उपयोग साइट की terms और कानून के अंदर होना चाहिए — यह जिम्मेदारी है, feature नहीं जिस पर निर्भर रहा जाए।
Crawlee कब चुनें, और कब managed API
Crawlee एक खुद-से-नियंत्रित tool है, और कई teams के लिए यही सही चुनाव है। इसे तब चुनें जब आप crawler को अपने Node codebase में खुद रखना चाहते हों, एक ही project में HTTP और browser crawling मिलाकर framework न बदलना चाहते हों, और queue तथा storage पर भी आपका नियंत्रण हो। अगर आप browser fleet को चलाने और eventually scale करने में सहज हैं, तो Crawlee आपको एक साफ़, अच्छी तरह designed spine देता है जिस पर आप यह सब जोड़ सकते हैं।
दूसरा रास्ता यह है कि आपको यह infrastructure चलाना ही न पड़े। अगर Chromium instances संभालना, proxy rotation, और anti-bot handling आपके engineering समय का तरीका नहीं है, तो managed API बेहतर विकल्प है — और यहीं Thunderbit पर हमारी developer stack काम आती है। Technical users के लिए Thunderbit Chrome extension नहीं, बल्कि AI scraping API, MCP server, और CLI है। आप POST /distill call करके किसी page को साफ़, LLM-ready Markdown में बदल सकते हैं, या POST /extract के साथ JSON Schema देकर structured data वापस पा सकते हैं, और renderMode को none, basic, या full रखकर यह तय कर सकते हैं कि full browser render कब चाहिए। MCP server किसी AI agent (Claude, Cursor, और दूसरे MCP clients) को task के बीच scrape करने देता है, और CLI terminal या CI से चलता है:
वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
Developers के लिए फर्क यह है: Crawlee आपको raw material देता है — rendered HTML, parsed nodes — और pipeline आपकी होती है; managed API schema-matched structured JSON वापस देती है, जिसमें JS rendering, CAPTCHA, और anti-bot handling server-side हो जाता है। काम अलग हैं। Maximum control चाहिए और ops से दिक्कत नहीं, तो Crawlee। Browser fleet चलाए बिना data चाहिए, तो managed route। बहुत-सी teams दोनों का उपयोग करती हैं — एक bespoke crawls के लिए, और दूसरा “बस structured data दे दो” वाले मामलों के लिए। Cost का अंतर आप Thunderbit की pricing पर देख सकते हैं।
अंतिम निर्णय
क्या Crawlee इस्तेमाल करना चाहिए? हाँ — अगर आप Node या TypeScript developer हैं और एक ऐसा framework चाहते हैं जो HTTP और browser crawling दोनों को एक ही छत के नीचे लाए, साथ में असली crawl queue भी दे। दो-engine वाला वादा ही इसे चुनने की असली वजह है, और मेरे fixtures पर यह साफ़-साफ़ सही साबित हुआ: वही URL एक class swap से 0 से full data तक गया, static extraction तेज़ और सटीक रहा, और queue-plus-depth crawling ने भी दस्तावेज़ के अनुसार काम किया।
बस दो बातें ध्यान में रखें। पहली बार PlaywrightCrawler इस्तेमाल करते समय hidden browser download के लिए budget रखें, और यह न मान लें कि जिन हिस्सों को मैंने टेस्ट नहीं किया — scale, crash-resume, built-in exports — वे उतने ही अच्छे हैं जब तक आप उन्हें अपने workload पर चला न लें। अपने crawler बनाने की foundation के रूप में Crawlee एक मजबूत, अच्छी तरह engineered विकल्प है। लेकिन एक तैयार, hands-off data pipeline के रूप में यह शुरुआती कदम है, मंज़िल नहीं।
वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ Get Started Free
FAQs
क्या Crawlee free है, और इसका license क्या है?
हाँ। Crawlee open source है और Apache-2.0 license के तहत आता है, और इसे npm से install किया जाता है (npm install crawlee)। मैंने जो version टेस्ट किया वह 3.17.0 था। Browser crawlers चलाने के लिए Playwright के जरिए अलग से Chromium download करना पड़ता है, जो free है लेकिन setup में लगभग 81.7 MiB जोड़ देता है।
CheerioCrawler बनाम PlaywrightCrawler — कौन-सा इस्तेमाल करूँ?
जब data raw HTML या किसी underlying JSON API में हो, तब CheerioCrawler इस्तेमाल करें — यह बहुत तेज़ है और browser लॉन्च नहीं करता। जब content JavaScript से render होता हो, तब PlaywrightCrawler इस्तेमाल करें; इसका संकेत आपको तब मिलेगा जब HTTP path खाली परिणाम दे। मेरे tests में HTTP engine ने JS-rendered page पर 0 items दिए और browser engine ने सब कुछ निकाल लिया। क्योंकि दोनों का API एक जैसा है, switching में rewrite नहीं, सिर्फ class change लगता है।
क्या Crawlee को चलाने के लिए browser चाहिए?
सिर्फ browser crawlers के लिए। CheerioCrawler को browser की जरूरत नहीं होती। PlaywrightCrawler (और PuppeteerCrawler) के लिए browser binary चाहिए — इसे npx playwright install chromium से install करें। ध्यान रहे, सिर्फ npm install crawlee करने से browser नहीं आता, और यही सबसे common first-run gotcha है।
क्या Crawlee pagination और multi-page crawls संभाल सकता है?
हाँ, और standalone browser library की तुलना में इसे चुनने की यही एक बड़ी वजह है। enqueueLinks links को follow करता है (pagination selectors जैसे .next-page सहित), RequestQueue crawl को deduplicate और manage करता है, और आपको depth control के साथ maxRequestsPerCrawl limits भी मिलती हैं। Testing में same-hostname crawl ने depths 0–2 के बीच 11 pages चलाए, और failed requests failedRequestHandler के जरिए सामने आए।
Crawlee managed scraping API से कैसे तुलना करता है?
Crawlee self-hosted है: crawler आप लिखते और चलाते हैं, और scaling, proxies, anti-bot handling आपकी जिम्मेदारी होती है। Thunderbit जैसे managed API के distill/extract endpoints clean Markdown या schema-matched structured JSON लौटाते हैं, rendering और anti-bot handling server-side होती है, और इसे API, MCP server, और CLI के जरिए इस्तेमाल किया जा सकता है। अपना pipeline खुद नियंत्रित करना हो तो Crawlee चुनें; browser infrastructure खुद चलाना न चाहें, तो managed API बेहतर है।
