Nesten alle oversikter over «beste open source-scraper» har én stille svakhet: de tester aldri verktøyene på de samme sidene. Scrapy blir prøvd på en nyhetsartikkel, Playwright på en eller annen e-handelsdemo, Colly på noe forfatteren allerede hadde liggende — og så rangeres de mot hverandre, som om tallene faktisk kunne sammenlignes. En slik rangering sier mest om sidene, ikke om verktøyene.
Så jeg gjorde det kjedelige, opplagte som listene vanligvis hopper over. Jeg bygde ett sett med testfixtures og kjørte alle ni verktøyene gjennom dem: en statisk katalog, en katalog rendret med JavaScript, en artikkel begravd i navigasjon og footer-støy, en bevisst ødelagt HTTP 500, en liten crawl-graf med interne lenker, pluss to offentlige øvingsnettsteder. Samme fasit, samme målinger, hver eneste kjøring. Skriptene og rådataene ligger i ett offentlig benchmark-repositorium, så du kan kjøre alt på nytt selv. Resultatet ble ikke den pene resultatlisten oversiktene lover — det finnes ingen enkelt vinner. Det finnes tre ulike jobber, og de ni verktøyene fordeler seg nesten av seg selv mellom dem.
Prøv Thunderbit for webdatauttrekk
Hvordan testen fungerte, og den ene begrensningen jeg sier høyt
Alle verktøyene møtte de samme fixture-typene: 12 statiske produkter fordelt på to sider, 8 produkter injisert via JavaScript etter en forsinkelse, en artikkel omgitt av navigasjon og footer-bokser, en bevisst 500-feil fra serveren, og en graf av interne lenker. Nettopp det oppsettet gjør at resultatene kan sammenlignes — «8/8 dynamiske produkter» betyr nøyaktig det samme enten Puppeteer eller Crawlee produserte det.
Her er grensen de fleste oversikter hopper over. Hver verktøypakke speiler sin egen kopi av disse fixture-ne, så absolutte tegnmengder kan ikke sammenlignes direkte mellom verktøyene — les dem som signaler innenfor hvert verktøy, aldri som en kryssverktøy-score. Tallene som kan sammenlignes er recall (se det som en rate), om JavaScript lykkes eller ikke, og strukturell oppførsel. En lignende presisering: Crawl4AIs statiske katalogtest dekket bare side én, så 6/6 er full recall på et smalere utsnitt, mens de andre verktøyene crawlet begge sider og fikk 12/12 — mindre omfang, ikke delvis bom. Hele resonnementet, fixture for fixture, ligger i metodebeskrivelsen.
Én ting til før tallene. Hver pakke inneholder også en foreløpig forskningsscore, men jeg skriver dem bevisst ikke ut som en rangert tabell. De var interne hjelpemidler for å sjekke hvert verktøy opp mot sitt eget bevismateriale, ikke en liga-tabell — og å publisere dem som sådan ville gjenskape akkurat det falske presisjonsproblemet hele dette forsøket prøver å unngå. Dette er en syntese av det testen viste, ikke en resultatliste.
Hele feltet, på én testbenk
Les ned to kolonner i denne tabellen — «Renders JS?» og «Built-in crawl queue» — så trer de tre jobbene nesten tydelig fram av seg selv.
| Verktøy | Språk | Rendrer JS? | Statisk recall | Strukturert output | Innebygd crawl-kø | Oppsettsvekt | Lisens |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Ja (nettleser) | 6/6 (side 1) | CSS-skjema | BFS/DFS innebygd | Tung (2 nettleserstakker) | Apache-2.0 |
| Firecrawl | Selvhostet | Ja (playwright-service) | Full Markdown | Ja | /v1/crawl | Tyngst (6 containere) | AGPL-3.0 |
| trafilatura | Python | Nei | 3/3 artikkel | Nei (kun tekst) | Nei | Lett | Apache-2.0 |
| Crawlee | Node/TS | Valgfri motor | 12/12 | Via ekstraksjon | Ja (RequestQueue) | Middels (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Ja | 12/12 | Manuell | Nei (BFS skrevet for hånd) | Middels (nettleser) | Apache-2.0 |
| Puppeteer | Node | Ja (Chrome) | 12/12 | Manuell | Nei (BFS skrevet for hånd) | Middels (Chrome) | Apache-2.0 |
| Scrapy | Python | Nei | 12/12 | Feed-eksport (JSON/CSV/XML) | Ja (innebygd) | Middels (Twisted-avhengigheter) | BSD-3 |
| Colly | Go | Nei | 12/12 | Via callbacks | Dybdekontroll | Lett (1 binærfil + Go) | Apache-2.0 |
| Scrapling | Python | Nei (HTTP-henter) | 12/12 | Ja | Nei | Middels ([fetchers]) | BSD-3 |
En merknad om metadata i tabellen og ellers nedenfor: stjernetall og versjonsnumre ble hentet i begynnelsen av juli 2026, og begge deler endrer seg fort. Sjekk dem opp mot hvert prosjekts GitHub- og pakkeside før du behandler dem som ferske.
Indeks for enkeltverktøy-anmeldelsene
Hvert prosjekt i denne oversikten har en egen utdypende anmeldelse:
- Crawl4AI-anmeldelse
- Firecrawl-anmeldelse
- trafilatura-anmeldelse
- Playwright vs Puppeteer-sammenligning
- Crawlee-anmeldelse
- Scrapy-anmeldelse
- Colly-anmeldelse
- Scrapling-anmeldelse
Her er forsiden deres — pluss to ekte skjermbilder fra testen med JavaScript-rendering, så «8/8 dynamisk» ikke bare er et tall på en side.
Oppgave én: gjør en side om til LLM-klar tekst
Hvis du vil ha ren Markdown til en RAG-pipeline, er det tre verktøy som konkurrerer — og de kunne knapt vært mer ulike i oppbygning.
Crawl4AI er, bak markedsføringen, en nettleserbasert Markdown-generator. Det er verdt å avlive fortellingen om «adaptiv intelligens med selvlærende selektor» som følger den rundt i søkeresultatene: den har ikke noe slikt — det er et triks fra et annet bibliotek (mer om det når vi kommer til Scrapling). Det den faktisk gjør, gjør den bra. På øvingsnettstedet Books to Scrape leverte den 13 476 tegn med Markdown, den håndterer CSS-skjema-ekstraksjon for strukturerte uttrekk, og den innebygde BFS-dypcrawlen gikk gjennom 5 sider i crawl-graf-fixturen mens den rendret en JavaScript-side og tok et skjermbilde. To tydelige minus, derimot. Rå-Marken dens tar med sidens boilerplate med mindre du aktiverer et content filter, og den bevisste 500-feilen kom tilbake som success=false — ikke fordi Crawl4AI fanget HTTP-feilen rent, men fordi dens egen innholdsheuristikk så på den lille feilmeldingen og merket den som minimal_text ... blocked. Og oppsettet legger to nettleserstakker på disken din. Versjon 0.9.0, Apache-2.0, rundt 71k stjerner per begynnelsen av juli.
Firecrawl er tungvekteren, og selvhosting fungerer faktisk — jeg sier «faktisk» fordi sekscontainer-oppsettet (api, playwright-service, redis, rabbitmq, nuq-postgres og foundationdb) faktisk kom opp og produserte 9 222 tegn med LLM-klar Markdown fra samme Books to Scrape-side. Den rendret en JavaScript-side gjennom sin innebygde playwright-service, og Einstein-sitatet som kom inn etter skriptkjøring dukket opp i outputen, noe som beviste at renderingen var ekte. To problemer jeg støtte på skyldtes miljøet, ikke Firecrawl, og jeg vil være presis så ingen kopierer feil løsning: en bygging fra kilde støtt på en containerd snapshotter-feil under colima (jeg byttet til ferdigbygde images), og colimas 198.18.x.x-DNS-område trigget Firecrawls SSRF-beskyttelse, som jeg løste med ALLOW_LOCAL_WEBHOOKS=true — en lokal utviklingsomvei, ikke noe du bør slå av i produksjon. Den selvhostede kjernen mangler også Fire-engine, skyens anti-blokkeringslag, og jeg testet ikke sky-API-et. Den større advarselen er lisensen: Firecrawls selvhostede kjerne er AGPL-3.0, som krever skikkelig juridisk vurdering før kommersiell bruk — ikke en fotnote. Rundt 148k stjerner per begynnelsen av juli.
trafilatura er motstrømmen i gruppen, og den er den AI-hypelistene stadig glemmer. Ingen nettleser. Ingen strukturerte rader. Bare rask, ren artikkeltekst i ren Python. På artikkel-fixturen hentet den tittelen pluss alle 3 av de 3 reelle avsnittene, fjernet boilerplate fullstendig — ingen «Login», «Subscribe» eller «Copyright» lekket gjennom — og tok i tillegg med forfatter og dato. På en offentlig produktside returnerte den 1 324 tegn ren tekst. Begrensningen er akkurat det designet tilsier: peker du den mot en katalog, får du 12 produktnavn som tekst, men 0 strukturerte rader — teksten er der, strukturen er det ikke, og den rendrer ikke JavaScript. Versjon 2.1.0 (nåværende utgave), Apache-2.0, omtrent 6,2k stjerner. For ren artikkelhenting er dette det første jeg ville valgt.
De to Markdown-tallene — 13 476 fra Crawl4AI og 9 222 fra Firecrawl — kom fra samme offentlige side, men les dem ikke som et kvalitetsgap. De gjenspeiler ulike Markdown-strategier (hvor mye av sidechrome som beholdes), ikke en dom over hvilket output som er best. Det er regelen om signaler innenfor hvert verktøy, fra tidligere, i full aksjon.
Oppgave to: rendér JavaScript pålitelig
Noe data finnes rett og slett ikke i HTML-en før skriptene kjører, og i det øyeblikket slutter en ekte nettleser å være valgfri. Tre verktøy dekker denne jobben — og to av dem viste seg å være nesten det samme verktøyet.
Playwright og Puppeteer endte uavgjort på alt jeg kastet mot dem. Begge rendret 8/8 dynamiske produkter på den lokale fixturen og 10 på det offentlige Quotes JS-nettstedet, begge traff 12/12 statisk recall, og begge håndterte 500-feilen rent (Puppeteer returnerer et response-objekt i stedet for å kaste). Ingen av dem leverer en crawl-kø, så begge trengte BFS skrevet for hånd for å gå gjennom lenkegrafen på 12 sider. Den egentlige forskjellen er rekkevidde: Playwright styrer Chromium, Firefox og WebKit og snakker Python og .NET, mens Puppeteer er Chrome-først og kun Node. To presiseringer, fordi versjonene endrer seg fort: Jeg testet Playwright 1.56.0 mot en nåværende 1.61.1 og brukte bare Chromium, og Puppeteer 24.16.0 mot en nåværende 25.3.0 — kjør på nytt eller ta resultatet med forbehold. Begge Apache-2.0; omtrent 92k og 95k stjerner henholdsvis.
Crawlee er verktøyet som løser kø-problemet de to andre lar stå åpent. Det pakker en Cheerio-motor (HTTP) og en Playwright-motor (nettleser) bak ett felles API, og kontrasten på én side er hele poenget: Cheerio-motoren så 0 JavaScript-injiserte elementer, Playwright-motoren så alle 8/8 lokalt (og 10 på det offentlige nettstedet), og byttet mellom dem er én linjes endring. Det gir deg også en ekte RequestQueue, og det er det som gjør at den hører hjemme i denne oppgaven heller enn i oppgave tre. Fangsten ingen skriver i overskriften: nettlesermotoren trenger en separat npx playwright install, omtrent 80 MiB som npm install crawlee ikke henter for deg. Versjon 3.17.0, TypeScript, Apache-2.0, rundt 24,6k stjerner.
Oppgave tre: crawl raskt uten nettleser
Når siden ikke bruker JavaScript, er en nettleser dyr overkill. Tre HTTP-først-verktøy konkurrerer her, ett per språkfilosofi, og de er interessante nettopp fordi de er uenige.
Scrapy er det mest ingeniøraktige rammeverket i feltet — spiders, feed-eksport til JSON/CSV/XML, AutoThrottle, hele pakken. Det traff 12/12 statisk recall, hentet artikkelens 3/3 avsnitt, gikk gjennom 11 sider på tvers av dybde 0–2 i crawl-grafen, og fanget 500-feilen via handle_httpstatus_list. Verdensbildet er det interessante: det rendrer ikke, det reproduserer forespørselen. Kaster du den mot JavaScript-siden, fikk den 0 noder — og så ga JSON-API-et bak samme side den 8/8. Det er Scrapy-filosofien i ett datapunkt: finn forespørselen siden gjør, og spill den av igjen, ikke kjør en nettleser. Prisen er en ganske stor avhengighetsstakk (Twisted, lxml, parsel), og jeg testet den bare mot små fixtures. Versjon 2.17.0, BSD-3-Clause, omtrent 63k stjerner.
Colly er Go-svaret, og den er forfriskende bokstavelig om hva den er: én statisk binær, callback-drevet via OnHTML, OnResponse og OnError, med dybdekontroll. Den traff 12/12 statisk recall, hentet 8/8 fra JSON-API-et via OnResponse, fanget 500-feilen via OnError, og nådde 17 sider under en crawl med dybde 2 — og jeg formulerer det akkurat slik, fordi sideantallet er harnessens egen teller, ikke en fullstendighetsgaranti Colly selv lover. Det den ikke gjør, er JavaScript: den dynamiske fixturen og Quotes JS-nettstedet kom begge tilbake med 0, helt etter design. Du trenger Go-verktøykjeden for å bygge den, og modulversjonen (v2.3.0) ligger for øyeblikket foran den taggede releasen (v2.2.0). Apache-2.0, omtrent 25k stjerner.
Scrapling er spesialisten, og den fortjener den betegnelsen. De adaptive selektorene er laget for å finne et element igjen etter at markupen endrer seg — så da jeg endret en målside sin HTML-klasse fra product-name til product-title, traff en vanlig selektor 0, mens den adaptive gjenfinningslogikken fortsatt fant det sporede elementet. Ved ren HTTP-ekstraksjon traff den 12/12 statisk og 8/8 på JSON-API-et. Det dokumentasjonen ikke skjuler: i en syntetisk test med flere elementer fant den 1 av 3 — dette er robust elementsporing, ikke total gjenoppretting, så ikke overdriv det i hodet ditt. Grunninstallasjonen pip install scrapling trenger også [fetchers]-tillegget for å komme i gang, og StealthyFetcher er et etterlevelsesforbehold, ikke en funksjon jeg ville satt på en presentasjonsslide. Versjon 0.4.10 (nåværende utgave), BSD-3-Clause, rundt 68,7k stjerner.
Mønsteret bak de tre oppgavene
Legg de ni ved siden av hverandre, så blir noe ryddig tydelig. Full statisk recall — flate 12/12 — er minimumskrav for alle HTTP-først-verktøy; ingen av dem snublet i den enkle delen, så det er ikke noe som skiller dem. Nettleserverktøyene forsvarer bare den ekstra vekten når JavaScript faktisk er involvert, og de betaler alle for det i oppsett: en nettleserstakk, en ekstra installasjon eller en hel containerflåte. Og kolonnen «built-in crawl queue» er egentlig grensen mellom et rammeverk og en motor — Scrapy og Crawlee gir deg orkestrering, mens Playwright og Puppeteer lar deg skrive BFS-en selv. Det er slik feltet ser ut. Ingen vinner totalt fordi ingen spiller samme spill.
Så hvilket skal du faktisk velge
Testbenken nekter å kåre en vinner fordi riktig svar ikke er et verktøy, men et spørsmål — hvilken av de tre jobbene skal du gjøre?
- Trenger du LLM-klar Markdown? Velg trafilatura når du vil ha ren artikkeltekst, Crawl4AI når du også vil ha CSS-uttrekk og JavaScript-rendering i samme bibliotek, og Firecrawl når du spesifikt vil ha en selvhostet tjeneste og kan håndtere både AGPL-3.0-lisensen og vekten av seks containere.
- Trenger du JavaScript rendret? Bruk Playwright eller Puppeteer for selve rendering-en — velg etter motor og språk, siden de ellers er uavgjort — og Crawlee når du også vil ha crawl-orkestrering ferdig levert i stedet for å skrive den for hånd.
- Crawler du statiske sider eller reproduserbare API-er i stor skala? Scrapy for et fullt Python-rammeverk, Colly for rå Go-hastighet i én enkelt binær, og Scrapling når det er nettopp markup-drift som er ditt tilbakevendende problem.
Velg verktøy etter jobb, så er alle disse forsvarlige valg. Plukk fra feil kategori — et nettleserverktøy for statiske sider, eller en HTTP-parser for en JavaScript-app — og selv den best rangerte biblioteket på internett vil fortsatt svikte deg.
Hvor en administrert AI-API passer inn i stedet
Alle verktøyene over er gratis, open source og dine å kjøre. Det er også den felles avveiningen testen stadig peker på: du eier nettlesermiljøet, crawl-koden, anti-bot-kappløpet og alt vedlikeholdet. For mange team er nettopp den kontrollen poenget, og lisensbildet betyr noe når du tar valget — mesteparten av feltet er permissivt (Apache-2.0 for Crawl4AI, Crawlee, Playwright, Puppeteer og Colly; BSD-3 for Scrapy og Scrapling), mens Firecrawls selvhostede kjerne med AGPL-3.0 er den som krever skikkelig vurdering før kommersiell bruk.
Men legg merke til hva testen også avdekket: det disse verktøyene ikke gjør. Rendring, crawling, strukturering og blokk-håndtering — sjelden alt samtidig, og aldri uten at du vedlikeholder det selv. En administrert AI-scraping-API samler hele stakken i ett kall. Vår egen utviklerflate hos Thunderbit er ett alternativ der, og for et teknisk publikum er det API-et, MCP-serveren og CLI-en som betyr noe — ikke nettleserutvidelsen. POST /distill returnerer ren Markdown og POST /extract returnerer schema-definert JSON, med JavaScript-rendering og anti-bot håndtert på serversiden i stedet for på maskinen din. Det finnes en offisiell MCP-server for agenter og kodeassistenter — thunderbit_suggest_fields er gratis og hjelper deg å planlegge en ekstraksjon, deretter gjør thunderbit_distill (1 kreditt) og thunderbit_extract (20 kreditter) jobben — og en CLI du kan hente inn med npx @thunderbit/thunderbit-cli for terminal- og cron-jobber. For ikke-utviklerne på teamet finnes det også en no-code Chrome-utvidelse, og prisene dekker begge retninger.
Avveiningen er den samme som hele denne testbenken kretser rundt: kjør og vedlikehold opptil ni biblioteker selv uten kostnad per kall, eller overlat røropplegget og betal per forespørsel. Ingen av valgene er feil. Det kommer an på hvor mye av stakken du faktisk vil eie. Hvis du heller vil se hvordan ekstraksjonen ser ut i praksis, går Thunderbit YouTube-kanalen gjennom det.
{{INTERNAL_BLOG_LINKS}}
Konklusjon
Det finnes ingen enkelt beste open source-scraper, og enhver liste som skråsikkert gir deg én, skjuler stille spørsmålet som egentlig avgjør saken: hvilken av de tre jobbene gjør du? Gjør en side om til tekst, rendér JavaScript, eller crawl raskt uten nettleser — feltet deler seg ryddig i disse gruppene, og innenfor hver av dem handler valget om språk og oppsettsvekt, ikke om en universell mester.
Hvis du tar med deg én vane fra alt dette, så ta denne: test på dine egne sider før du bestemmer deg. Hvert tall her kan reproduseres i benchmark-repositoriet nettopp av den grunnen — fordi verktøyet som topper en generell oversikt og verktøyet som overlever dine faktiske mål, ikke alltid er det samme.
Prøv Thunderbit for webdatauttrekk Get Started Free
Vanlige spørsmål
Hva er den beste open source-webscraperen? Det finnes ikke én enkelt — det avhenger av oppgaven. For LLM-klar tekst: trafilatura eller Crawl4AI. For JavaScript-rendering: Playwright, Puppeteer eller Crawlee. For rask HTTP-crawling: Scrapy eller Colly. På en felles testbenk var hvert verktøy sterkest innenfor sin egen kategori og merkbart svakere utenfor den, og derfor blir one-size-fits-all-rangeringer misvisende.
Hvilke open source-scrapere rendrer JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer og Crawlees Playwright-motor rendrer JavaScript. Scrapy, Colly, trafilatura og Scraplings standard HTTP-henter gjør det ikke — de trenger enten et reproduserbart API bak siden (Scrapys tilnærming, som fikk 8/8 via JSON-endepunktet) eller en separat nettlesermodus.
Trenger jeg en headless browser for å scrape et nettsted? Bare hvis dataene først vises etter at JavaScript kjører. Hvis en vanlig HTTP-forespørsel pluss en parser kommer inn til innholdet, er en nettleser dyr overkill — Scrapy, Colly eller Scrapling vil være langt lettere og raskere i det tilfellet.
Hvilket av disse har mest brukervennlig lisens for kommersiell bruk? De fleste er permissive: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) eller BSD-3-Clause (Scrapy, Scrapling). Unntaket er Firecrawls selvhostede kjerne, som er AGPL-3.0 og bør gjennomgås nøye før du bygger et kommersielt produkt på den.
Er disse benchmark-tallene reproduserbare? Ja. Hver kjører, hver fixture og hvert råresultat ligger i et offentlig MIT-lisensiert repo. Én ting å huske på: recall og strukturelle resultater kan sammenlignes på tvers av verktøy, men absolutte tegnmengder er bare signaler innenfor hvert verktøy, fordi hver pakke speiler fixture-ne i stedet for å dele én kanonisk kopi — så sammenlign rater og pass/fail, ikke rå tegnsummer.
