Useimmat törmäävät Crawleeen yrittäessään ratkaista ihan eri kysymystä: "minkä headless-selaimen pitäisi käyttää?" Se on väärä kysymys, ja Crawlee on syy siihen miksi. Se ei ole selain. Se on Node/TypeScript-kehys, joka kytkee selaimen käyttöön silloin kun sitä tarvitset ja ohittaa sen silloin kun et.
Ajoin Crawlee 3.17.0:aa parin päivän ajan hallitulla joukolle testiaineistoja ja muutamille julkisille demo-sivustoille Node v22.22.3:lla ja macOS:ssä. Otsikkotason lupaus — yksi kirjasto, yksi API, taustalla joko HTTP-crawler tai oikea selain — oli juuri se, mitä halusin testata kunnolla, koska juuri siitä riippuu, onko Crawlee lisäyksen arvoinen osa työkalupakkia vai pitäisikö tarttua suoraan Playwrightiin. Lyhyt vastaus: kahden moottorin malli pitää, vaikka muutama huomio pitääkin tehdä.
Mitä Crawlee oikeastaan on — ja mitä se ei ole
Crawlee kuvaa itseään Node.js:lle rakennetuksi web-scraping- ja selainautomaatiokirjastoksi, jonka tarkoitus on tehdä luotettavien crawlerien rakentamisesta helpompaa. Virallinen kuvaus on laaja: dataa AI:lle, LLM:ille, RAG:lle tai GPT:ille; HTML-, PDF-, JPG-, PNG- ja muiden tiedostojen lataus; tuki Puppeteerille, Playwrightille, Cheerolle, JSDOM:lle ja suoralle HTTP:lle; headful- tai headless-ajo; sekä valmiiksi mukana tuleva proxy-kierrätys. Kattaus on iso, joten on hyödyllistä sanoa myös, mitä Crawlee ei ole.
Se ei ole renderöintimoottori. Sillä ei ole omaa selainta. Kun JavaScript pitää ajaa, Crawlee ohjaa Playwrightia tai Puppeteeria, jotka puolestaan ohjaavat Chromiumia (tai muuta selainta). Se ei myöskään ole verkkopalvelu, jota kutsut API:n yli — se on riippuvuus, jonka asennat ja ajat itse. Tarkemmin sanottuna Crawlee on fetcherin yläpuolella oleva kerros: crawler-luokat, request queue, tallennus ja linkkien seuraamiseen liittyvä logiikka. Ajattele sitä crawl-työkaluna, jonka alla on vaihdettava moottori.
Vertaillakseni käytin versiota 3.17.0 (julkaistu 2026-06-04), se on TypeScriptillä tehty, lisenssi on Apache-2.0, ja repo oli noin 24,6k tähden tasolla 2026-07-09 mennessä osoitteessa apify/crawlee. Tähtimäärä elää jatkuvasti — repo sai 53 uutta tähteä kahden päivän aikana, kun seurasin sitä — joten luku kannattaa tulkita hetkenä, ei pysyvänä totuutena.
Kaksi moottoria: CheerioCrawler vs PlaywrightCrawler
Tässä kohtaa suunnittelu todella näyttää hyötynsä, ja juuri tämän parissa vietin suurimman osan ajasta.
CheerioCrawler on HTTP-puoli. Se hakee raaka-HTML:n verkosta ja parsii sen Cheerion avulla — ei selainta, ei JavaScriptin ajoa, ei renderöintiä. Se on nopea ja kevyt. PlaywrightCrawler on selainpuoli. Se käynnistää oikean Chromiumin, renderöi sivun mukaan lukien kaiken sen JavaScriptin, joka rakentaa DOMin, ja voi jopa ottaa kuvakaappauksia.
Kaksi eri moottoria, joilla on aidosti eri kyvyt. Crawleen pointti on, että ne näyttävät samanlaisilta ulospäin. Molemmat käyttävät requestHandleria. Molemmissa on run(). Molemmat seuraavat linkkejä enqueueLinks-kutsulla. Siirtyminen moottorista toiseen on luokan vaihto, ei uudelleenkirjoitus — varmistin tämän pitämällä poimintalogiikan byte-identtisenä ja vaihtamalla vain sen, minkä crawler-luokan ympärille se kiedottiin.
Yksi tarkkuutta vaativa kohta, koska juuri siinä parity loppuu: sisällön käsittely eroaa. CheerioCrawler-handlerissa saat $-olion — staattisen, jo parsitun DOMin, jota kysellään kuin jQueryllä. Selainhandlerissa saat elävän page-olion. Siis queue, reititys ja "pistä tämä data talteen, seuraa nuo linkit" -putkisto pysyy samana, mutta kohta jossa oikeasti luet sivua, näyttää erilaiselta. Crawleen omat dokumentit sanovat samaa: yhteinen rajapinta koskee crawl-toimintoja, ja sisällön lukeminen on se osa, joka vaihtelee.
| Moottori | Miten se hakee | Ajaa JavaScriptin? | Oma ajoni (1 dynaaminen sivu) | Paras käyttöön |
|---|---|---|---|---|
CheerioCrawler | Raaka HTTP + Cheerio-parsaus | Ei | ~0.035 s | Staattinen HTML, JSON-API:t, nopeus |
PlaywrightCrawler | Oikea Chromium Playwrightin kautta | Kyllä | ~4.967 s | JavaScriptillä renderöidyt sivut, kuvakaappaukset |
Nuo ajat ovat yhdeltä koneelta ja yhdestä ajosta — eivät benchmark, vaan kuva tradeoffista. Selainpolku maksoi samalla URL:lla noin kaksi suuruusluokkaa enemmän aikaa. Se on renderöinnin hinta, ja juuri siksi siihen ei kannata tarttua oletuksena.
Testi: sama URL, 0 vs 8/8
Lupaukset ovat halpoja. Siksi luotan kahden moottorin tarinaan: sain sen ensin epäonnistumaan ja sitten korjattua vaihtamalla vain yhden luokan.
Rakensin paikallisen dynaamisen testisivun — katalogisivun, jossa tuotekortit injektoidaan JavaScriptillä latauksen jälkeen, eli juuri sellaisen sivun, josta on tullut modernin verkon perusmalli. Kohdistin CheerioCrawlerin siihen. Tulos oli 0 tuotekorttia. Se ei ole bugi; se on fysiikkaa. Cheerio ei koskaan ajanut JavaScriptiä, joten kortit eivät koskaan päätyneet HTML:ään, jota se parsii. Sitten kohdistin PlaywrightCrawlerin täsmälleen samaan URL:iin, en muuttanut mitään muuta, ja se renderöi 8/8 tuotetta ja otti kuvakaappauksen todisteeksi.
Varmistaakseni, ettei kyse ollut vain omasta testisivustani, toistin saman julkisella sivulla — Quotes to Scrape -JavaScript-demossa, joka rakentaa sitaatit client-puolella. Sama lopputulos samaan suuntaan: CheerioCrawler näki 0 lainausta, PlaywrightCrawler palautti 10.
Haluan olla tarkka siitä, mitä tämä todistaa. Se on puhdas vahvistus väitteelle, jonka Crawlee jo dokumentoi — framework on jakanut saman base classin ja rajapinnan crawler-tyyppien välillä versiosta 3.0 lähtien. Kyse on siis validoinnista, ei uudesta löydöksestä. Mutta juuri siinä piilee arvo: markkinointilause "yksi rajapinta, HTTP tai selain" on totta, ja tässä on 0 → täydet tiedot -todiste sekä omasta fixturestä että sivustolta, jota en itse hallitse.
Missä HTTP-polku voittaa
Olisi helppoa lukea edellinen osio niin, että "käytä aina selainta". Älä tee niin. Koko kahden moottorin mallin pointti on siinä, että selain on kallis vararatkaisu, ei oletus.
Staattisessa sisällössä CheerioCrawler oli tarkka ja nopea. Staattinen katalogifixture palautti 12/12 tuotetta täydellä recallilla ja seurasi paginointia enqueueLinks({ selector: '.next-page' }) -kutsulla noin 0,155 sekunnissa. Yhdestä artikkelista saatiin otsikko ja kaikki 3/3 kappaletta, samalla kun login/subscribe/copyright-tekstit erottuivat siististi itse sisällöstä.
Yksi kohta kannattaa painaa mieleen: sivu, jonka data ladataan JavaScriptillä, sisältää usein taustalla myös JSON-API:n. Omani dynaamisen testisivun data eli endpointissa, ja kun kohdistin CheerioCrawlerin suoraan siihen API:in, se palautti 8/8 tuotetta — ilman selainta, noin 0,035 sekunnissa. Sama data, jonka selainpolku renderöi lähes viidessä sekunnissa. Oppi on vanha mutta pitää yhä paikkansa: jos pystyt toistamaan taustapyynnön, tee se sen sijaan että käynnistät Chromiumin. Crawlee antaa sinun valita tämän crawler-kohtaisesti vaihtamatta frameworkia.
Crawl-työkalun varsinainen hyöty (syy valita Crawlee pelkän selainkirjaston sijaan)
Jos tarvitsisit vain yhden sivun renderöinnin, et tarvitsisi Crawleea — käyttäisit Playwrightia tai Puppeteeria sellaisenaan. Pelkkä selainkirjasto ei kuitenkaan tarjoa crawl-prosessia: jonoa, deduplikointia, syvyyden hallintaa, retryjä. Juuri se on Crawleen osa, joka ei liity moottoreihin lainkaan.
Ajoin saman hostnameen sisällä etenevän crawlin fixture-juuresta käyttäen enqueueLinksiä ja syvyyden seurantaa. Crawlee kävi läpi 11 sivua syvyyksillä {0:1, 1:3, 2:7} — yksi juuri, kolme sivua yhden hypyn päässä, seitsemän sivua kahden hypyn päässä — ja noudatti maxRequestsPerCrawl-rajaa pysäytysehtona. RequestQueue hoiti kirjanpidon. Kun kohdistin pyynnön sivulle, joka palautti HTTP 500:n, Crawlee yritti uudelleen ja lopulta toi virheen näkyviin failedRequestHandlerin kautta sen sijaan, että se olisi niellyt sen hiljaa tai kaatanut ajon.
Tämä on vahvin argumentti Crawleen puolesta verrattuna erilliseen selaintyökaluun: crawl-orchestration on sisäänrakennettu, ja mikä tärkeintä, sama orchestration toimii riippumatta siitä, onko taustalla HTTP vai selain. Kirjoitat queue- ja linkinseurantalogistiikan kerran. Päätät erikseen, renderöikö kukin crawler JavaScriptin vai ei.
Asennus ja piilossa oleva selaimen lataus
Asennus oli pääosin kivuton, mutta siinä on yksi ansa, joka puree ensikertalaisia.
npm install crawlee playwright meni läpi siististi — ei haavoittuvuuksia. Mutta PlaywrightCrawler ei käynnisty ennen kuin ajat myös npx playwright install chromium, joka lataa noin 81,7 MiB:n Chromium-binaarin. Pelkkä crawlee-paketin asennus ei hae selainta. Jos ohitat tämän vaiheen ja hyppäät suoraan selaincrawleriin, saat launch-virheen, joka ei ole itsestään selvä, ellet jo tunne Playwrightin pakkausmallia. Tämä on Playwrightin periytyvä toimintatapa, ei Crawlee-bugi, mutta se on aidosti huomionarvoinen ensimmäisen ajon kitkakohta.
Yksi operatiivinen huomio vielä: oletuksena Crawlee kirjoittaa paikalliseen storage/-hakemistoon. Oma testiharnessini ohjasi tämän erilliseen temp-hakemistoon ja poisti pysyvän tallennuksen, jotta ympäristö pysyi siistinä, mutta tavallinen ajo jättää storage/-kansion projektiin. Ei ongelma, mutta hyvä tietää ennen kuin se ilmestyy git status -listalle.
Kolmas moottori lyhyesti
Crawleen parity-tarina ei rajoitu Cheerioon ja Playwrightiin. Mukana on myös PuppeteerCrawler, ja tarkistin, kuinka pitkälle "sama rajapinta" -väite ulottuu siihen asti — luokka- ja API-tasolla, ei live-crawlin kautta.
Kaikki kolme crawler-luokkaa johtavat samaan BasicCrawler-base classiin. CheerioCrawler kulkee HttpCrawlerin kautta; PlaywrightCrawler ja PuppeteerCrawler puolestaan jakavat yhteisen BrowserCrawler-kerroksen. Asennetun paketin introspektio osoitti, että 24 julkista metodia on yhteisiä kaikille kolmelle moottorille, mukaan lukien koko suunnittelun kannalta olennaiset queue- ja storage-operaatiot — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. PuppeteerCrawler ja PlaywrightCrawler itse asiassa paljastavat identtisen julkisen metodijoukon. Ainoat moottorien väliset erot ovat juuri HTTP- ja selainrajapinnan kohdalla, mikä on täsmälleen se paikka, jossa niiden kuuluukin olla.
Rajaus kannattaa sanoa suoraan: en ajanut live-PuppeteerCrawler-crawlia. puppeteer-peer dependency on valinnainen eikä kuulunut testipakettiini, ja sen ajaminen olisi tarkoittanut vielä yhtä selaimen latausta. Siksi Puppeteer-pariteetti on tässä vahvistettu rakenteellisesti — sama base class, samat jaetut metodit, sama handler-contextin muoto — ei suoritetulla ajolla. Ja vaikka rajapinta täsmää, käytös konepellin alla ei ole täysin sama: Crawleen oma ohjeistus huomauttaa, että Playwright odottaa elementtejä automaattisesti, kun taas Puppeteerissa odotus pitää tehdä itse. Se on moottorin ominaisuus, ei Crawlee-virhe, mutta se tarkoittaa, että "sama API" ei ole sama koodi jokaisen handlerin sisällä.
Mitä en testannut
Tässä kierroksessa jätin tarkoituksella muutaman asian auki, jotta tuloksia ei tulkittaisi laajemmiksi kuin ne ovat.
- Skaala. Kaikki ajettiin pienillä fixtureillä ja lyhyillä julkisilla crawlilla. Ei 100–1 000 sivun pitkää ajoa, joten en voi sanoa mitään Crawleen autoskaalauksesta tai vakaudesta oikealla kuormalla.
- Jonon pysyvyys ja jatkaminen. En koskaan tappanut crawlia kesken ajon testatakseni, nouseeko
RequestQueuesiististi takaisin käyntiin kaatumisen jälkeen. Se on tärkeä ominaisuus pitkiin ajoihin, mutta sitä ei testattu tässä. - Dataset- ja KeyValueStore-exportit. Kirjoitin itse JSON/CSV-exportit harnessissa. Crawleen sisäänrakennetun
Dataset/KeyValueStore-exportin käytettävyyttä — joka on ehkä koko frameworkin ergonominen hyöty — en käyttänyt. - Proxy- ja session-poolit. Crawlee tarjoaa proxy-kierrätyksen ja fingerprinting-ominaisuuksia. Käsittelen niitä puhtaasti yhteensopivuus- ja operointikysymyksenä, en "anti-bot-ohituksena", enkä stressitestannut niitä kumpaankaan suuntaan.
Ja kaikkialla mainitut ajat ovat yhden koneen yhden ajon tuloksia. Ne näyttävät HTTP- ja selainpolun kustannusten muodon. Ne eivät ole benchmarkeja, enkä käyttäisi niitä sellaisina.
Plussat ja miinukset
Plussat
- Yksi API-pinta HTTP- ja selaincrawlaamiseen — moottorin vaihto on oikeasti luokan vaihto, ja tämä vahvistui 0 → täydet tiedot sekä paikallisella fixturellä että julkisella sivulla.
- Oikea crawl-framework:
RequestQueue,enqueueLinkssyvyydenhallinnalla, retryt jafailedRequestHandler, ei pelkkä sivun renderöijä. - Tarkka HTTP-poiminta (12/12 staattinen, 3/3 artikkelikappaletta, 8/8 JSON-API:n kautta) silloin kun JavaScript ei ole esteenä.
- Selainpolku saa talteen sisällön, jota HTTP-polku ei fyysisesti näe, ja ottaa kuvakaappauksia.
- Apache-2.0, TypeScript, aktiivisesti ylläpidetty.
Miinukset
- Selaincrawlerit vaativat erillisen
npx playwright install chromium-vaiheen (~81,7 MiB), jotanpm install crawleeei hoida — helppo unohtaa. - Selainrenderöinti tuo oikean per-sivu-kustannuksen (~5 s vs alle sekunti omassa yhden sivun testissä).
- Oletushakemisto
storage/ilmestyy tavallisissa ajoissa sivuvaikutuksena. - Skaala, jonon pysyvyys/jatkaminen ja Dataset-exportin ergonomia jäivät omassa testissä todentamatta.
- Proxy- ja fingerprinting-ominaisuuksia pitää käyttää sivuston ehtojen ja lain puitteissa — vastuuna, ei oikotienä.
Milloin valita Crawlee ja milloin hallittu API
Crawlee on itse rakennettava työkalu, ja se on monelle tiimille juuri oikea valinta. Tartu siihen, kun haluat omistaa crawlerin omassa Node-koodipohjassasi, yhdistää HTTP- ja selaincrawlaus samassa projektissa vaihtamatta frameworkia, ja hallita jonoa sekä tallennusta itse. Jos olet valmis ajamaan ja lopulta skaalaamaan selainlaivastoa, Crawlee tarjoaa siihen siistin ja hyvin suunnitellun rungon.
Toinen vaihtoehto on olla pyörittämättä kaikkea tuota infraa itse. Jos Chromium-instanssien vahtiminen, proxy-kierrätys ja anti-bot-käsittely eivät ole sitä, mihin haluat käyttää insinöörituntisi, hallittu API on vaihtoehto — ja siihen meidän oma developer stack Thunderbitissä sopii. Teknisille käyttäjille Thunderbit ei ole Chrome-laajennus; se on AI-scraping API, MCP-serveri ja CLI. Kutsut POST /distill -päätepistettä muuntaaksesi sivun siistiksi, LLM-valmiiksi Markdowniksi, tai POST /extract -päätepistettä JSON Schema -määrittelyllä saadaksesi rakenteisen datan takaisin. renderMode voi olla none, basic tai full, joten päätät itse, milloin täysi selainrenderöinti on sen arvoista. MCP-serveri antaa AI-agentin (Claude, Cursor ja muut MCP-asiakkaat) tehdä scrapingia kesken tehtävän, ja CLI toimii terminaalista tai CI:stä:
Kokeile Thunderbitia verkkodatan poimintaan
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
Kehittäjälle tärkeä ero: Crawlee antaa sinulle raaka-aineen — renderöidyn HTML:n, parsitut nodet — ja sinä omistat putken; hallittu API palauttaa skeemaan sopivaa strukturoitua JSONia, jossa JS-renderöinti, CAPTCHA:t ja anti-bot-käsittely hoidetaan palvelinpuolella. Eri työkalut eri tarpeisiin. Jos haluat maksimaalisen kontrollin etkä välitä operoinnista, Crawlee. Jos haluat datan ilman selainlaivaston pyörittämistä, hallittu vaihtoehto. Moni tiimi päätyy käyttämään molempia: yhtä räätälöityihin crawlauksiin ja toista tilanteisiin, joissa halutaan vain strukturoitu data nopeasti. Kustannuseron näet Thunderbitin hinnoittelusta.
Lopputulos
Kannattaako Crawleea käyttää? Kyllä — jos olet Node- tai TypeScript-kehittäjä ja haluat yhden frameworkin, joka kattaa HTTP- ja selaincrawlauksen oikealla crawl-jonolla taustalla. Kahden moottorin lupaus on juuri se syy valita Crawlee, ja se piti paikkansa testeissäni: sama URL siirtyi 0:sta täyteen dataan yhdellä luokkavaihdolla, staattinen poiminta oli tarkkaa ja nopeaa, ja queue- ja depth-crawlaus toimi kuten dokumentaatiossa luvataan.
Lähde liikkeelle kahdella asialla. Varaa budjettiin piilossa oleva selaimen lataus ensimmäistä PlaywrightCrawler-ajoa varten, äläkä oleta että ne osat, joita en testannut — skaala, crash-resume, sisäänrakennetut exportit — toimivat yhtä hyvin kuin ne osat, joita testasin, ennen kuin olet ajanut ne omalla kuormallasi. Oman crawlerin rakentamisen perustaksi Crawlee on vahva ja hyvin suunniteltu osaamista. Valmiiksi, täysin hands-offiksi data-putkeksi se on lähtöpiste, ei päätepysäkki.
Kokeile Thunderbitia verkkodatan poimintaan Get Started Free
Usein kysytyt kysymykset
Onko Crawlee ilmainen, ja mikä sen lisenssi on?
Kyllä. Crawlee on avoimen lähdekoodin projekti Apache-2.0-lisenssillä ja asennettavissa npm:stä (npm install crawlee). Testaamani versio oli 3.17.0. Selaincrawlerien ajaminen vaatii erillisen Chromium-latauksen Playwrightin kautta; sekin on ilmainen, mutta lisää asennukseen noin 81,7 MiB.
CheerioCrawler vai PlaywrightCrawler — kumpaa minun pitäisi käyttää?
Käytä CheerioCrawleria silloin, kun data on raakassa HTML:ssä tai taustalla olevassa JSON-API:ssa — se on paljon nopeampi eikä käynnistä selainta lainkaan. Käytä PlaywrightCrawleria silloin, kun sisältö renderöidään JavaScriptillä, minkä huomaa siitä, että HTTP-polku palauttaa tyhjiä tuloksia. Omissa testeissä HTTP-moottori palautti JS-renderöidyllä sivulla 0 kohdetta ja selainmoottori palautti kaiken. Koska API on sama, vaihtaminen on luokan vaihto, ei uudelleenkirjoitus.
Tarvitseeko Crawlee selainta toimiakseen?
Vain selaincrawlereita varten. CheerioCrawler ei tarvitse selainta lainkaan. PlaywrightCrawler (ja PuppeteerCrawler) tarvitsevat selainbinaarin — asenna se komennolla npx playwright install chromium. Huomaa, että pelkkä npm install crawlee ei hae selainta, ja se on yleisin ensimmäisen ajon kompastuskivi.
Pystyykö Crawlee käsittelemään paginointia ja monisivuisia crawlauksia?
Kyllä, ja juuri siksi se on hyvä valinta verrattuna erilliseen selainkirjastoon. enqueueLinks seuraa linkkejä (myös paginointiselektoreita kuten .next-page), RequestQueue deduplisoi ja hallitsee crawlia, ja käytössä on syvyydenhallinta sekä maxRequestsPerCrawl-rajat. Testissä saman hostnameen crawl kävi läpi 11 sivua syvyyksillä 0–2, ja epäonnistuneet pyynnöt nousivat näkyviin failedRequestHandlerin kautta.
Miten Crawlee vertautuu hallittuun scraping-API:in? Crawlee on itse hostattu: kirjoitat ja ajat crawlerin itse, ja vastaat skaalauksesta, proxyista ja anti-bot-käsittelystä. Thunderbitin kaltaiset hallitut API:t palauttavat siistiä Markdownia tai skeemaan sopivaa strukturoitua JSONia, ja renderöinti sekä anti-bot hoidetaan palvelinpuolella. Käytössä on API, MCP-serveri ja CLI. Valitse Crawlee, kun haluat maksimaalisen kontrollin omaan putkeesi; valitse hallittu API, kun et halua pyörittää ja skaalata selaininfrastruktuuria itse.
