Většina lidí narazí na Crawlee ve chvíli, kdy se snaží vyřešit úplně jinou otázku: „který headless prohlížeč mám použít?“ Jenže to je špatně položená otázka — a právě Crawlee je důvod proč. Crawlee totiž není prohlížeč. Je to Node/TypeScript framework, který si prohlížeč přizve, když je potřeba, a obejde se bez něj, když potřeba není.
Strávil jsem pár dní testováním Crawlee 3.17.0 na kontrolované sadě fixture dat a několika veřejných demo webech, a to na Node v22.22.3 a macOS. Hlavní slib — jedna knihovna, jedno API, pod tím buď HTTP crawler, nebo skutečný prohlížeč — byl přesně to, co jsem chtěl otestovat nejdůkladněji. Právě tahle vlastnost totiž rozhoduje, jestli Crawlee stojí za přidání do vašeho stacku, nebo jestli je lepší sáhnout přímo po Playwright. Krátká verze: příběh o dvou enginech funguje, i když s pár poznámkami, ke kterým se dostanu.
Co Crawlee vlastně je — a co není
Crawlee se popisuje jako knihovna pro web scraping a automatizaci prohlížeče v Node.js, postavená tak, aby z ní šlo dělat spolehlivé crawlery. Oficiální позиционирование je široké: extrakce dat pro AI, LLM, RAG nebo GPT, stahování HTML, PDF, JPG, PNG i dalších souborů; podpora Puppeteer, Playwright, Cheerio, JSDOM i čistého HTTP; režim s oknem i bez okna; včetně rotace proxy. To je opravdu hodně funkcí najednou, a proto pomáhá říct i to, co Crawlee není.
Není to renderovací engine. Nemá vlastní browser. Když potřebujete spouštět JavaScript, Crawlee řídí Playwright nebo Puppeteer, a ty pak ovládají Chromium (nebo jiný browser). Zároveň to není hostovaná služba, kterou jen zavoláte přes síť — je to závislost, kterou si nainstalujete a spustíte sami. Přesněji řečeno, Crawlee je vrstva nad fetcherem: crawler třídy, request queue, storage, logika následování odkazů. Představte si ho jako crawl framework s vyměnitelným enginem pod kapotou.
Pro úplnost: verze, kterou jsem testoval, byla 3.17.0 (vydaná 2026-06-04), je napsaná v TypeScriptu, licence je Apache-2.0 a repozitář měl k 2026-07-09 zhruba 24,6 tisíce hvězdiček na apify/crawlee. Počty hvězdiček se mění — během dvou dnů mého sledování přibylo 53 — takže to berte jako momentku, ne jako pevný údaj.
Dva enginy: CheerioCrawler vs PlaywrightCrawler
Tady začíná být design skutečně zajímavý, a právě tomu jsem věnoval většinu času.
CheerioCrawler je HTTP varianta. Stahuje čisté HTML přes síť a parsuje ho pomocí Cheerio — žádný browser, žádné spouštění JavaScriptu, žádné renderování. Je rychlý a levný. PlaywrightCrawler je browserová varianta. Spustí skutečný Chromium, stránku vyrenderuje včetně všeho, co JavaScript vloží do DOM, a umí i pořizovat screenshoty.
Dva různé enginy se skutečně odlišnými možnostmi. Pointa Crawlee je v tom, že navenek vypadají stejně. Oba přijímají requestHandler. Oba mají run(). Oba procházejí odkazy pomocí enqueueLinks. Přechod z jednoho enginu na druhý je jen výměna třídy, ne přepis. Ověřil jsem si to tak, že jsem zachoval extrakční logiku byte-identicky a změnil jen to, jaká crawler třída ji obaluje.
Jeden detail je potřeba pojmenovat přesně, protože tady ta parity končí: liší se přístup k obsahu. U handleru v CheerioCrawler dostanete $ — statický, už naparsovaný DOM, nad kterým děláte dotazy jako v jQuery. U browser handleru dostanete živý objekt page. Takže fronta, routing i plumbing typu „ulož tahle data, následuj tyhle odkazy“ zůstávají stejné, ale místo, kde si stránku opravdu čtete, má jiný tvar. I dokumentace Crawlee říká totéž — sdílené rozhraní se týká crawl operací, zatímco přístup k obsahu je to, co se liší.
| Engine | Jak načítá data | Spouští JavaScript? | Můj test (1 dynamická stránka) | Nejlepší pro |
|---|---|---|---|---|
CheerioCrawler | Čisté HTTP + Cheerio parsing | Ne | ~0.035 s | Statické HTML, JSON API, rychlost |
PlaywrightCrawler | Skutečný Chromium přes Playwright | Ano | ~4.967 s | Stránky renderované přes JS, screenshoty |
Ta čísla jsou z jednoho stroje a jednoho běhu — není to benchmark, spíš ukázka poměru. Browser varianta stála na stejné URL přibližně o dva řády víc času. To je cena za renderování, a důvod, proč po ní nesaháte jako po výchozím řešení.
Test: stejná URL, 0 vs 8/8
Sliby jsou levné. Důvod, proč věřím příběhu o dvou enginech, je ten, že jsem ho dokázal rozbít — a pak opravit pouhou výměnou jedné třídy.
Postavil jsem lokální dynamickou fixture: katalogovou stránku, kde se produktové karty doplňují JavaScriptem až po načtení, tedy přesně ten typ stránky, který je dnes na webu běžný. Poslal jsem na ni CheerioCrawler. Výsledek: 0 produktových karet. To není chyba, to je fyzika. Cheerio JavaScript nespustil, takže se karty nikdy nedostaly do HTML, které parsoval. Pak jsem na úplně stejnou URL nasadil PlaywrightCrawler, nezměnil nic dalšího a dostal jsem vyrenderovaných 8 z 8 produktů a screenshot jako důkaz.
Abych si ověřil, že to není jen zvláštnost mojí fixture, otestoval jsem stejný postup i na veřejném webu — demo stránce Quotes to Scrape, která citáty vytváří na klientovi přes JavaScript. Výsledek byl stejný: CheerioCrawler viděl 0 citátů, PlaywrightCrawler vytáhl 10.
Chci být přesný v tom, co to dokazuje. Je to čistá reprodukce tvrzení, které Crawlee už dokumentuje — framework už od verze 3.0 sdílí stejnou base class i rozhraní napříč typy crawlerů. Tady tedy nejde o objev, ale o ověření. A právě to je ten důležitý přínos: marketingová věta „jedno rozhraní, HTTP nebo browser“ je skutečná, a tady máte potvrzení 0 → plná data jak na mojí vlastní fixture, tak na webu, který neovládám.
Kde HTTP cesta vyhrává
Bylo by snadné číst předchozí část jako „vždy používej browser“. Jenže tak to není. Celý smysl dvou engineů je v tom, že browser je drahá záloha, ne výchozí volba.
Na statickém obsahu byl CheerioCrawler přesný a rychlý. Můj statický katalogový fixture vrátil 12 z 12 produktů s plným pokrytím, při procházení paginace přes enqueueLinks({ selector: '.next-page' }), a to asi za 0,155 sekundy. Článková stránka vrátila název a všech 3 z 3 odstavců těla, zatímco login/subscribe/copyright boilerplate zůstaly pěkně oddělené od obsahu.
To nejdůležitější: stránka, jejíž data se načítají přes JavaScript, často má hned vedle sebe JSON API. Data mé dynamické fixture byla dostupná přes endpoint, a když jsem na ten endpoint poslal přímo CheerioCrawler, dostal jsem zpět 8 z 8 produktů — bez browseru, asi za 0,035 sekundy. Stejná data, která browser varianta renderovala skoro pět sekund. Lekce je stará, ale pořád platí: pokud můžete reprodukovat původní request, udělejte to místo spouštění Chromia. Crawlee vám dovolí volit per-crawler bez změny frameworku.
Část o crawl frameworku (důvod, proč zvolit Crawlee místo holé browser knihovny)
Kdybyste potřebovali jen vyrenderovat jednu stránku, Crawlee byste nepotřebovali — stačil by Playwright nebo Puppeteer samostatně. To, co vám čistá browser knihovna nedá, je crawl: frontu, deduplikaci, řízení hloubky, retry logiku. A právě to je část Crawlee, která už vůbec není o enginech.
Spustil jsem crawl ve stejném hostu od kořenové fixture pomocí enqueueLinks s hlídáním hloubky. Crawlee prošel 11 stránek v hloubkách {0:1, 1:3, 2:7} — jedna kořenová stránka, tři stránky o jeden hop dál a sedm stránek o dva hopy dál — a respektoval maxRequestsPerCrawl jako stop podmínku. RequestQueue se postarala o evidenci. Když jsem poslal request na stránku vracející HTTP 500, Crawlee request zopakoval a pak chybu předal přes failedRequestHandler místo toho, aby ji tiše spolkl nebo celý běh shodil.
Tohle je nejsilnější argument pro Crawlee proti samostatnému browser nástroji: orchestrace crawlu je zabudovaná a hlavně je stejná bez ohledu na to, jestli pod ní běží HTTP nebo browser. Logiku fronty a následování odkazů napíšete jednou. Zvlášť potom rozhodujete, jestli který crawler má renderovat JavaScript.
Instalace a skrytý browser download
Instalace byla většinou bez problémů, až na jednu past, do které může snadno spadnout první uživatel.
npm install crawlee playwright proběhlo čistě — bez hlášených zranitelností. Jenže PlaywrightCrawler se nespustí, dokud nezadáte i npx playwright install chromium, což stáhne Chromium binary o velikosti asi 81,7 MiB. Samotný balíček crawlee žádný browser nestáhne. Když ten krok přeskočíte a rovnou zkusíte browser crawler, narazíte na chybu při startu, která nemusí být na první pohled zřejmá, pokud neznáte balíčkovací model Playwrightu. Je to zděděné chování Playwrightu, ne chyba Crawlee, ale je to reálné tření při prvním spuštění, které stojí za zmínku.
Ještě jedna provozní poznámka: Crawlee standardně zapisuje do lokální složky storage/. Můj testovací harness to přesměroval do dočasného scratch adresáře a vypnul persistenci, aby byl výstup čistý, ale běžné spuštění vám v projektu vytvoří složku storage/. Není to problém, jen je dobré o tom vědět dřív, než se to objeví v git status.
Stručně k třetímu enginu
Parita Crawlee se neomezuje jen na Cheerio a Playwright. Existuje také PuppeteerCrawler a já jsem se podíval, jak daleko sahá tvrzení o „stejném rozhraní“ i u něj — na úrovni tříd a API, ne na živém crawlu.
Všechny tři crawler třídy vycházejí ze stejné base třídy BasicCrawler. CheerioCrawler prochází přes HttpCrawler; PlaywrightCrawler i PuppeteerCrawler jdou přes sdílený BrowserCrawler. Při introspekci nainstalovaného balíčku jsem napočítal 24 veřejných metod, které jsou sdílené napříč všemi třemi enginy, včetně operací nad frontou a storage, na kterých celý design stojí — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. PuppeteerCrawler a PlaywrightCrawler mají dokonce identickou sadu veřejných metod. Jediné rozdíly napříč enginy leží na hraně mezi HTTP a browserem, což je přesně místo, kde byste je čekali.
Je ale potřeba říct jasně i hranici: PuppeteerCrawler jsem nespouštěl živě. Peer dependency puppeteer je volitelná a v mém testovacím balíčku nebyla nainstalovaná, a její otestování by znamenalo další download browseru. Paritu s Puppeteerem jsem tedy ověřil strukturálně — stejná base class, stejné sdílené metody, stejný tvar kontextu handleru — ne vykonaným během. A i tam, kde se rozhraní shoduje, se chování uvnitř úplně neshoduje: vlastní dokumentace Crawlee uvádí, že Playwright automaticky čeká na elementy, zatímco Puppeteer vyžaduje explicitní čekání. To je vlastnost enginu, ne chyba Crawlee, ale znamená to, že „stejné API“ neznamená „stejné kód uvnitř každého handleru“.
Co jsem netestoval
Tady je to, co jsem v tomhle kole záměrně nechal stranou, abyste mé výsledky nečetli širší optikou, než odpovídá realitě.
- Škálování. Všechno běželo na malých fixturách a krátkých veřejných crawlech. Žádný dlouhý běh na 100–1 000 stránek, takže nemůžu potvrdit autoscaling ani stabilitu pod skutečnou zátěží.
- Persistenci fronty a pokračování po restartu. Nikdy jsem crawl násilně nepřerušil uprostřed, abych ověřil, jestli
RequestQueuepo pádu pokračuje čistě dál. To je klíčová funkce pro dlouhé úlohy, ale tady neotestovaná. - Export Dataset a KeyValueStore. Export JSON/CSV jsem v harnessu psal ručně. Ergonomii vestavěných exportů přes
Dataset/KeyValueStore— což je přitom jedna z hlavních výhod frameworku — jsem nezkoušel. - Proxy a session pooly. Crawlee má proxy rotaci i fingerprinting. Beru je čistě jako téma compliance a provozu, ne jako prodejní argument typu „obejití anti-bot ochrany“, a netestoval jsem je ani tak, ani onak.
A ještě jednou: všechna čísla o časech jsou z jednoho stroje a jednoho běhu. Ukazují tvar rozdílu mezi HTTP a browserem. Nejsou to benchmarky a já bych je jako benchmarky necitoval.
Klady a zápory
Klady
- Jedno API napříč HTTP i browser crawlingem — výměna engine je opravdu jen změna třídy, potvrzená přechodem 0 → plná data na lokální fixtuře i veřejném webu.
- Skutečný crawl framework:
RequestQueue,enqueueLinkss řízením hloubky, retry ifailedRequestHandler, ne jen renderer jedné stránky. - Přesná HTTP extrakce (12/12 statických položek, 3/3 odstavce článku, 8/8 přes JSON API), když JavaScript nepřekáží.
- Browser varianta umí získat obsah, který HTTP cesta fyzicky nevidí, a navíc dělá screenshoty.
- Apache-2.0, TypeScript, aktivně udržovaný projekt.
Zápory
- Browser crawleři vyžadují samostatné
npx playwright install chromium(~81,7 MiB), kterénpm install crawleeneřeší — snadno se na to zapomene. - Renderování v browseru má reálnou cenu na jednu stránku (~5 s oproti sub-sekundě v mém jednom testu).
- Při běžném spuštění se standardně vytvoří složka
storage/. - Škálování, pokračování po pádu a ergonomie exportu Datasetu jsem v testu nepotvrdil.
- Proxy a fingerprinting musíte používat v souladu s podmínkami webu i zákonem — je to odpovědnost, ne zkratka.
Kdy sáhnout po Crawlee a kdy po managed API
Crawlee je nástroj typu „postav si to sám“, a pro spoustu týmů je to přesně správná volba. Zvolte ho, když chcete mít crawler ve vlastním Node kódu, míchat HTTP a browser crawling v jednom projektu bez přepínání frameworků a mít pod kontrolou frontu i storage. Pokud vám nevadí provozovat a časem škálovat browserovou farmu, Crawlee vám k tomu dá čistou a dobře navrženou páteř.
Druhá cesta znamená neprovozovat tu infrastrukturu vůbec. Pokud nechcete trávit inženýrský čas hlídáním instancí Chromia, rotací proxy a anti-bot logikou, alternativou je managed API — a přesně tam zapadá náš vlastní vývojářský stack na Thunderbit. Pro technické uživatele Thunderbit není Chrome extension; je to AI scraping API, MCP server a CLI. Voláte POST /distill, když chcete stránku převést na čistý Markdown připravený pro LLM, nebo POST /extract s JSON Schema, abyste dostali strukturovaná data zpět, a k tomu si zvolíte renderMode none, basic nebo full podle toho, kdy má smysl plné vykreslení browserem. MCP server umožní AI agentovi (Claude, Cursor a dalším MCP klientům) scrapovat i během úlohy a CLI běží z terminálu nebo v CI:
Vyzkoušet Thunderbit pro extrakci webových dat
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
Rozdíl, který je pro vývojáře podstatný: Crawlee vám dá surový materiál — vyrenderované HTML, parsované nody — a pipeline je na vás; managed API vám vrátí strukturované JSON odpovídající schématu, přičemž renderování JS, CAPTCHA i anti-bot řeší serverová strana. Každé se hodí na něco jiného. Když chcete maximum kontroly a nevadí vám provoz, Crawlee. Když chcete data bez browserové farmy, zvolte managed cestu. Spousta týmů nakonec používá oboje: jedno na specifické crawly a druhé na případy typu „prostě mi dejte strukturovaná data“. Rozdíl v ceně si můžete prohlédnout na ceníku Thunderbit.
Verdikt
Máte použít Crawlee? Ano — pokud jste Node nebo TypeScript vývojář a chcete jeden framework, který pokrývá HTTP i browser crawling a přitom pod sebou má skutečnou crawl frontu. Slib dvou engineů je hlavní důvod, proč po něm sáhnout, a v mých testech obstál: stejná URL přešla z 0 na plná data jen výměnou třídy, statická extrakce byla přesná a rychlá a crawlování podle fronty i hloubky fungovalo přesně podle dokumentace.
Jen do toho jděte s dvěma věcmi v hlavě. Poprvé při použití PlaywrightCrawler počítejte se skrytým downloadem browseru a nepředpokládejte, že části, které jsem netestoval — škálování, obnova po pádu, vestavěné exporty — fungují stejně dobře jako to, co jsem ověřil, dokud si je nespustíte na vlastním workloadu. Jako základ pro vlastní crawler je Crawlee silný a dobře navržený kus inženýrství. Jako hotová, zcela bezobslužná datová pipeline je to startovní bod, ne cíl.
Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free
Často kladené otázky
Je Crawlee zdarma a pod jakou licencí je vydané?
Ano. Crawlee je open source pod licencí Apache-2.0 a instaluje se z npm (npm install crawlee). Verze, kterou jsem testoval, byla 3.17.0. Pro browser crawleři je navíc potřeba samostatně stáhnout Chromium přes Playwright, což je také zdarma, ale do instalace přidá zhruba 81,7 MiB.
CheerioCrawler vs PlaywrightCrawler — který mám použít?
Použijte CheerioCrawler, když jsou data v syrovém HTML nebo v podkladovém JSON API — je výrazně rychlejší a nikdy nespouští browser. PlaywrightCrawler použijte tehdy, když je obsah vyrenderovaný JavaScriptem, což poznáte podle toho, že HTTP cesta vrací prázdné výsledky. V mých testech HTTP engine na JS-renderované stránce vrátil 0 položek a browser engine vrátil všechno. Protože sdílejí stejné API, přechod je změna třídy, ne přepis.
Potřebuje Crawlee k běhu browser?
Jen browser crawleři. CheerioCrawler žádný browser nepotřebuje. PlaywrightCrawler (a PuppeteerCrawler) vyžadují browser binary — nainstalujete ho přes npx playwright install chromium. Pozor na to, že samotné npm install crawlee browser nestáhne; to je nejběžnější první past.
Umí Crawlee pagination a vícestránkové crawly?
Ano, a právě proto ho mnoho lidí volí místo samostatné browser knihovny. enqueueLinks následuje odkazy včetně selektorů pro pagination, jako je .next-page, RequestQueue se stará o deduplikaci a řízení crawlu a máte k dispozici hloubkové limity i maxRequestsPerCrawl. V testu crawl na stejném hostu prošel 11 stránek v hloubkách 0–2 a neúspěšné requesty skončily přes failedRequestHandler.
Jak si Crawlee stojí proti hostovanému scraping API?
Crawlee je self-hosted: crawler píšete a provozujete vy, a také si nesete škálování, proxy i anti-bot logiku. Managed API, jako je Thunderbit distill/extract, vrací čistý Markdown nebo strukturovaný JSON odpovídající schématu, přičemž renderování i anti-bot řeší serverová strana a vše je dostupné přes API, MCP server a CLI. Zvolte Crawlee, pokud chcete maximální kontrolu nad vlastním pipeline; zvolte managed API, pokud nechcete provozovat a škálovat browser infrastrukturu sami.
