Fast jeder Vergleich zum Thema „beste Open-Source-Scraper“ hat denselben stillen Fehler: Die Tools werden nicht auf denselben Seiten getestet. Scrapy läuft gegen einen News-Artikel, Playwright gegen irgendeine E-Commerce-Demo, Colly gegen das, was der Autor gerade zur Hand hatte – und danach werden sie direkt gegeneinander gerankt, als hätten diese Zahlen je wirklich dasselbe bedeutet. Diese Rangfolge sagt dir mehr über die Seiten als über die Tools.
Also habe ich genau das gemacht, was viele Listen auslassen, weil es langweilig und naheliegend ist. Ich habe einen gemeinsamen Satz an Testfällen gebaut und alle neun Tools daran gemessen: einen statischen Produktkatalog, einen per JavaScript gerenderten Katalog, einen Artikel, der sich hinter Navigation und Footer-Ballast versteckt, einen absichtlich kaputten HTTP-500-Fall, einen kleinen Crawl-Graphen aus internen Links sowie zwei öffentliche Übungsseiten. Gleiche Referenzdaten, gleiche Messung, jeder einzelne Lauf. Die Skripte und Rohdaten liegen in einem öffentlichen Benchmark-Repo, damit du alles selbst erneut ausführen kannst. Das Ergebnis ist nicht das saubere Ranking, das man aus solchen Übersichten erwartet – es gibt keinen einzelnen Sieger. Es gibt drei unterschiedliche Aufgaben, und die neun Tools ordnen sich fast von selbst genau dort ein.
Thunderbit für Web-Datenextraktion ausprobieren
Wie der Testaufbau funktioniert hat – und die eine Einschränkung, die ich offen sage
Jedes Tool wurde mit denselben Testformen gefüttert: 12 statische Produkte auf zwei Seiten verteilt, 8 Produkte, die nach einer Verzögerung per JavaScript eingefügt werden, ein Artikel mit Boilerplate aus Navigation und Footer um drei echte Absätze herum, ein absichtlich ausgelöster Server-500-Fehler und ein Graph interner Links. Genau dieses Design sorgt dafür, dass die Resultate vergleichbar sind – „8/8 dynamische Produkte“ bedeutet exakt dasselbe, egal ob Puppeteer oder Crawlee das Ergebnis erzeugt hat.
Hier kommt die Grenze, die viele Roundups gern unterschlagen. Das jeweilige Testpaket eines Tools spiegelt seine eigenen Kopien dieser Fixtures wider, deshalb lassen sich absolute Zeichenzahlen nicht strikt toolübergreifend vergleichen – sie sind nur als Signal innerhalb eines Tools zu lesen, niemals als Score zwischen Tools. Wirklich vergleichbar sind Recall-Werte, JavaScript bestanden/nicht bestanden und strukturelles Verhalten. Eine ähnliche Anmerkung zur Reichweite: Der statische Lauf von Crawl4AI umfasste nur Seite eins, daher ist sein 6/6 ein vollständiger Recall auf einem engeren Ausschnitt, während die anderen Tools beide Seiten und damit 12/12 abgeholt haben – also kleinerer Umfang, kein teilweises Versäumnis. Die vollständige Begründung, Fixture für Fixture, steht im Methodik-Text.
Noch ein Hinweis, bevor wir zu den Zahlen kommen. Jedes Paket enthält außerdem einen vorläufigen Research-Score, aber ich drucke ihn bewusst nicht als Rangliste aus. Er diente nur intern dazu, jedes Tool gegen seine eigenen Belege zu prüfen – nicht als Liga-Tabelle. Ihn als solche zu veröffentlichen würde genau das Problem falscher Präzision wieder erzeugen, das diese ganze Übung vermeiden soll. Das hier ist eine Zusammenfassung dessen, was der Test gezeigt hat, keine Tabelle zur Vergabe von Medaillen.
Das gesamte Feld auf einem Prüfstand
Wenn du in dieser Tabelle nur zwei Spalten liest – „Renders JS?“ und „Built-in crawl queue“ –, springen dir die drei Aufgaben praktisch ins Auge.
| Tool | Sprache | Rendert JS? | Statischer Recall | Strukturierte Ausgabe | Integrierte Crawl-Queue | Aufwand beim Setup | Lizenz |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Ja (Browser) | 6/6 (Seite 1) | CSS-Schema | BFS/DFS integriert | Hoch (2 Browser-Stacks) | Apache-2.0 |
| Firecrawl | Selbst gehostet | Ja (playwright-service) | Vollständiges Markdown | Ja | /v1/crawl | Sehr hoch (6 Container) | AGPL-3.0 |
| trafilatura | Python | Nein | 3/3 Artikel | Nein (nur Text) | Nein | Gering | Apache-2.0 |
| Crawlee | Node/TS | Engine optional | 12/12 | Über Extraktion | Ja (RequestQueue) | Mittel (+~80 MiB) | Apache-2.0 |
| Playwright | Node/mehrere | Ja | 12/12 | Manuell | Nein (BFS per Hand) | Mittel (Browser) | Apache-2.0 |
| Puppeteer | Node | Ja (Chrome) | 12/12 | Manuell | Nein (BFS per Hand) | Mittel (Chrome) | Apache-2.0 |
| Scrapy | Python | Nein | 12/12 | Feed-Export (JSON/CSV/XML) | Ja (integriert) | Mittel (Twisted-Dependencies) | BSD-3 |
| Colly | Go | Nein | 12/12 | Über Callbacks | Tiefenkontrolle | Gering (1 Binary + Go) | Apache-2.0 |
| Scrapling | Python | Nein (HTTP-Fetcher) | 12/12 | Ja | Nein | Mittel ([fetchers]) | BSD-3 |
Ein Hinweis zu den Metadaten in dieser Tabelle und überall weiter unten: Die Sternzahlen und Versionsangaben wurden Anfang Juli 2026 erfasst, und beides ändert sich schnell. Prüfe sie am besten direkt auf GitHub und der jeweiligen Paketseite, bevor du sie als aktuell behandelst.
Der Index zu den Einzeltests
Zu jedem Projekt in diesem Vergleich gibt es eine ausführliche Einzelanalyse:
- Crawl4AI review
- Firecrawl review
- trafilatura review
- Playwright vs Puppeteer comparison
- Crawlee review
- Scrapy review
- Colly review
- Scrapling review
Hier sind die Cover – plus zwei echte Screenshots aus dem JavaScript-Rendering-Test, damit die „8/8 dynamisch“-Aussage nicht nur eine Zahl auf einer Seite bleibt.
Aufgabe eins: eine Seite in LLM-tauglichen Text verwandeln
Wenn du sauberes Markdown für eine RAG-Pipeline brauchst, konkurrieren drei Tools miteinander – und sie könnten unterschiedlicher kaum gebaut sein.
Crawl4AI ist unter der Marketingoberfläche im Kern ein browsergestützter Markdown-Generator. Die Story vom „adaptiven, selbstlernenden Selector“ sollte man sich nicht zu sehr zu Herzen nehmen: So etwas bringt das Tool nicht mit – das ist ein Trick einer anderen Bibliothek (dazu später bei Scrapling mehr). Was es tatsächlich macht, macht es gut. Auf der Übungsseite Books to Scrape lieferte es 13.476 Zeichen Markdown, es beherrscht CSS-Schema-Extraktion für strukturierte Pulls, und sein integriertes BFS-Deep-Crawling lief über 5 Seiten im Crawl-Graph-Test, während gleichzeitig eine JavaScript-Seite gerendert und ein Screenshot aufgenommen wurde. Zwei echte Schwachpunkte gibt es aber. Das rohe Markdown enthält den Boilerplate der Seite, solange man keinen Content-Filter aktiviert, und der absichtlich provozierte 500er kam als success=false zurück – nicht weil Crawl4AI den HTTP-Fehler sauber erkannt hätte, sondern weil seine eigene Content-Heuristik auf den kleinen Fehlertext schaute und ihn als minimal_text ... blocked einstufte. Außerdem landen beim Setup gleich zwei Browser-Stacks auf deiner Platte. Version 0.9.0, Apache-2.0, Anfang Juli ungefähr 71k Sterne.
Firecrawl ist das Schwergewicht, und Self-Hosting funktioniert hier tatsächlich – „tatsächlich“ betone ich, weil der Stack aus sechs Containern (api, playwright-service, redis, rabbitmq, nuq-postgres und foundationdb) wirklich hochkam und aus derselben Books-to-Scrape-Seite 9.222 Zeichen LLM-taugliches Markdown erzeugte. Es rendert eine JavaScript-Seite über den mitgelieferten playwright-service, und das nachgeladene Einstein-Zitat erschien im Output – ein klarer Beweis, dass das Rendern echt war. Zwei Haken, auf die ich gestoßen bin, lagen nicht an Firecrawl selbst, und ich will das sauber trennen, damit niemand die falsche Lösung übernimmt: Ein Build aus den Quellen lief in colima in einen containerd-Snapshotter-Fehler, also bin ich auf die vorgebauten Images ausgewichen. Und colimas 198.18.x.x-DNS-Bereich löste Firecrawls SSRF-Schutz aus, was ich mit ALLOW_LOCAL_WEBHOOKS=true behoben habe – ein Workaround für lokale Entwicklung, nichts, was man in einer echten Produktionsumgebung abschalten sollte. Der selbst gehostete Kern bringt außerdem kein Fire-Engine mit, also die Anti-Block-Cloudschicht, und ich habe die Cloud-API nicht getestet. Das größere Warnsignal ist die Lizenz: Der selbst gehostete Kern von Firecrawl steht unter AGPL-3.0, was vor jeder kommerziellen Nutzung echte juristische Prüfung verlangt und keine Nebensache ist. Anfang Juli lagen die Sterne bei rund 148k.
trafilatura ist der Gegenentwurf in dieser Runde – und genau das Tool, das in den AI-Hype-Listen ständig vergessen wird. Kein Browser. Keine strukturierten Zeilen. Nur schneller, sauberer Artikeltext in reinem Python. Beim Artikel-Setup holte es den Titel plus alle 3 von 3 echten Absätzen, entfernte den Boilerplate komplett – nichts wie „Login“, „Subscribe“ oder „Copyright“ rutschte durch – und erfasste zusätzlich Autor und Datum. Auf einer öffentlichen Produktseite lieferte es 1.324 Zeichen klaren Text. Seine Grenze ist exakt die, die seine Architektur nahelegt: Wenn du es auf einen Katalog ansetzt, bekommst du 12 Produktnamen als Text, aber 0 strukturierte Zeilen – der Text ist da, die Struktur nicht, und JavaScript rendert es gar nicht. Version 2.1.0 (aktuelle Release), Apache-2.0, etwa 6,2k Sterne. Für reine Artikel-Extraktion wäre das mein erster Griff.
Diese beiden Markdown-Zahlen – 13.476 von Crawl4AI, 9.222 von Firecrawl – stammen von derselben öffentlichen Seite, aber bitte nicht als Qualitätsabstand lesen. Sie spiegeln unterschiedliche Markdown-Strategien wider (also wie viel Seitengerüst jeweils mitgenommen wird), nicht ein Urteil darüber, welches Ergebnis „besser“ ist. Genau das ist die Regel mit den toolinternen Signalen von oben, nur diesmal offen sichtbar.
Aufgabe zwei: JavaScript zuverlässig rendern
Manche Daten sind im HTML schlicht noch nicht vorhanden, bevor Skripte gelaufen sind – und genau dann ist ein echter Browser keine Option mehr, sondern Pflicht. Drei Tools decken diese Aufgabe ab, und zwei davon erwiesen sich fast als dasselbe Tool.
Playwright und Puppeteer lagen in jedem Test gleichauf. Beide renderten 8/8 dynamische Produkte auf dem lokalen Testfall und 10 auf der öffentlichen Quotes-JS-Seite, beide kamen bei statischen Seiten auf 12/12 Recall, und beide gingen mit dem 500er sauber um (Puppeteer gibt dabei ein Response-Objekt zurück statt eine Exception zu werfen). Keines der beiden bringt eine Crawl-Queue mit, daher brauchte jedes eine per Hand geschriebene BFS, um den 12-seitigen Link-Graphen zu durchlaufen. Der einzige echte Unterschied ist die Reichweite: Playwright steuert Chromium, Firefox und WebKit an und spricht Python und .NET, während Puppeteer klar Chrome-first und nur für Node gedacht ist. Zwei Hinweise zu den Versionen, weil sich hier viel schnell bewegt: Ich habe Playwright 1.56.0 gegen die aktuelle 1.61.1 getestet und dabei nur Chromium genutzt; Puppeteer 24.16.0 gegen die aktuelle 25.3.0 – bitte entsprechend erneut testen oder das Ergebnis entsprechend einordnen. Beide Apache-2.0; ungefähr 92k bzw. 95k Sterne.
Crawlee ist das Tool, das das Queue-Problem löst, das die beiden anderen offenlassen. Es kapselt eine Cheerio-Engine (HTTP) und eine Playwright-Engine (Browser) hinter einer gemeinsamen API, und der Unterschied auf einer einzigen Seite ist schon die ganze Pointe: Die Cheerio-Engine sah 0 per JavaScript eingefügte Elemente, die Playwright-Engine sah lokal 8/8 (und 10 auf der öffentlichen Seite), und der Wechsel zwischen beiden ist eine Ein-Zeilen-Änderung. Dazu kommt eine echte RequestQueue, und genau deshalb gehört es in diese Aufgabe statt in Aufgabe drei. Der Haken, den niemand in die Überschrift schreibt: Die Browser-Engine braucht zusätzlich npx playwright install – rund 80 MiB, die npm install crawlee dir nicht automatisch mitbringt. Version 3.17.0, TypeScript, Apache-2.0, etwa 24,6k Sterne.
Aufgabe drei: schnell crawlen, ohne Browser
Wenn auf der Seite kein JavaScript gebraucht wird, ist ein Browser schlicht unnötig teuer. Drei HTTP-first-Tools treten hier gegeneinander an, jedes aus einer anderen Sprachphilosophie heraus, und sie unterscheiden sich auf interessante Weise.
Scrapy ist das Werkzeug auf Engineering-Niveau: Spiders, Feed-Export nach JSON/CSV/XML, AutoThrottle und alles, was dazugehört. Es erreichte 12/12 statischen Recall, holte 3/3 Absätze des Artikels, lief über 11 Seiten auf dem Crawl-Graphen in den Tiefen 0 bis 2 und fing den 500er über handle_httpstatus_list ab. Das Interessante ist seine Denkweise: Es rendert nicht, sondern rekonstruiert die Anfrage. Auf die JavaScript-Seite angesetzt, bekam es 0 Nodes – und dann lieferte die dahinterliegende JSON-API 8/8 zurück. Genau das ist die Scrapy-Philosophie in einem Datenpunkt: Finde die Anfrage, die die Seite selbst macht, und spiele sie nach – statt einen Browser zu fahren. Der Preis ist ein recht großer Dependency-Stack (Twisted, lxml, parsel), und ich habe es nur gegen kleine Testfälle geprüft. Version 2.17.0, BSD-3-Clause, ungefähr 63k Sterne.
Colly ist die Go-Antwort darauf, und es ist angenehm direkt darin, was es ist: ein einziges statisches Binary, callback-gesteuert über OnHTML, OnResponse und OnError, mit Tiefenkontrolle. Es traf 12/12 beim statischen Recall, holte über OnResponse 8/8 aus der JSON-API, fing den 500er über OnError ab und erreichte bei einem Crawl mit Tiefe 2 17 Seiten – und ich formuliere es genau so, weil diese Seitenzahl die Zählung des Test-Harness ist, nicht irgendeine Vollständigkeitsgarantie von Colly. Was es nicht kann, ist JavaScript: Der dynamische Testfall und die Quotes-JS-Seite kamen beide auf 0, absichtlich. Zum Bauen brauchst du eine Go-Toolchain, und die Modulfassung (v2.3.0) liegt derzeit vor dem getaggten Release (v2.2.0). Apache-2.0, etwa 25k Sterne.
Scrapling ist der Spezialist, und das Label ist verdient. Seine adaptiven Selektoren sind dafür gebaut, ein Element nach Markup-Änderungen wiederzufinden – als ich also die HTML-Klasse eines Ziels von product-name in product-title umbenannt habe, traf ein normaler Selector 0, während das adaptive Re-Match das verfolgte Element trotzdem zurückholte. Bei reiner HTTP-Extraktion erreichte es 12/12 statisch und 8/8 auf der JSON-API. Was die eigene Doku nicht verschweigt: In einem synthetischen Multi-Element-Test fand es 1 von 3 wieder – das ist robustes Element-Tracking, keine vollständige Wiederherstellung, also bitte nicht zu großzügig interpretieren. Für den Basis-Start braucht auch pip install scrapling noch das Extra [fetchers], und sein StealthyFetcher ist eher ein Compliance-Hinweis als ein Feature, das ich auf eine Folie setzen würde. Version 0.4.10 (aktuelle Release), BSD-3-Clause, rund 68,7k Sterne.
Das Muster hinter den drei Aufgaben
Legt man alle neun nebeneinander, wird etwas Schönes sichtbar. Vollständiger statischer Recall – flache 12/12 – ist für jedes HTTP-first-Tool Pflichtprogramm; niemand hat die leichte Aufgabe vergeigt, also ist das kein Unterscheidungsmerkmal. Die Browser-Tools rechtfertigen ihr Zusatzgewicht nur dann, wenn wirklich JavaScript im Spiel ist, und dafür zahlen sie immer mit Setup-Aufwand: Browser-Stack, Zusatzinstallation oder gleich eine ganze Container-Flotte. Und die Spalte „Built-in crawl queue“ ist im Grunde die Grenze zwischen Framework und Engine – Scrapy und Crawlee bringen die Orchestrierung mit, während Playwright und Puppeteer dich die BFS selbst schreiben lassen. So sieht das Feld aus. Niemand gewinnt insgesamt, weil niemand dasselbe Spiel spielt.
Welches Tool solltest du also tatsächlich wählen?
Der Testkranz verweigert eine Siegerkrone, weil die richtige Antwort kein Tool ist, sondern eine Frage: Welche der drei Aufgaben erledigst du gerade?
- Du brauchst LLM-taugliches Markdown? Nimm trafilatura, wenn du sauberen Artikeltext willst; Crawl4AI, wenn du CSS-Extraktion und JavaScript-Rendering in einer Bibliothek brauchst; und Firecrawl, wenn du ausdrücklich einen selbst gehosteten Dienst willst und sowohl die AGPL-3.0-Lizenz als auch das Gewicht von sechs Containern akzeptieren kannst.
- Du brauchst gerendertes JavaScript? Playwright oder Puppeteer für das reine Rendering – wähle nach Engine und Sprache, denn sonst sind sie praktisch gleichauf – und Crawlee, wenn du zusätzlich die Crawl-Orchestrierung nicht selbst bauen möchtest.
- Du willst statische Seiten oder reproduzierbare APIs in großem Stil crawlen? Scrapy für ein vollständiges Python-Framework, Colly für rohe Go-Geschwindigkeit in einem einzigen Binary, und Scrapling, wenn dir Markup-Drift regelmäßig das Leben schwer macht.
Ordne das Tool der Aufgabe zu, und jedes einzelne davon ist eine vertretbare Wahl. Nimm die falsche Kategorie – ein Browser-Tool für statische Seiten oder einen HTTP-Parser für eine JavaScript-App – und selbst die bestbewertete Library im Netz wird dich enttäuschen.
Wo stattdessen eine gemanagte KI-API ins Bild kommt
Jedes der obigen Tools ist kostenlos, Open Source und kann von dir selbst betrieben werden. Genau das ist auch der gemeinsame Preis, den der Test immer wieder sichtbar macht: Du verantwortest die Browser-Umgebung, den Crawl-Code, das Wettrüsten gegen Bots und die gesamte Wartung. Für viele Teams ist genau diese Kontrolle der Punkt – und die Lizenzlage spielt eine große Rolle, wenn man sich dafür entscheidet: Der Großteil des Feldes ist permissiv lizenziert (Apache-2.0 bei Crawl4AI, Crawlee, Playwright, Puppeteer und Colly; BSD-3 bei Scrapy und Scrapling), während Firecrawls selbst gehosteter Kern unter AGPL-3.0 die eine Lösung ist, die vor kommerzieller Nutzung wirklich geprüft werden sollte.
Aber schau dir an, was der Test ebenfalls gezeigt hat: was diese Tools nicht leisten. Rendern, crawlen, strukturieren und von Blockaden wegrotieren – selten alles zusammen und nie ohne Wartungsaufwand. Eine gemanagte KI-Scraping-API packt diesen Stack in einen einzigen Aufruf. Unsere eigene Entwickleroberfläche bei Thunderbit ist hier eine Option, und für ein technisches Publikum zählen vor allem die API, der MCP-Server und die CLI – nicht die Browser-Erweiterung. POST /distill liefert sauberes Markdown, und POST /extract gibt schema-definiertes JSON zurück; JavaScript-Rendering und Anti-Bot-Behandlung laufen dabei serverseitig und nicht auf deinem Rechner. Es gibt außerdem einen offiziellen MCP-Server für Agents und Coding-Assistenten – thunderbit_suggest_fields ist kostenlos, um eine Extraktion zu planen, danach erledigen thunderbit_distill (1 Credit) und thunderbit_extract (20 Credits) die Arbeit – sowie eine CLI, die du mit npx @thunderbit/thunderbit-cli für Terminal- und Cron-Jobs einbinden kannst. Für Nicht-Entwickler im Team gibt es zusätzlich eine No-Code-Chrome-Erweiterung, und die Preise decken beide Einsatzdimensionen ab.
Der Kompromiss ist derselbe, um den sich der gesamte Test dreht: Entweder betreibst und wartest du bis zu neun Bibliotheken selbst und zahlst pro Aufruf nichts, oder du gibst das Drumherum ab und zahlst pro Anfrage. Keiner der beiden Wege ist falsch. Es kommt darauf an, wie viel vom Stack du wirklich selbst besitzen willst. Wenn du lieber sehen möchtest, wie die Extraktion in der Praxis aussieht, zeigt dir der Thunderbit-YouTube-Kanal den Ablauf Schritt für Schritt.
{{INTERNAL_BLOG_LINKS}}
Fazit
Es gibt keinen einzelnen besten Open-Source-Scraper, und jede Liste, die dir selbstbewusst einen nennt, verschweigt die eigentliche Frage: Welche der drei Aufgaben willst du lösen? Eine Seite in Text verwandeln, JavaScript rendern oder schnell ohne Browser crawlen – das Feld sortiert sich sauber in diese drei Kategorien, und innerhalb jeder Kategorie hängt die Wahl von Sprache und Setup-Aufwand ab, nicht von einem universellen Champion.
Wenn du dir aus diesem Artikel nur eine Angewohnheit mitnimmst, dann diese: Teste auf deinen eigenen Seiten, bevor du dich festlegst. Jede Zahl hier ist im Benchmark-Repo reproduzierbar – genau aus diesem Grund: Das Tool, das in einem generischen Vergleich vorne liegt, und das Tool, das deine echten Ziele überlebt, sind nicht immer dieselben.
Thunderbit für Web-Datenextraktion ausprobieren Get Started Free
FAQs
Was ist der beste Open-Source-Web-Scraper? Einen einzigen gibt es nicht – es hängt von der Aufgabe ab. Für LLM-tauglichen Text sind trafilatura oder Crawl4AI stark; für JavaScript-Rendering Playwright, Puppeteer oder Crawlee; für schnelles HTTP-Crawling Scrapy oder Colly. Auf einem gemeinsamen Prüfstand war jedes Tool in seiner eigenen Kategorie am stärksten und außerhalb davon deutlich schwächer – genau deshalb führen Einheits-Rankings in die Irre.
Welche Open-Source-Scraper rendern JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer und die Playwright-Engine von Crawlee rendern JavaScript. Scrapy, Colly, trafilatura und der Standard-HTTP-Fetcher von Scrapling tun das nicht – sie brauchen entweder eine reproduzierbare API hinter der Seite (Scrapys Ansatz, der auf dem JSON-Endpunkt 8/8 erreichte) oder einen separaten Browser-Modus.
Brauche ich einen Headless-Browser, um eine Website zu scrapen? Nur dann, wenn die Daten erst nach dem Ausführen von JavaScript erscheinen. Wenn ein normaler HTTP-Request zusammen mit einem Parser an die Inhalte kommt, ist ein Browser teurer Overkill – in diesem Fall sind Scrapy, Colly oder Scrapling deutlich leichter und schneller.
Welche dieser Lösungen hat die freundlichste Lizenz für kommerzielle Nutzung? Die meisten sind permissiv: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) oder BSD-3-Clause (Scrapy, Scrapling). Die Ausnahme ist Firecrawls selbst gehosteter Kern, der unter AGPL-3.0 steht und vor einem kommerziellen Produkt ernsthaft geprüft werden sollte.
Sind diese Benchmark-Zahlen reproduzierbar? Ja. Jeder Runner, jedes Fixture und jedes Rohresultat liegt in einem öffentlichen MIT-lizenzierten Repo. Die eine Einschränkung: Recall- und Strukturwerte sind toolübergreifend vergleichbar, absolute Zeichenzahlen aber nur als Signal innerhalb eines Tools, weil jedes Paket die Fixtures spiegelt statt eine einzige kanonische Kopie zu teilen – also bitte Raten und Pass/Fail vergleichen, nicht rohe Zeichenzahlen.
