De fleste møter Crawlee når de egentlig prøver å finne svar på et annet spørsmål: «hvilken headless-browser bør jeg bruke?» Det er egentlig feil spørsmål, og Crawlee er grunnen. Det er ikke en nettleser. Det er et Node/TypeScript-rammeverk som bruker en når du trenger det, og lar være når du ikke gjør det.
Jeg brukte et par dager på å kjøre Crawlee 3.17.0 mot et kontrollert sett med testdata og noen offentlige demo-nettsider, på Node v22.22.3 og macOS. Hovedpåstanden — ett bibliotek, én API, enten en HTTP-crawler eller en ekte nettleser under panseret — var det jeg ville teste hardest, fordi det er nettopp den påstanden som avgjør om Crawlee er verdt å legge inn i stacken din, eller om du heller bør gå rett på Playwright direkte. Kortversjonen: historien om de to motorene holder mål, med et par forbehold jeg kommer tilbake til.
Hva Crawlee faktisk er (og ikke er)
Crawlee beskriver seg selv som et bibliotek for webskraping og nettleserautomatisering for Node.js, bygget for å lage pålitelige crawlere. Den offisielle posisjoneringen er bred: hent data til AI, LLM-er, RAG eller GPT-er; last ned HTML, PDF, JPG, PNG og andre filer; fungerer med Puppeteer, Playwright, Cheerio, JSDOM og rå HTTP; med eller uten nettleservindu; og med proxy-rotasjon inkludert. Det er mye å dekke, så det hjelper å si hva Crawlee ikke er.
Det er ikke en rendering-motor. Det har ikke egen nettleser. Når du vil at JavaScript skal kjøres, styrer Crawlee Playwright eller Puppeteer, som igjen styrer Chromium (eller en annen nettleser). Det er heller ikke en hostet tjeneste du kaller over nettet — det er en avhengighet du installerer og kjører selv. Det Crawlee er, helt presist, er laget over hentelaget: crawler-klassene, request-køen, lagringen og logikken for å følge lenker. Tenk på det som crawl-rammeverket, med en motor som kan byttes ut under.
Til orientering: versjonen jeg testet var 3.17.0 (utgitt 2026-06-04), det er TypeScript, lisensen er Apache-2.0, og repoet lå på omtrent 24,6k stjerner per 2026-07-09 på apify/crawlee. Stjernetall endrer seg hele tiden — repoet fikk 53 nye i løpet av de to dagene jeg fulgte det — så se på tallet som et øyeblikksbilde, ikke som en evig sannhet.
De to motorene: CheerioCrawler vs PlaywrightCrawler
Her er det designet virkelig fortjener plassen sin, og det var her jeg brukte mest tid.
CheerioCrawler er HTTP-sporet. Den henter rå HTML over nettverket og parser den med Cheerio — ingen nettleser, ingen JavaScript-kjøring, ingen rendering. Den er rask og billig. PlaywrightCrawler er nettlesersporet. Den starter ekte Chromium, renderer siden inkludert alt JavaScript bruker for å bygge DOM-en, og kan til og med ta skjermbilder.
To ulike motorer med helt ulike egenskaper. Poenget Crawlee prøver å få fram, er at de kler seg likt. Begge tar en requestHandler. Begge eksponerer run(). Begge kan følge lenker med enqueueLinks. Å gå fra én motor til den andre er et klassebytte, ikke en omskriving — det bekreftet jeg ved å holde ekstraksjonslogikken byte-identisk og bare bytte hvilken crawler-klasse som pakket den inn.
Det er én ting det er viktig å være presis på, fordi det er akkurat der likheten stopper: hvordan du leser innholdet er forskjellig. Inne i en CheerioCrawler-handler får du $ — et statisk, ferdig parsede DOM-tre du spør mot som i jQuery. Inne i en nettleserhandler får du et levende page-objekt. Så køen, rutingen og «legg til denne dataen, følg de lenkene»-opplegget forblir identisk, men linjen der du faktisk leser siden endrer form. Crawlees egne dokumenter sier i praksis det samme — de avgrenser det delte grensesnittet til crawl-operasjonene og peker på innholdslesingen som det som varierer.
| Motor | Hvordan den henter | Kjører JavaScript? | Min kjøring (1 dynamisk side) | Best egnet for |
|---|---|---|---|---|
CheerioCrawler | Rå HTTP + Cheerio-parsing | Nei | ~0.035s | Statisk HTML, JSON-API-er, hastighet |
PlaywrightCrawler | Ekte Chromium via Playwright | Ja | ~4.967s | JS-renderte sider, skjermbilder |
Disse tidene er fra én maskin og én kjøring — ikke en benchmark, bare illustrasjon av avveiningen. Nettleser-sporet kostet omtrent to størrelsesordener mer tid på samme URL. Det er prisen for rendering, og det er derfor du ikke velger det som standard.
Testen: samme URL, 0 vs 8/8
Påstander er billige. Grunnen til at jeg stoler på historien om de to motorene, er at jeg kunne få den til å feile — og så fikse den ved å bytte én klasse.
Jeg bygde en lokal dynamisk testside — en katalogside der produktkortene injiseres av JavaScript etter lasting, akkurat den typen side som har blitt standard på nettet. Jeg pekte CheerioCrawler mot den. Den returnerte 0 produktkort. Det er ikke en feil; det er fysikk. Cheerio kjørte aldri JavaScript-et, så kortene eksisterte aldri i HTML-en den parsed. Deretter pekte jeg PlaywrightCrawler mot nøyaktig samme URL, endret ingenting annet, og den rendret 8 av 8 produkter og tok et skjermbilde som bevis.
For å sikre at det ikke bare var en særhet ved min egen testside, kjørte jeg samme mønster mot en offentlig nettside — Quotes to Scrape-demoen med JavaScript, som bygger sitatene på klientsiden. Samme resultat, samme retning: CheerioCrawler så 0 sitater, PlaywrightCrawler hentet fram 10.
Jeg vil være nøye med hva dette faktisk beviser. Det er en ren bekreftelse av en påstand Crawlee allerede dokumenterer — rammeverket har delt samme basisklasse og samme grensesnitt mellom crawler-typene siden versjon 3.0. Så dette er verifisering, ikke oppdagelse. Men det er nettopp verdien: markedsføringsløftet om «ett grensesnitt, HTTP eller nettleser» er reelt, og her er 0 → full data dokumentert både på en testside jeg kontrollerer og en side jeg ikke gjør det.
Hvor HTTP-sporet vinner
Det er lett å lese avsnittet over som «bruk alltid nettleser». Ikke gjør det. Hele poenget med de to motorene er at nettleseren er den kostbare nødløsningen, ikke standardvalget.
På statisk innhold var CheerioCrawler både nøyaktig og rask. Min statiske katalogtestside ga 12 av 12 produkter med full treffprosent, og fulgte paginering via enqueueLinks({ selector: '.next-page' }), på omtrent 0.155 sekunder. En artikkelside ga tittelen og alle 3 av 3 avsnitt i brødteksten, mens login-/abonnement-/copyright-fyll ble separert ryddig fra innholdet.
Det viktigste å ta med seg: en side der data lastes inn med JavaScript, har ofte et JSON-API rett bak seg. Dataene i min dynamiske testside lå på et endepunkt, og da jeg pekte CheerioCrawler direkte mot API-et, hentet den 8 av 8 produkter — uten nettleser, på omtrent 0.035 sekunder. De samme dataene tok nesten fem sekunder å rendre via nettlesersporet. Lærdommen er gammel, men like sann: hvis du kan gjenskape den underliggende forespørselen, gjør det i stedet for å starte Chromium. Crawlee lar deg ta det valget per crawler uten å bytte rammeverk.
Del med crawl-rammeverket (grunnen til å velge Crawlee fremfor et rent nettleserbibliotek)
Hvis alt du trengte var å rendere én side, hadde du ikke trengt Crawlee — da ville du brukt Playwright eller Puppeteer alene. Det et rent nettleserbibliotek ikke gir deg, er en crawl: kø, deduplisering, dybdekontroll og retries. Det er den delen av Crawlee som ikke handler om motorer i det hele tatt.
Jeg kjørte en crawl innenfor samme hostname fra roten av testdataene, med enqueueLinks og dybdesporing. Crawlee gikk gjennom 11 sider fordelt på dybdene {0:1, 1:3, 2:7} — én rot, tre sider ett hopp ut, syv sider to hopp ut — og respekterte maxRequestsPerCrawl som stoppbetingelse. RequestQueue tok seg av bokføringen. Når jeg sendte en forespørsel til en side som returnerte HTTP 500, prøvde Crawlee på nytt og sendte deretter feilen videre gjennom failedRequestHandler i stedet for å svelge den stille eller krasje kjøringen.
Dette er det sterkeste argumentet for Crawlee framfor et frittstående nettleserverktøy: crawl-orchestreringen er innebygd, og viktigst av alt, den er den samme enten motoren under er HTTP eller nettleser. Du skriver kø- og lenkefølgingslogikken én gang. Du bestemmer separat om hver crawler skal rendre JavaScript eller ikke.
Oppsett og den skjulte nettleser-nedlastingen
Installasjonen gikk stort sett smertefritt, med ett fellepunkt som vil bite førstegangsbrukere.
npm install crawlee playwright gikk fint — 0 sårbarheter rapportert. Men PlaywrightCrawler starter ikke før du også kjører npx playwright install chromium, som laster ned en Chromium-binær på rundt 81.7 MiB. Å installere bare crawlee pakker ikke ned en nettleser. Hopper du over det steget og går rett på en browser-crawler, får du en oppstartsfeil som ikke er opplagt hvis du ikke allerede kjenner Playwrights pakkemodell. Det er arvet Playwright-oppførsel, ikke en Crawlee-feil, men det er like fullt en reell friksjon ved første oppstart som det er verdt å nevne.
Et operasjonelt notat til: Som standard skriver Crawlee til en lokal storage/-mappe. Testoppsettet mitt omdirigerte dette til en midlertidig arbeidsmappe og skrudde av lagring for å holde ting ryddig, men en vanlig kjøring vil legge igjen en storage/-mappe i prosjektet ditt. Ikke et problem, bare noe det er greit å vite før det dukker opp i git status.
En tredje motor, kort fortalt
Crawlees likhetshistorie stopper ikke ved Cheerio og Playwright. Det finnes også PuppeteerCrawler, og jeg sjekket hvor langt påstanden om «samme grensesnitt» faktisk strekker seg dit — på klasse- og API-nivå, ikke med en live crawl.
Alle tre crawler-klassene går tilbake til samme BasicCrawler-base. CheerioCrawler går via en HttpCrawler; PlaywrightCrawler og PuppeteerCrawler går begge via en delt BrowserCrawler. Ved å inspisere den installerte pakken fant jeg 24 offentlige metoder som deles av alle tre motorene, inkludert kø- og lagringsoperasjonene hele designet bygger på — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. PuppeteerCrawler og PlaywrightCrawler har faktisk nøyaktig samme offentlige metode-sett. De eneste forskjellene på tvers av motorene ligger akkurat i HTTP-vs.-nettleser-skjøten, som er der du forventer dem.
Grensen det er verdt å si tydelig: Jeg kjørte ikke en faktisk PuppeteerCrawler-crawl. puppeteer-peer-dependency er valgfri og var ikke installert i testpakken min, og å teste den ville betydd enda en nettlesernedlasting. Så Puppeteer-likheten her er verifisert strukturelt — samme basisklasse, samme delte metoder, samme form på handler-konteksten — ikke gjennom en faktisk kjøring. Og selv når grensesnittet er likt, er ikke oppførselen under helt identisk: Crawlees egen veiledning påpeker at Playwright venter automatisk på elementer, mens Puppeteer krever at du venter eksplisitt. Det er en egenskap ved motoren, ikke en feil i Crawlee, men det betyr at «samme API» ikke er det samme som «samme kode inni hver handler».
Det jeg ikke testet
Her er hva denne runden med vilje lot ligge, så du ikke leser resultatene mine som mer omfattende enn de faktisk er.
- Skala. Alt kjørte på små testdata og korte offentlige crawls. Ingen langkjøring på 100–1 000 sider, så jeg kan ikke si noe om Crawlees autoskalering eller stabilitet under reell belastning.
- Vedvarende kø og gjenopptakelse. Jeg stoppet aldri en crawl midt i løpet for å se om
RequestQueuehenter seg pent inn igjen etter et krasj. Det er en viktig funksjon for store jobber, og den er ikke testet her. - Eksport fra Dataset og KeyValueStore. Jeg skrev JSON/CSV-eksportene selv i testoppsettet. Crawlees innebygde eksportopplevelse for
Dataset/KeyValueStore— kanskje en av de største grunnene til å bruke rammeverket — testet jeg ikke. - Proxy- og session-pools. Crawlee leverer funksjoner for proxy-rotasjon og fingerprinting. Jeg behandler dette strengt som et compliance- og driftsområde, ikke som et «anti-bot bypass»-salgspoeng, og jeg stresstestet det ikke i noen retning.
Og tidene gjennom hele testen er fra én maskin og én kjøring. De viser formen på kostnaden mellom HTTP og nettleser. De er ikke benchmarks, og jeg ville ikke sitert dem som det.
Fordeler og ulemper
Fordeler
- Ett API på tvers av HTTP- og nettlesercrawling — motorbyttet er virkelig et klassebytte, bekreftet med 0 → full data både på en lokal testside og en offentlig side.
- Et ekte crawl-rammeverk:
RequestQueue,enqueueLinksmed dybdekontroll, retries ogfailedRequestHandler, ikke bare en siderenderer. - Nøyaktig HTTP-ekstraksjon (12/12 statisk, 3/3 artikkelavsnitt, 8/8 via JSON-API) når JavaScript ikke står i veien.
- Nettlesersporet henter innhold HTTP-sporet fysisk ikke kan se, og kan ta skjermbilder.
- Apache-2.0, TypeScript, aktivt vedlikeholdt.
Ulemper
- Browser-crawlerne krever en separat
npx playwright install chromium(~81.7 MiB) somnpm install crawleeikke håndterer — lett å overse. - Rendering i nettleser har reell kostnad per side (~5s mot under ett sekund i min enkeltsidetest).
- Standardbivirkning i form av en
storage/-mappe ved vanlige kjøringer. - Skala, gjenopptakelse av kø etter krasj og eksportopplevelse for Dataset er ikke bevist i mine tester.
- Proxy- og fingerprinting-funksjoner må brukes innenfor nettstedets vilkår og lovverket — et ansvar, ikke en funksjon du bare kan lene deg på.
Når du bør velge Crawlee vs et administrert API
Crawlee er et verktøy du bygger selv, og det er det riktige valget for mange team. Velg det når du vil eie crawleren i din egen Node-kodebase, blande HTTP- og nettlesercrawling i ett prosjekt uten å bytte rammeverk, og styre kø og lagring selv. Hvis du er komfortabel med å drifte og etter hvert skalere en flåte av nettlesere, gir Crawlee deg en ren og velutformet grunnmur å bygge på.
Det andre sporet er å slippe å drifte alt dette selv. Hvis du ikke ønsker å bruke ingeniørtiden din på å passe Chromium-instanser, proxy-rotasjon og anti-bot-håndtering, er et administrert API alternativet — og det er der vår egen utviklerstack hos Thunderbit passer inn. For tekniske brukere er Thunderbit ikke Chrome-utvidelsen; det er en AI-skrape-API, MCP-server og CLI. Du kaller POST /distill for å gjøre en side om til ren, LLM-klargjort Markdown, eller POST /extract med et JSON Schema for å få strukturert data tilbake, med renderMode satt til none, basic eller full slik at du selv bestemmer når full nettleserrendering er verdt det. MCP-serveren lar en AI-agent (Claude, Cursor og andre MCP-klienter) skrape midt i en oppgave, og CLI-en kan kjøres fra terminalen eller CI:
Prøv Thunderbit for uthenting av nettdata
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
Forskjellen som betyr noe for utviklere: Crawlee gir deg råmaterialet — rendret HTML, parsede noder — og du eier pipelinen; et administrert API gir deg strukturert JSON som matcher skjemaet, med JS-rendering, CAPTCHA og anti-bot håndtert på serversiden. Forskjellige jobber. Vil du ha maksimal kontroll og tåler driften, velg Crawlee. Vil du ha data uten å drifte en nettleserflåte, velg en administrert løsning. Mange team ender opp med å bruke begge, én for skreddersydde crawls og én for tilfellene der de bare vil ha strukturert data. Du kan se kostnadsavveiningen på Thunderbits priser.
Konklusjon
Bør du bruke Crawlee? Ja — hvis du er en Node- eller TypeScript-utvikler som vil ha ett rammeverk som dekker både HTTP- og nettlesercrawling, med en ekte crawl-kø under. Løftet om to motorer er hele grunnen til å velge det, og det holdt på testdataene mine: samme URL gikk fra 0 til full data med ett klassebytte, statisk ekstraksjon var både rask og nøyaktig, og kø- og dybdecrawling fungerte som dokumentert.
Gå inn med to ting i bakhodet. Sett av plass til den skjulte nettlesernedlastingen første gang du bruker PlaywrightCrawler, og ikke anta at delene jeg ikke testet — skala, gjenoppretting etter krasj, innebygde eksportfunksjoner — fungerer like godt som delene jeg faktisk testet før du har kjørt dem på din egen last. Som grunnlag for å bygge din egen crawler er Crawlee et solid og godt konstruert stykke ingeniørarbeid. Som ferdig, helautomatisk datapipeline er det et utgangspunkt, ikke endestasjonen.
Prøv Thunderbit for uthenting av nettdata Get Started Free
Vanlige spørsmål
Er Crawlee gratis, og hvilken lisens har det?
Ja. Crawlee er åpen kildekode under Apache-2.0-lisensen og installeres fra npm (npm install crawlee). Versjonen jeg testet var 3.17.0. For å kjøre nettleser-crawlerne må du i tillegg laste ned Chromium via Playwright, som også er gratis, men legger omtrent 81.7 MiB til oppsettet.
CheerioCrawler vs PlaywrightCrawler — hvilken bør jeg bruke?
Bruk CheerioCrawler når dataene ligger i rå HTML eller i et underliggende JSON-API — den er mye raskere og starter aldri en nettleser. Bruk PlaywrightCrawler når innholdet rendres av JavaScript, noe du ofte ser når HTTP-sporet gir tomme resultater. I testene mine returnerte HTTP-motoren 0 elementer på en JS-rendret side, mens nettlesermotoren hentet alt. Siden de deler samme API, er byttet et klassebytte, ikke en omskriving.
Trenger Crawlee en nettleser for å kjøre?
Bare for nettleser-crawlerne. CheerioCrawler trenger ingen nettleser i det hele tatt. PlaywrightCrawler (og PuppeteerCrawler) trenger en nettleserbinær — installer den med npx playwright install chromium. Merk at npm install crawlee alene ikke laster ned en nettleser, og det er den vanligste fellgruven ved første oppstart.
Kan Crawlee håndtere paginering og crawl på flere sider?
Ja, og dette er en av hovedgrunnene til å velge det fremfor et rent nettleserbibliotek. enqueueLinks følger lenker (inkludert pagineringsvelgere som .next-page), RequestQueue dedupliserer og styrer crawl-en, og du får både dybdekontroll og grenser via maxRequestsPerCrawl. I testene mine gikk en crawl innenfor samme hostname gjennom 11 sider på dybde 0–2, og mislykkede forespørsler ble håndtert via failedRequestHandler.
Hvordan sammenlignes Crawlee med et hostet skrape-API?
Crawlee kjøres selv: du skriver og drifter crawleren, og du eier skalering, proxyer og anti-bot-håndtering. Et administrert API som Thunderbits distill/extract-endepunkter leverer ren Markdown eller strukturert JSON som matcher skjemaet, med rendering og anti-bot håndtert på serversiden, eksponert via API, MCP-server og CLI. Velg Crawlee når du vil ha maksimal kontroll over din egen pipeline; velg et administrert API når du helst vil slippe å drifte og skalere nettleserinfrastrukturen selv.
