Næsten hver eneste oversigt over de "bedste open source-scrapere" har den samme stille fejl: ingen kører værktøjerne på de samme sider. Scrapy bliver testet på en nyhedsartikel, Playwright på en eller anden e-handelsdemo, Colly på det, forfatteren lige havde liggende — og så rangeres de side om side, som om tallene overhovedet kunne betyde det samme. Den slags rangliste fortæller dig noget om siderne, ikke om værktøjerne.
Så jeg gjorde det kedelige, oplagte, som listerne springer over. Jeg byggede ét samlet sæt fixtures og sendte alle ni værktøjer igennem det: et statisk katalog, et katalog rendret med JavaScript, en artikel begravet i navigation og footer-støj, en bevidst ødelagt HTTP 500, en lille crawl-graf med interne links samt to offentlige øvesider. Samme facit, samme målinger, hver eneste kørsel. Scripts og rå output ligger i et offentligt benchmark-repo, så du selv kan køre det hele igen. Det, der kom tilbage, er ikke den pæne leaderboard, oversigterne lover — der er ingen enkelt vinder. Der er tre forskellige opgaver, og de ni værktøjer fordeler sig næsten af sig selv.
Prøv Thunderbit til udtræk af webdata
Sådan fungerede testen, og den ene begrænsning jeg siger højt
Hvert værktøj blev kørt mod de samme fixtures: 12 statiske produkter fordelt på to sider, 8 produkter injiceret med JavaScript efter en forsinkelse, en artikel omgivet af nav/footer-boilerplate omkring tre rigtige afsnit, en bevidst server-500, og en graf af interne links. Det er netop den opbygning, der får resultaterne til at hænge sammen — "8/8 dynamiske produkter" betyder det samme, uanset om det var Puppeteer eller Crawlee, der producerede det.
Her er grænsen, som de fleste oversigter springer over. Hver værktøjspakke afspejler sin egen kopi af disse fixtures, så absolutte tegnantal kan ikke sammenlignes direkte på tværs af værktøjer — læs dem som signaler inden for hvert værktøj, aldrig som en score mellem værktøjer. De tal, der kan sammenlignes, er recall (betrag det som en rate), JavaScript pass/fail og strukturel adfærd. En lignende note: Crawl4AI's statiske katalogkørsel dækkede kun side ét, så dens 6/6 er fuld recall på en smallere delmængde, mens de andre værktøjer crawl'ede begge sider for 12/12 — altså mindre scope, ikke et delvist tab. Hele begrundelsen, fixture for fixture, ligger i metodegennemgangen.
Endnu et forbehold, inden vi går til tallene. Hver pakke indeholder også en foreløbig forskningsscore, men jeg viser dem bevidst ikke som en rangeret tabel. De var interne hjælpemidler til at kontrollere hvert værktøj op imod dets eget bevismateriale, ikke en ligatabel — og at offentliggøre dem som sådan ville genskabe præcis det falsk præcise problem, som hele øvelsen forsøger at undgå. Det her er en sammenfatning af, hvad testen viste, ikke en resultatliste.
Hele feltet på én testbænk
Læs ned ad de to kolonner i denne tabel — "Renders JS?" og "Built-in crawl queue" — så træder de tre opgaver næsten frem af sig selv.
| Tool | Language | Renders JS? | Static recall | Structured output | Built-in crawl queue | Setup weight | License |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Yes (browser) | 6/6 (page 1) | CSS schema | BFS/DFS built-in | Heavy (2 browser stacks) | Apache-2.0 |
| Firecrawl | Self-hosted | Yes (playwright-service) | Full Markdown | Yes | /v1/crawl | Heaviest (6 containers) | AGPL-3.0 |
| trafilatura | Python | No | 3/3 article | No (text only) | No | Light | Apache-2.0 |
| Crawlee | Node/TS | Engine-optional | 12/12 | Via extraction | Yes (RequestQueue) | Medium (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Yes | 12/12 | Manual | No (hand-written BFS) | Medium (browser) | Apache-2.0 |
| Puppeteer | Node | Yes (Chrome) | 12/12 | Manual | No (hand-written BFS) | Medium (Chrome) | Apache-2.0 |
| Scrapy | Python | No | 12/12 | Feed export (JSON/CSV/XML) | Yes (built-in) | Medium (Twisted deps) | BSD-3 |
| Colly | Go | No | 12/12 | Via callbacks | Depth control | Light (1 binary + Go) | Apache-2.0 |
| Scrapling | Python | No (HTTP fetcher) | 12/12 | Yes | No | Medium ([fetchers]) | BSD-3 |
En note om metadata i tabellen og længere nede: stjerнетаl og versionsnumre blev taget i begyndelsen af juli 2026, og begge dele ændrer sig hurtigt. Tjek dem igen på projekternes GitHub og packageside, før du betragter dem som aktuelle.
Indeks over enkelttests
Hvert projekt i denne oversigt har en tilhørende dybdegående anmeldelse:
- Crawl4AI-anmeldelse
- Firecrawl-anmeldelse
- trafilatura-anmeldelse
- Playwright vs Puppeteer-sammenligning
- Crawlee-anmeldelse
- Scrapy-anmeldelse
- Colly-anmeldelse
- Scrapling-anmeldelse
Her er forsiderne — plus to rigtige screenshots fra testen med JavaScript-rendering, så "8/8 dynamisk" ikke bare er et tal på en side.
Opgave ét: gør en side til LLM-klar tekst
Hvis du vil have ren Markdown til en RAG-pipeline, er det tre værktøjer, der konkurrerer — og de kunne næsten ikke være mere forskellige.
Crawl4AI er i bund og grund en browserbaseret Markdown-generator, uanset markedsføringen. Det er værd at aflive historien om den "adaptive intelligence self-learning selector", som følger den rundt i søgeresultaterne: sådan noget har den ikke — det er en helt anden biblioteksfeature (mere om det, når vi når Scrapling). Det, den faktisk gør, gør den godt. På Books to Scrape-øvesitet leverede den 13.476 tegn Markdown, den håndterer CSS-schema-ekstraktion til strukturerede udtræk, og dens indbyggede BFS-deep crawl gik igennem 5 sider på crawl-graf-fixturen, mens den rendrede en JavaScript-side og tog et screenshot. Men der er også to tydelige minusser. Dens rå Markdown indeholder sidens boilerplate, medmindre du slår et content filter til, og den bevidste 500 kom tilbage som success=false — ikke fordi Crawl4AI pænt fangede HTTP-fejlen, men fordi dens egen indholdsheuristik kiggede på den lille fejltekst og markerede den som minimal_text ... blocked. Og setup lægger to browser stacks på disken. Version 0.9.0, Apache-2.0, omkring 71k stars i begyndelsen af juli.
Firecrawl er tungvægteren, og self-hosting fungerer faktisk — jeg siger "faktisk", fordi den seks-container stack (api, playwright-service, redis, rabbitmq, nuq-postgres og foundationdb) kom op og leverede 9.222 tegn LLM-klar Markdown fra den samme Books to Scrape-side. Den rendrede en JavaScript-side via sin indbyggede playwright-service, og Einstein-citatet efter script-kørsel dukkede op i outputtet, hvilket beviste, at renderingen var reel. To problemer, jeg ramte, var miljøets skyld, ikke Firecrawls, og jeg vil være præcis, så ingen kopierer den forkerte løsning: et build fra kildekode snublede over en containerd snapshotter-fejl under colima (jeg skiftede til de præbyggede images), og colimas 198.18.x.x DNS-række fik Firecrawls SSRF-beskyttelse til at slå ud, hvilket jeg løste med ALLOW_LOCAL_WEBHOOKS=true — en lokal udviklings-workaround, ikke noget man skal deaktivere i en rigtig deployment. Den self-hostede kerne mangler også Fire-engine, cloud anti-block-laget, og jeg testede ikke cloud-API'et. Det større røde flag er licensen: Firecrawls self-hostede kerne er AGPL-3.0, hvilket kræver reel juridisk gennemgang før kommerciel brug, ikke blot en fodnote. Omkring 148k stars i begyndelsen af juli.
trafilatura er gruppens modspil, og det er den, AI-hypen oftest glemmer. Ingen browser. Ingen strukturerede rækker. Bare hurtig, ren artikeltekst i ren Python. På artikel-fixturen trak den titlen plus alle 3 af de 3 rigtige afsnit, fjernede boilerplate helt — ingen "Login", "Subscribe" eller "Copyright" slap igennem — og hentede forfatter og dato oveni. På en offentlig produktside returnerede den 1.324 tegn ren tekst. Dens begrænsning er præcis det, designet lægger op til: peger du den mod et katalog, får du 12 produktnavne som tekst, men 0 strukturerede rækker — teksten er der, strukturen er det ikke, og den render ikke JavaScript. Version 2.1.0 (den aktuelle release), Apache-2.0, omkring 6,2k stars. Til ren artikelsekstraktion er det det første, jeg selv ville gribe efter.
De to Markdown-tegntal — 13.476 fra Crawl4AI og 9.222 fra Firecrawl — kom fra den samme offentlige side, men læs dem ikke som et kvalitetsskel. De afspejler forskellige Markdown-strategier (hvor meget sidechrome hver af dem beholder), ikke en dom over, hvilket output der er bedst. Det er reglen om signaler inden for hvert værktøj, der spiller ud helt åbent.
Opgave to: render JavaScript pålideligt
Noget data findes simpelthen ikke i HTML'en, før scripts har kørt, og så er en rigtig browser ikke længere valgfri. Tre værktøjer dækker den opgave — og to af dem viste sig at være næsten det samme værktøj.
Playwright og Puppeteer stod helt lige i alle tests, jeg kastede efter dem. Begge rendrede 8/8 dynamiske produkter på den lokale fixture og 10 på den offentlige Quotes JS-side, begge ramte 12/12 statisk recall, og begge håndterede 500-fejlen rent (Puppeteer returnerer et response-object i stedet for at kaste en fejl). Ingen af dem kommer med en crawl queue, så begge krævede en håndskrevet BFS for at gå igennem linkgrafen med 12 sider. Den eneste reelle forskel er rækkevidde: Playwright styrer Chromium, Firefox og WebKit og taler Python og .NET, mens Puppeteer er Chrome-først og kun Node. To forbehold, fordi versionerne ændrer sig hurtigt: Jeg testede Playwright 1.56.0 op mod en aktuel 1.61.1 og brugte kun Chromium, og Puppeteer 24.16.0 op mod en aktuel 25.3.0 — kør igen eller tag forbehold. Begge Apache-2.0; omkring 92k og 95k stars henholdsvis.
Crawlee er den, der løser queue-problemet, som de to andre efterlader åbent. Det pakker en Cheerio (HTTP)-motor og en Playwright (browser)-motor ind bag et fælles API, og kontrasten på én side er hele pointen: Cheerio-motoren så 0 JavaScript-injicerede elementer, Playwright-motoren så alle 8/8 lokalt (og 10 på den offentlige side), og skiftet mellem dem er en ændring på én linje. Det giver dig også en rigtig RequestQueue, og det er grunden til, at det hører hjemme i denne opgave og ikke i opgave tre. Det, ingen skriver i overskriften: browser-motoren kræver en separat npx playwright install, cirka 80 MiB, som npm install crawlee ikke henter for dig. Version 3.17.0, TypeScript, Apache-2.0, omkring 24,6k stars.
Opgave tre: crawl hurtigt uden browser
Når siden ikke bruger JavaScript, er en browser dyr overkill. Tre HTTP-first-værktøjer konkurrerer her, ét for hver sproglig filosofi, og de er uenige på interessante måder.
Scrapy er den mest ingeniørprægede ramme i feltet — spiders, feed-eksport til JSON/CSV/XML, AutoThrottle, det hele. Den ramte 12/12 statisk recall, trak artiklens 3/3 afsnit ud, gik igennem 11 sider på dybde 0–2 i crawl-grafen og fangede 500-fejlen via handle_httpstatus_list. Dets verdenssyn er det interessante: det renderer ikke, det genskaber requesten. Kastet mod JavaScript-siden fik den 0 noder — og så gav JSON-API'et bag samme side den 8/8. Det er Scrapy-filosofien i ét datapunkt: find den request siden selv laver, og replay den, i stedet for at styre en browser. Prisen er en ret stor dependency-stack (Twisted, lxml, parsel), og jeg testede den kun mod små fixtures. Version 2.17.0, BSD-3-Clause, omkring 63k stars.
Colly er Go-svaret, og den er dejligt bogstavelig omkring, hvad den er: én statisk binary, callback-drevet via OnHTML, OnResponse og OnError, med depth control. Den ramte 12/12 statisk recall, hentede 8/8 fra JSON-API'et via OnResponse, fangede 500-fejlen via OnError, og nåede 17 sider under en depth-2 crawl — og jeg formulerer det præcist sådan, fordi det sidetal er harnessens egen optælling, ikke en fuldstændig garanti, som Colly selv giver. Det, den ikke gør, er JavaScript: både den dynamiske fixture og Quotes JS-siden kom tilbage med 0, helt efter design. Du skal bruge et Go-toolchain for at bygge den, og modulversionen (v2.3.0) kører i øjeblikket foran den taggede release (v2.2.0). Apache-2.0, omkring 25k stars.
Scrapling er specialisten, og den gør æren op. Dens adaptive selectors er bygget til at finde et element igen, efter markup ændrer sig — så da jeg omdøbte en måls HTML-klasse fra product-name til product-title, matchede en almindelig selector 0, mens den adaptive rematch alligevel fandt det sporede element. Ved almindelig HTTP-ekstraktion ramte den 12/12 statisk og 8/8 på JSON-API'et. Det, dens egen dokumentation ikke skjuler: i en syntetisk multi-element-test genskabte den 1 af 3 — det er robust elementtracking, ikke total gendannelse, så lad være med at overvurdere det. Dens grundlæggende pip install scrapling kræver også [fetchers]-extra for overhovedet at komme i gang, og dens StealthyFetcher er en compliance-advarsel, ikke en feature jeg ville sætte på en slide. Version 0.4.10 (den aktuelle release), BSD-3-Clause, omkring 68,7k stars.
Mønstret bag de tre opgaver
Stil de ni værktøjer op side om side, og der opstår et klart mønster. Fuld statisk recall — flade 12/12 — er basisniveau for alle HTTP-first-værktøjer; ingen af dem snublede i den lette case, så det er ikke det, der skiller dem. Browserværktøjerne giver kun mening, når JavaScript faktisk er en del af billedet, og de betaler alle for det i setup: en browser stack, en ekstra installation eller en hel container-flåde. Og kolonnen "built-in crawl queue" er i virkeligheden grænsen mellem en ramme og en motor — Scrapy og Crawlee leverer orchestration, mens Playwright og Puppeteer får dig til selv at skrive BFS'en. Det er feltets form. Ingen vinder samlet, fordi ingen spiller det samme spil.
Så hvad bør du egentlig vælge
Testbænken nægter at krone en vinder, fordi det rigtige svar ikke er et værktøj, men et spørgsmål — hvilken af de tre opgaver laver du?
- Skal du bruge LLM-klar Markdown? Vælg trafilatura, når du vil have ren artikeltekst, Crawl4AI, når du også vil have CSS-ekstraktion og JavaScript-rendering i samme bibliotek, og Firecrawl, når du specifikt vil have en self-hosted service og kan acceptere både AGPL-3.0-licensen og vægten fra seks containere.
- Skal JavaScript rendres? Playwright eller Puppeteer til selve renderingen — vælg efter motor og sprog, for de er ellers lige — og Crawlee, når du også vil have crawl-orchestration serveret i stedet for at kode den selv.
- Skal du crawl'e statiske sider eller reproducerbare API'er i stor skala? Scrapy for en fuld Python-ramme, Colly for rå Go-hastighed i én binary, og Scrapling, når det er markup-drift, der er din konkrete, tilbagevendende smerte.
Matcher du værktøjet med opgaven, er alle disse valg forsvarlige. Tager du det fra den forkerte kategori — et browserværktøj til statiske sider eller en HTTP-parser til en JavaScript-app — så vil selv det bedst ratede bibliotek på internettet svigte dig.
Hvor en administreret AI-API passer ind i stedet
Alle værktøjerne ovenfor er gratis, open source og dine at køre. Det er også den fælles trade-off, testen hele tiden peger på: du ejer browsermiljøet, crawl-koden, anti-bot-kapløbet og hele vedligeholdelsen. For mange teams er netop den kontrol pointen, og licenskortet betyder noget, når du tager det valg — størstedelen af feltet er permissiv (Apache-2.0 på tværs af Crawl4AI, Crawlee, Playwright, Puppeteer og Colly; BSD-3 for Scrapy og Scrapling), mens Firecrawls self-hosted kerne med AGPL-3.0 er den ene, der kræver reel gennemgang, før den bruges kommercielt.
Men læg mærke til, hvad testen også viste: hvad disse værktøjer ikke gør. Render, crawl, strukturér og roter omkring blokeringer — sjældent alt på én gang, og aldrig uden din vedligeholdelse. En administreret AI-scraping-API samler hele stakken i ét kald. Vores egen developersurface hos Thunderbit er én mulighed, og for et teknisk publikum er det API'et, MCP-serveren og CLI'en, der betyder noget — ikke browser-extensionen. POST /distill returnerer ren Markdown, og POST /extract returnerer JSON defineret af et schema, med JavaScript-rendering og anti-bot håndteret server-side i stedet for på din egen maskine. Der findes en officiel MCP-server til agenter og coding assistants — thunderbit_suggest_fields kører gratis for at planlægge et udtræk, derefter klarer thunderbit_distill (1 kredit) og thunderbit_extract (20 kreditter) arbejdet — samt en CLI, du kan hente med npx @thunderbit/thunderbit-cli til terminal- og cron-jobs. For de ikke-tekniske på dit team findes der også en no-code Chrome extension, og priserne dækker begge retninger.
Trade-off'et er det samme, som hele denne testbænk kredser om: kør og vedligehold op til ni biblioteker selv til nul pris pr. kald, eller overlad rørene til nogen anden og betal pr. request. Ingen af delene er forkert. Det handler om, hvor meget af stakken du faktisk vil eje. Hvis du hellere vil se, hvordan udtrækket ser ud i praksis, viser Thunderbit YouTube-kanalen det trin for trin.
{{INTERNAL_BLOG_LINKS}}
Konklusion
Der findes ikke én bedste open source-scraper, og enhver liste, der roligt giver dig én, skjuler stille det spørgsmål, der faktisk afgør det: hvilken af de tre opgaver laver du? Gør en side til tekst, render JavaScript, eller crawl hurtigt uden browser — feltet fordeler sig rent i de tre grupper, og inde i hver gruppe handler valget om sprog og setup-vægt, ikke om en universel mester.
Hvis du tager én vane med dig fra det her, så lad det være denne: test på dine egne sider, før du binder dig til noget. Hvert tal her kan genskabes i benchmark-repoet netop af den grund — fordi værktøjet, der topper en generisk oversigt, og værktøjet, der overlever dine rigtige mål, ikke altid er det samme.
Prøv Thunderbit til udtræk af webdata Get Started Free
FAQ
Hvad er den bedste open source-webscraper? Der findes ikke én enkelt — det afhænger af opgaven. Til LLM-klar tekst: trafilatura eller Crawl4AI; til JavaScript-rendering: Playwright, Puppeteer eller Crawlee; til hurtig HTTP-crawl: Scrapy eller Colly. På en fælles testbænk var hvert værktøj stærkest inden for sin egen kategori og mærkbart svagere udenfor, hvilket er grunden til, at one-size-fits-all-ranglister er misvisende.
Hvilke open source-scrapere render JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer og Crawlees Playwright-motor renderer alle JavaScript. Scrapy, Colly, trafilatura og Scraplings standard HTTP-fetcher gør ikke — de kræver enten et reproducerbart API bag siden (Scrapys tilgang, som fik 8/8 via JSON-endpointet) eller en separat browsertilstand.
Har jeg brug for en headless browser for at scrape en side? Kun hvis data først vises, efter JavaScript har kørt. Hvis en almindelig HTTP-request plus en parser kan nå indholdet, er en browser dyr overkill — i den situation er Scrapy, Colly eller Scrapling både lettere og hurtigere.
Hvilken af dem har den mest kommercielt venlige licens? De fleste er permissive: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) eller BSD-3-Clause (Scrapy, Scrapling). Undtagelsen er Firecrawls self-hosted kerne, som er AGPL-3.0 og bør gennemgås grundigt, før du bygger et kommercielt produkt på den.
Kan benchmark-tallene genskabes? Ja. Hver runner, fixture og hvert råt resultat ligger i et offentligt MIT-licenseret repo. Den ene ting, du skal huske: recall og strukturelle resultater kan sammenlignes på tværs af værktøjer, men absolutte tegnantal er kun signaler inden for hvert værktøj, fordi hver pakke spejler fixtures i stedet for at dele én kanonisk kopi — så sammenlign rater og pass/fail, ikke rå tegnsummer.
