Recenze Crawlee: Quotes to Scrape v HTTP vrátilo 0, v Chromiu 10

To, co dělá Crawlee užitečným, je jeho orchestrace procházení, která umí jak HTTP parsing, tak spuštění v prohlížeči. Stejná URL tak může vrátit různé výsledky podle zvoleného crawleru a podmínky připravenosti.

Na veřejné stránce Quotes to Scrape JS našel CheerioCrawler 0 cílových citátů, zatímco PlaywrightCrawler po čekání na .quote našel 10. Životní cyklus crawlování je podobný, ale nešlo o jednoduchou záměnu jedné třídy za druhou: Cheerio handler používal $, zatímco Playwright handler pracoval s page, explicitním čekáním a extrakcí přímo v prohlížeči.

Co Crawlee vlastně je

Crawlee (projekt apify/crawlee, verze 3.17.0) je knihovna pro web scraping a automatizaci prohlížeče pro Node.js a TypeScript. Podporuje HTTP crawling postavený na Cheerio nebo JSDOM a browser crawling postavený na Playwright nebo Puppeteer. Projekt je pod licencí Apache-2.0; před nasazením si zkontrolujte povinnosti týkající se notice a atribuce.

Důležitý mentální model je oddělit „získat stránku“ od „přečíst stránku“. Jedna cesta stáhne syrové HTML a nespouští JavaScript. Druhá spustí Chromium a umí vykonat skripty stránky, ale stejně potřebuje vhodnou podmínku připravenosti a může minout obsah, který je navázaný na interakci, načítá se lazy-loadem, je ukrytý ve shadow DOM, selhal přes API, nebo je blokovaný bot ochranou. Crawlee pro tyto cesty nabízí odpovídající životní cyklus, ne zaměnitelné DOM primitivy.

To je věc, kterou se vyplatí pochopit ještě před napsáním jediného selektoru, protože právě volba mezi těmito dvěma enginy rozhodne, jestli váš scraper na daném webu vrátí data, nebo prázdný výsledek.

Klíčové vlastnosti: dva enginy, jedno API

CheerioCrawler stáhne HTML a parsuje ho pomocí Cheerio; PlaywrightCrawler ovládá Chromium a umí dělat screenshoty. Oba používají requestHandler, mají run() a sdílejí koncepty jako fronty a objevování odkazů. Rozdíly jsou ale v kontextu handleru: testovaná cesta přes Cheerio extrahovala pomocí $, zatímco browser cesta používala page, waitForSelector a $$eval. Fronta i životní cyklus mohou zůstat známé, ale extrakční kód může potřebovat adaptér nebo úplný přepis.

Pod tím vším Crawlee dodává infrastrukturu, kterou reálný crawl potřebuje. RequestQueue spravuje frontu URL k navštívení, deduplikuje je a sleduje, co už bylo hotové. enqueueLinks nachází a zařazuje nové URL (s filtrem podle selektoru a stejné domény), takže crawl může sám větvit dál. Dataset ukládá nasbírané záznamy pro export. Ve výchozím nastavení Crawlee všechno ukládá do lokální složky storage/ na disk — je to praktické pro pokračování v běhu, a zároveň mírně otravné, když poprvé narazíte na storage/, kterou jste si sami nevyžádali (můj harness to přesměroval do dočasné složky a vypnul persistenci, aby byl test čistý).

Ty jednotlivé části samy o sobě nejsou ničím výjimečné. Pointa je, že jsou sdílené mezi oběma enginy, takže fronta, objevování odkazů i dataset fungují stejně, ať crawl běží přes HTTP, nebo přes prohlížeč. Naučíte se jedno API a získáte dvě strategie načítání.

Nastavení: prohlížeč se instaluje zvlášť

V testované instalaci nebyl po instalaci balíčků k dispozici spustitelný soubor Chromia.

npm install crawlee playwright proběhlo bez problémů — 85 balíčků, 0 zranitelností, žádné drama. Pokud tím skončíte a spustíte CheerioCrawler, vše funguje, protože HTTP crawling browser nepotřebuje.

V tomhle prostředí bylo potřeba Chromium doinstalovat zvlášť přes npx playwright install chromium; bez toho PlaywrightCrawler nedokázal nastartovat. Pozorovaná velikost browser payloadu byla zhruba 82 MiB, ale původní poznámky už neuchovaly, jestli šlo o přenosovou nebo diskovou velikost. Je to pozorování specifické pro konkrétní stroj, ne pevná vlastnost produktu. Dokumentace i chování balíčků se mohou měnit, takže tento článek netvrdí, že by ta absence byla univerzální nebo trvale nedokumentovaná.

Testované nastavení si tedy naplánujte ve dvou krocích: nejdřív nainstalujte Node balíčky, potom browser, který používá Playwright větev. Vždy znovu ověřte aktuální postupy instalace Crawlee a Playwright pro verze a platformu, na které budete nasazovat.

Praktický test: stejná stránka, dvě hodně rozdílné odpovědi

Jádro testu poslalo stejný JavaScriptem rendrovaný fixture přes oba crawlery. URL i cílová pole byla stejná; extrakční primitiva ne.

Na lokálním fixture vrátil CheerioCrawler 0 cílových karet, protože v raw HTML vůbec nebyly. PlaywrightCrawler počkal na #dynamic-products article.product-card, poté vrátil všech 8 očekávaných karet a pořídil screenshot. Ten výsledek potvrzuje úplnost na úrovni fixture pro zvolená pole po daném čekání; neznamená, že browser uvidí každý možný stav stránky. Syrové soubory i screenshot jsou v benchmark repozitáři.

Na veřejné stránce Quotes to Scrape JS našel CheerioCrawler 0 cílových citátů, zatímco PlaywrightCrawler před extrakcí počkal na .quote a našel 10. To potvrzuje stejnou hranici mezi HTTP a browser cestou i na veřejném cíli, přičemž třída crawleru, kontext handleru, podmínka čekání i extrakční primitivum se mezi oběma větvemi liší.

Užitečný závěr je užší: ověřte požadovaná pole po HTTP cestě a teprve když je raw response neobsahuje, přepněte na browser crawler. Browser handler navíc musí čekat na podmínku navázanou na tato pole.

HTTP větev na kontrolovaných statických katalozích a article fixturech vrátila všechna očekávaná data, dekódovala všech osm očekávaných položek z přímé JSON odpovědi, prošla 11stránkový bounded graf a jednu odpověď 500 směrovala do failedRequestHandler. To jsou samostatné kontroly schopností, ne jedno číselné skóre přesnosti. Pro veřejnou stránku Books to Scrape vrátil zadaný selektor jako smoke test 20 produktů.

Úplné časování a čísla pro jednotlivé testy jsou v results/crawlee-test-summary.json.

A teď poctivá upozornění, protože jeden běh na jednom stroji má svoje limity a nebudu předstírat opak. Tohle jsou časy, ne benchmarky — jeden stroj, každý test jednou, takže vyšší cenu browser cesty na stránku berte jako „výrazně pomalejší než sub-second Cheerio běhy“, ne jako publikované číslo. A je tu řada věcí, které jsem v tomhle průchodu netestoval: rotace proxy, session pools, velké běhy v rozsahu stovek až tisíců stránek, persistenci RequestQueue a pokračování po pádu, engine Puppeteer a ergonomii exportů Dataset/KeyValueStore (exporty jsem tu psal ručně). Dvěma enginům a přesnosti na úrovni fixture věřit můžu. Škálování ani anti-blocking chování ale nepotvrdím, a proto to netvrdím.

Co je sdílené a co se musí změnit

Společný základ je orchestrace crawlu. Obě crawler třídy přijímají requestHandler a nabízejí run(). Fronty, metadata requestů, objevování odkazů, chybové hooky i storage koncepty lze konzistentně organizovat kolem obou výkonnostních cest. Tím se snižuje množství infrastruktury, které se tým musí znovu učit ve chvíli, kdy jeden cíl potřebuje browser.

Přístup k samotné stránce ale společný není. Handler CheerioCrawler dostává přístup orientovaný na Cheerio, například $, a může pracovat s response body bez browseru. Testovaný handler PlaywrightCrawler dostává page; čeká na selektor a provádí evaluaci nad browser DOM. I když oba handlery vrátí stejný datový formát, dostanou se k němu přes odlišná API. Znovupoužitelný adaptér by mohl část rozdílu skrýt, ale tenhle harness žádný neimplementoval ani neukazoval.

Tohle rozlišení je důležité i pro odhady. Změna třídy crawleru může zachovat frontu, dataset i politiku URL, ale selektory, readiness checks, screenshoty, interakční kroky i error handling se stejně mohou změnit. Článek proto považuje za ověřený benefit „sdílenou crawl infrastrukturu“ a odmítá tvrzení o „migraci na jeden řádek“ jako nepodložený slib.

Praktický postup výběru enginu

HTTP cestu použijte jako první, když vrácené HTML nebo přímá JSON odpověď obsahuje požadovaná pole. Definujte kontrakt úplnosti — povinné klíče, minimální počet položek nebo cílový selektor — a při nesplnění failujte explicitně. Prázdné pole není důkazem, že stránka žádná data nemá; v těchto dvou JavaScriptových případech znamenalo jen to, že zvolená reprezentace neobsahovala cílové prvky.

Když je spuštění opravdu potřeba, předejte ten typovaný failure browser handleru. V tomto harnessu lokální stránka čekala na #dynamic-products article.product-card, zatímco veřejná stránka s citáty čekala na .quote. Tyto podmínky jsou součástí kontraktu extrakce. Obecný load event by neprokázal, že aplikacní data dorazila, a test nepodporuje univerzální pravidlo čekání.

Po eskalaci držte výstupní schéma stabilní, i když se DOM primitiva liší. Ukládejte, který engine výsledek vytvořil, která podmínka připravenosti proběhla a zda prošla validace povinných polí. Díky tomu je fallback z HTTP do browseru pozorovatelný a nemění se tiše chybějící pole na přijaté záznamy.

A nakonec berte instalaci browseru a jeho provozní náklady jako vstupy do nasazení. Pozorování kolem 82 MiB má smysl jen jako lokální řádová informace; v vašem prostředí změřte přesnou verzi browseru, platformu, chování cache a dopad image. Rotace proxy, sessiony, persistence, recovery po pádu i dlouhodobá souběžnost potřebují vlastní testy, než z tohoto fixture uděláte základ pro produkční rozhodnutí.

Klady a zápory

Klady:

• HTTP a browser crawlery sdílejí životní cyklus, ale zachovávají engine-specifické kontexty extrakce.
• HTTP extrakce na statických katalozích, článcích a JSON API fungovala s přesností 1.0.
• Sdílená infrastruktura pro oba enginy: RequestQueue, enqueueLinks s řízením hloubky, Dataset.
• Browser větev spustila skripty fixture a získala všechna očekávaná cílová data ve dvou JS renderovaných testech.
• Čisté zpracování chyb — HTTP 500 se objevil bez pádu aplikace.
• Licence Apache-2.0; downstream uživatelé by si měli zkontrolovat notice a povinnosti atributace.

Zápory:

• V testovaném prostředí potřeboval browser engine samostatnou instalaci Chromia; bez ní PlaywrightCrawler nenaběhl.
• HTTP cesta neumí zobrazit cílové prvky, které v raw HTML chybí; bez validace úplnosti to může vypadat jako platný prázdný výsledek.
• Browser cesta přidává další binárku a v tomto běhu i vyšší lokální cenu na stránku; velikost i časování se liší podle buildu a platformy.
• Výchozí běhy nechávají na disku složku storage/.
• Jen Node/TypeScript — pokud jedete v Pythonu, nepomůže vám.

Pro koho je to vhodné — a kdo by se tomu měl vyhnout

Crawlee sedne týmům v Node nebo TypeScriptu, které potřebují HTTP i browser crawling pod sdílenými koncepty fronty a životního cyklu. Praktický postup je zkusit HTTP crawler, validovat požadovaná pole a typizovaný failure úplnosti předat browser handleru s readiness podmínkou specifickou pro cíl. Kód handleru pro DOM je specifický pro engine, i když jsou fronta a objevování odkazů sdílené.

Nastavte očekávání na správnou úroveň, nebo hledejte jinde, pokud jste Python firma (Crawlee je Node/TS — existuje samostatný Python port, ale tento testoval Node knihovnu), pokud jsou všechny vaše cíle statické a chcete raději lehčí jednoúčelový HTTP scraper, nebo pokud potřebujete ověřené chování ve velkém měřítku — rotaci proxy, session pooly, pokračování po pádu — což tenhle praktický test nepokrýval. A pokud sáhnete po PlaywrightCrawler, nainstalujte nejdřív Chromium, jinak prostě neběží.

Alternativy, včetně toho, kam zapadá Thunderbit

Crawlee je open-source software, který si sami provozujete a spravujete. Nemá vendor fee za každý call, ale browser compute, bandwidth, proxy, storage, observability i engineering jsou provozní náklady. Crawler, browser binárku, storage state i logiku readiness máte ve vlastní režii.

Související recenze: recenze scrapy-playwright.

Managed extraction service přesouvá odpovědnost za získání dat a úpravu schématu na dodavatele. My vyvíjíme Thunderbit, ale na těchto fixturech jsme ho nespouštěli, takže tento článek nenabízí žádné srovnání kvality, latence, parity funkcí ani ceny. Rozhodující otázka je, zda váš tým chce kontrolu v procesu Crawlee, nebo servisní hranici s účtováním za request.

Související benchmark recenze: kompletní srovnání open-source scraperů, Playwright vs Puppeteer na stejných stránkách a recenze Scrapy bez replaye přes browser.

Vyzkoušet Thunderbit pro extrakci webových dat

Verdikt

Crawlee je silný kandidát pro týmy v Node nebo TypeScriptu, které chtějí sdílenou orchestrace crawlu pro HTTP i browser execution. Testované handlery nebyly zaměnitelné: přechod na Playwright vyžadoval page, čekání na cílový selektor a extrakci přímo v browseru. Proxy, sessiony, persistence, resume i chování ve velkém měřítku zůstávají otevřené otázky.

Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free

Často kladené otázky

Jaký je skutečný rozdíl mezi dvěma crawlerami v Crawlee? CheerioCrawler stahuje HTML přes HTTP a nespouští JavaScript. PlaywrightCrawler ovládá Chromium a umí spouštět skripty stránky a dělat screenshoty, ale za vyšší lokální cenu na stránku. Sdílí koncepty životního cyklu, ale ne totožné kontexty handleru: v tomto harnessu se na HTTP cestě používalo $, zatímco Playwright větev používala page, čekání na cílový selektor a evaluaci v browseru.

Proč PlaywrightCrawler po instalaci Crawlee neběží? V testovaném prostředí samotná instalace balíčku neposkytla spustitelný browser. Instalace Chromia přes npx playwright install chromium problém s launchí vyřešila. Pozorovaný objem byl zhruba 82 MiB, ale původní měření neuchovalo, jestli šlo o přenosovou nebo diskovou velikost, takže si to pro svoji platformu a build přeměřte.

Umí CheerioCrawler scrapovat JavaScriptem rendrované stránky? JavaScript stránky sám nespouští. Může ale požádat o dostupný JSON endpoint, který používá klient, jak ukazuje fixture s přímou odpovědí. Když požadovaná data vznikají až po spuštění browseru, použijte browser crawler a readiness podmínku navázanou na tato pole.

Je Crawlee přesné pro běžnou statickou extrakci? Na kontrolovaných fixturech vrátilo 12/12 očekávaných produktů z katalogu, 3/3 očekávaných odstavců článku a 8/8 očekávaných položek z přímé JSON odpovědi. To jsou kontroly úplnosti fixture, ne obecné skóre přesnosti pro netestované weby.

Je Crawlee zdarma pro komerční použití? Je vydáno pod licencí Apache-2.0. Aktuální licenci si ověřte v repozitáři a projděte si povinnosti notice a atribuce pro vaši distribuci.

Před nasazením do produkce otestujte části, které tento fixture nechává otevřené: opakovanou souběžnost na reprezentativních stránkách, chování proxy a session, obnovu perzistentní fronty po přerušení, úklid browser procesu a export datasetu při chybě. S těmito výsledky uchovejte i použitou verzi browseru a instalační cestu. Obě třídy crawlerů sice snižují rozdíly v orchestrace, ale neodstraňují potřebu engine-specifických readiness checks, rozpočtů na zdroje a operativního zpracování selhání.