Botasaurus-Test: 4-MB-Treiber, 122-MB-Installation und die 0,08-ms-Zahl, die Sie nicht zitieren sollten

Botasaurus ist ein Python-Web-Scraping-Framework von Omkar Cloud, das sich als Komplettlösung für den Aufbau von Scrapern positioniert. Du schreibst eine einfache Funktion, versiehst sie mit @browser, @request oder @task, und das Framework setzt automatisch einen Browser-Treiber, einen browserähnlichen HTTP-Client, Caching, Parallelisierung und Ausgabe in mehreren Formaten darum herum auf. Es ist ein Meta-Paket, und genau das ist der entscheidende Punkt: pip install botasaurus installiert nicht einfach nur eine Bibliothek in deiner Umgebung, sondern ein kleines Set an First-Party-Wheels plus einen breiten transitive Baum. Dieses technische Detail war am Ende das Interessanteste, was ich sauber messen konnte.

Botasaurus wirbt stark mit Anti-Detection, und genau dieser Aspekt war in diesem Test ganz bewusst nicht Teil der Bewertung. Ich habe das Framework inventarisiert — was installiert wird, was importiert wird, welche Methoden vorhanden sind, wie groß es ist und unter welcher Lizenz es steht — statt es gegen echte Schutzmechanismen zu testen. Alle untenstehenden Footprint- und Importwerte stammen aus pip, aus python -c "import ..." und aus der Introspektion von Klassen, die zwar instanziiert wurden, aber nie angewiesen waren, eine Seite abzurufen; kein Browser wurde gestartet, um diese Werte zu erzeugen. Später habe ich Browser zwar gestartet, aber nur auf Seiten, die ich selbst geschrieben und unter 127.0.0.1 bereitgestellt habe, um zu sehen, was der Treiber über sich selbst preisgibt und ob er Inhalte von einer Seite laden kann, die sich per JavaScript selbst zusammenbaut. Es war zu keinem Zeitpunkt eine Live-Website beteiligt, kein Anti-Bot-Dienst wurde angesprochen oder vermessen, und kein CAPTCHA wurde berührt. Die Wirksamkeit gegen echte Websites ist absichtlich nicht Teil dieses Tests, und das sage ich lieber gleich offen, statt einen benchmark zu suggerieren, den ich gar nicht gefahren bin.

Mit dieser klaren Abgrenzung ist die Hauptaussage zuerst eine Frage des Footprints — und zwar eine recht unspektakuläre. Eine saubere Installation erzeugt ein site-packages-Verzeichnis von 122,3 MB über 44 Pakete hinweg, auf einem Rechner, auf dem der Browser-Treiber im Zentrum der ganzen Sache rund 4 MB groß ist. Das Framework ist nicht schwer, weil der Treiber schwer ist; es ist schwer, weil „all in one“ bedeutet, dass numpy, lxml, gevent und ein Dutzend weitere Komponenten für eine Aufgabe mitgebracht werden, die eigentlich nur HTML abrufen soll. Und die zweite Hälfte der Erkenntnis ist eine Zahl, die gern als Tugend verkauft wird, der man aber nicht blind vertrauen sollte: import botasaurus braucht 0,08 ms — das klingt nach einem federleichten Framework, ist in Wahrheit aber nur eine fast leere Eingangstür.

Was Botasaurus eigentlich ist

Botasaurus — auf GitHub omkarcloud/botasaurus, mit 5.561 Stars, 486 Forks und 58 offenen Issues zum Zeitpunkt meiner Metadatenabfrage am 14. Juli 2026 — ist ein Python-Framework und keine Einzelbibliothek für einen Spezialzweck. Die getesteten Versionen waren botasaurus 4.0.97 für das Meta-Paket und botasaurus-driver 4.0.92 für die darunterliegende Engine. Das Meta-Paket verlangt requires-python >=3.7 (der Driver >=3.5), und die PyPI-Classifier nennen Unterstützung nur bis Python 3.11. Auf meinem Rechner ließ es sich unter Python 3.14.2 installieren und bestand dort auch den Import-Smoke-Test. Das sagt etwas über genau diese Installation aus, ist aber keine allgemeine Kompatibilitätsgarantie für jede Funktion.

Die Kategorie ist wichtig, weil sie definiert, was „gut“ überhaupt bedeutet. Botasaurus gehört klar auf die Framework-Seite des Spektrums, also in die Nähe von Scrapy und Crawlee — man übernimmt Struktur, Decorators und Konventionen und bekommt im Gegenzug die gesamte Infrastruktur verwaltet. Das ist etwas anderes als ein fokussierter Treiber wie nodriver, der einfach eine Chrome-DevTools-Protocol-Verbindung bereitstellt und sich dann zurückzieht. Botasaurus bringt zwar einen Treiber mit (botasaurus-driver), verpackt ihn aber in einen Task-Runner, eine Caching-Schicht, Output-Serializer und einen Request-Client. Du kaufst also nicht nur einen Treiber, sondern einen klar vorgeprägten Workflow mit Treiber im Inneren.

Die drei Decorators bilden das Design im Kleinen ab, und alle drei Einstiegspunkte sind real — ich habe bestätigt, dass botasaurus.browser.browser, botasaurus.request.request und botasaurus.task.task existieren und importierbar sind. @browser führt deine Funktion gegen den humanisierten Browser-Treiber aus. @request nutzt einen leichten HTTP-Client, der browserähnlich wirkt. @task ist der generische Wrapper für alles, was nicht eindeutig in die ersten beiden Kategorien fällt. Decorator drauf, und Botasaurus liefert die umgebende Mechanik gleich mit: parallele Ausführung, Wiederverwendung des Treibers, Ergebnis-Caching und Writer für JSON, CSV, Excel und HTML. Das ist ein stimmiges Konzept. Ob du so viel Framework um einen Scraper herum brauchst, ist die eigentliche Frage — und das ist eine Geschmacksfrage, kein Defekt.

Mein Fazit und die Grenze dieses Tests

Botasaurus ist kompetent, gut geschnitten und erfüllt genau das, was Frameworks leisten sollen: Es macht den Standardfall kurz. Das Decorator-Modell ist sauber. Die MIT-Lizenz ist tatsächlich großzügig. Die Installation läuft ohne Drama. Wenn ich die Ergonomie der API bewerten müsste, würde sie ordentlich abschneiden.

Worauf ich immer wieder zurückkomme, ist, dass der eigentliche Hauptclaim des Frameworks — Anti-Detection — genau der Punkt ist, zu dem ein verantwortungsvoller Test keine Aussage machen sollte, ohne es gegen Produktionsschutzmechanismen einer anderen Partei zu halten. Der Treiber bringt zwar eine ausdrücklich auf Anti-Detection ausgerichtete API-Oberfläche mit: Methoden, deren Existenz ich bestätigt habe, deren Verhalten ich aber gegen kein Ziel getestet habe. Mehr werde ich dazu nicht behaupten. Ich habe ihn nicht auf eine geschützte Seite losgelassen, keine Erfolgsquote gemessen, keinen Mechanismus reverse-engineert und werde durch Formulierung auch nichts davon implizieren. Die Methoden sind in der Klasse vorhanden. Was sie in freier Wildbahn leisten, ist ein anderer Test — dieser hier nicht.

Was folgt, ist also ein Inventar zu Fähigkeiten, Installation, Ressourcen und Lizenz sowie das, was der Treiber auf einer Seite zeigt, die ich selbst kontrolliere — eine deutlich schmalere Aussage als in den meisten Reviews dieses Werkzeugs, und genau diese Schmalheit ist der Punkt.

Was das Tool über sich selbst verrät

Hier ist eine Frage, die du beantworten kannst, ohne dich einer echten Verteidigung zu nähern: Was gibt ein Browser preis, wenn Botasaurus ihn steuert? Ich habe eine Seite gebaut, die die offensichtlichen Dinge ausliest — navigator.webdriver, User-Agent, Plattform, Sprachen, Plugin- und Hardware-Zähler, die Form von window.chrome, die Aussagen der Permissions API sowie Fenster- und Bildschirmgeometrie —, sie unter 127.0.0.1 ausgeliefert und vier Stacks darauf angesetzt: Botasaurus, nodriver sowie die Standardversionen von Playwright und Puppeteer als Kontrollgruppe. Alle vier steuerten dieselbe Chrome-Build-Version (Chrome for Testing 151.0.7922.10), also sind alle Unterschiede auf die jeweilige Bibliothek zurückzuführen, nicht auf den Browser. Getestet jeweils headless und headed, mit drei Durchläufen pro Modus. Alle unten genannten Werte blieben in allen drei Runs gleich.

Welche Unterschiede du siehst, hängt davon ab, welche Kontrollgruppe du heranziehst. Gegenüber dem Standard-Puppeteer änderte Botasaurus navigator.webdriver; die Sprachliste und die Fenstergeometrie mit Nullgröße blieben gleich, während sich der User-Agent nur in der Versionsformatierung unterschied. Gegenüber dem Standard-Playwright kamen zusätzlich Unterschiede in Sprachliste und Fenstergeometrie hinzu. Gegenüber nodriver stimmten der Boolean und die Sprachen überein; nur das User-Agent-Format unterschied sich in den hier gezeigten Feldern. Das sind Beobachtungen zur Standard-Offenlegung, kein Anti-Detection-Score.

Zwei Details machen diese Beobachtung interessanter als das nackte false. Das erste ist, wie der Wert zustande kommt. In allen vier Stacks ist die Eigenschaft weiterhin der native Getter des Browsers auf Navigator.prototype — function get webdriver() { [native code] } —, niemals eine Own-Property auf der Instanz und niemals eine ersetzte Funktion. Botasaurus überschreibt die Eigenschaft also nicht nach dem Laden der Seite; der Wert wird beim Start des Browsers festgelegt, und die Eigenschaft selbst bleibt unberührt.

Der zweite Punkt relativiert das Marketing. Im Headless-Modus kündigt sich Botasaurus im User-Agent weiterhin als HeadlessChrome/151.0.0.0 an — identisch zu Standard-Puppeteer und Standard-Playwright. Im headed-Modus wird daraus Chrome/151.0.0.0, ebenfalls identisch. Der Driver-Konstruktor akzeptiert zwar einen user_agent-Parameter; einen eigenen User-Agent zu setzen ist also nur einen Keyword-Argument entfernt. Aber die Standardkonfiguration verschleiert die berühmteste Selbstbezeichnung in der Browserautomation nicht.

Fast alles andere war über alle vier Stacks hinweg gleich, und das muss man klar sagen, weil es die Geschichte einengt — jedes der folgenden Felder war auf Botasaurus, nodriver, Playwright und Puppeteer identisch:

Der altbekannte Widerspruch zwischen Permissions API und Notification.permission tauchte nirgends auf — alle vier meldeten übereinstimmend default und prompt. Ich habe außerdem document und window nach den alten cdc_-Rückständen durchsucht, die von älteren WebDriver-Stacks bekannt waren: in allen vier Fällen war dort nichts zu finden.

Noch etwas ist vor einem Einsatz wichtig: Trotz seiner 122 MB bringt Botasaurus keinen Browser mit und lädt auch keinen nach. find_chrome_executable() verweist einfach auf den Chrome, der auf dem System bereits vorhanden ist — auf meinem Rechner /Applications/Google Chrome.app, Version 150.0.7871.187 — und genau diese Version gibt der User-Agent dann auch preis. Ihre Flotte meldet also jeweils den Chrome, der in Ihrer Umgebung installiert ist. Für ein so meinungsstarkes Framework ist das ein überraschend unaufgeregter Standard.

Sagen wir es klar: Das hier ist ein Protokoll dessen, was ein automatisierter Stack offenlegt, wenn niemand ihn gebeten hat, sich zu verstecken — nützlich für die Verteidigungsseite und nützlich, wenn du wissen willst, was dein eigenes Tooling sendet. Es ist kein Maß dafür, ob das für einen bestimmten Dienst relevant ist. Das habe ich nicht getestet, und keine der obigen Zeilen sollte so gelesen werden, als würde sie ein Ergebnis behaupten.

Ein großzügigerer Blick auf dieses Test-Fixture

Sich selbst ankündigen ist das eine; das richtige HTML zurückzugeben ist die eigentliche Aufgabe. Ich habe Botasaurus gegen dasselbe Drei-Klassen-Fixture laufen lassen, das auch für den Rest dieses benchmark-Repos verwendet wird, damit die Zahlen mit allen anderen hier gemessenen Tools vergleichbar sind. Die Seite enthält drei Dinge: A, einen statischen Link, dessen Marker als Literal in den gelieferten Bytes steckt; B, einen Knoten, der beim Parsen per Inline-Skript erzeugt wird, wobei Marker und URL aus Fragmenten zusammengesetzt werden, sodass nur das Ausführen des JavaScripts sie sichtbar macht; und C, einen Knoten, der 800 ms nach dem Load-Event eingefügt wird und auf dieselbe Weise zusammengesetzt ist. Klasse C ist die adversarielle Komponente — ein Abruf direkt zum Load-Event kann sie nicht sehen.

Botasaurus landet dort, wo auch die Schwergewichte landen. driver.get() gefolgt direkt von driver.page_html ist ein Snapshot zum Zeitpunkt des Ladens: JavaScript wird korrekt gerendert — Klasse B beweist das, denn Klasse B kommt in den gelieferten Bytes überhaupt nicht vor —, aber bei einer Verzögerung von 800 ms verfehlt er Klasse C. Mit driver.wait_for_element("#delayed-injected") bekommst du alle drei. Das war über drei Wiederholungen und drei komplette Läufe der gesamten Suite stabil, ohne Flakes.

Interessant wird es, wenn man die Einfügeverzögerung variiert, um zu sehen, wann der Standard-Abruf der einzelnen Stacks aufgibt:

Alle anderen Stacks verlieren Klasse C sofort, sobald die Einfügung 100 ms oder später nach dem Laden passiert. Botasaurus erwischt sie noch bei 300 ms und gibt erst bei 400 ms auf. Das ist das Framework-Verhalten eines Frameworks, und die Ursache steht direkt im Konstruktor: wait_for_complete_page_load=True ist der Standard, also kehrt get() spürbar später zurück als ein nacktes Load-Event. Konkret kostet dieser Standard-Abruf 401–431 ms Wall-Clock-Zeit, während nodriver bei 119–129 ms und Puppeteer bei 125–171 ms liegt.

In diesem lokalen Fixture mit verzögertem Einfügen lag der Trade-off bei rund 250 ms pro Navigation für einen späteren Standard-Snapshot. Das fing in diesen Läufen Inhalte ab, die bis zu 300 ms nach dem Load-Event eingefügt wurden; daraus folgt aber nicht, dass Botasaurus auf beliebigen Seiten grundsätzlich korrekter ist. Wenn du schnelle Scraper ohne explizite Wait-Bedingungen schreibst, kann der Puffer einen späten Knoten vor dem Übersehen retten. Bei hohem Navigationsvolumen oder wenn du ohnehin auf eine präzise Bedingung warten willst, ist es schlicht Overhead.

Noch zwei Timing-Werte zur Einordnung. Das Hochfahren des Browsers liegt bei Botasaurus ungefähr auf Augenhöhe mit nodriver und Puppeteer und klar hinter Playwright:

Und wait_for_element() kostet bis zu einer Verzögerung von 300 ms praktisch nichts extra — get() ist da ohnehin schon über den Einfügezeitpunkt hinausgekommen —, steigt dann aber auf etwa 1,42 s bei 400–800 ms und 2,43 s bei 1500 ms.

Die Frage nach den 122 MB: Was ein Meta-Paket tatsächlich installiert

Hier kommt die Rechnung, denn das ist die nützlichste Zahl, die ich dir geben kann. Eine saubere pip install botasaurus-Installation in einer frischen virtuellen Umgebung erzeugte einen site-packages-Baum von 122,3 MB über 44 Dist-Info-Pakete hinweg. Wenn man pip selbst herausnimmt (10,9 MB, also Venv-Overhead und nicht etwas, das Botasaurus verlangt hat), bleiben rund 111 MB Framework plus Abhängigkeiten. Der Browser-Treiber — die Komponente, die die eigentliche Browserautomation übernimmt — macht davon ungefähr 4 MB aus. Also sind rund 107 MB alles andere, was das Meta-Paket für notwendig hielt.

Wohin geht das? Die fünf größten transitive Abhängigkeiten machen allein schon den Großteil aus (jede Zeile ist ein Eintrag aus install_footprint.heaviest_deps_mb in artifacts/raw/runs/resource_baseline.run1.json; die Gesamtsumme ist meine Berechnung, kein Feld in der Datei):

Dass numpy der größte Einzelposten ist, ließ mich kurz die Augenbraue heben — das ist eine Lineare-Algebra-Bibliothek in einem Tool, dessen Aufgabe das Abrufen und Parsen von Webseiten ist. Falsch ist das nicht unbedingt; Frameworks sammeln Utility-Abhängigkeiten an, und offenbar will irgendetwas im Baum mit Array-Mathematik arbeiten. Es ist nur eine ganze Menge Maschine für eine vergleichsweise kleine Aufgabe.

Zur Einordnung: Der fokussierte Treiber nodriver liegt auf demselben Rechner bei etwa 17,2 MB über 6 Pakete hinweg — also grob 7x leichter. (Diese Zahl stammt nicht aus diesem Paket, sondern aus install_footprint.site_packages_total_mb in nodrivers eigenem artifacts/raw/runs/resource_baseline.run1.json, gemessen in einem separaten gestaffelten Lauf auf demselben Host; 122,3 ÷ 17,2 = 7,1.) Keine der beiden Zahlen ist ein Defekt, und das ist kein Fähigkeitsranking; es ist der mechanische Kostenunterschied zwischen einem „Batteries included“-Framework und einem fokussierten Treiber. In einem Container zählt der gemessene site-packages-Footprint zur Anwendungsschicht. Das ist nicht die komplette Imagegröße, und dieser Test hat weder Build- noch Cold-Deploy-Zeit gemessen.

Noch ein Footprint-Aspekt: Beim Introspektieren löste die erste Verwendung von from botasaurus.request import request einen einmaligen Download von etwa 12,8 MB aus. Der aufgezeichnete Lauf hat das Artefakt und das Ziel nicht sauber genug identifiziert, um diese Zahl als stabilen Zusatz zum Installations-Footprint zu behandeln. Es zeigt aber, dass dieser Codepfad beim ersten Einsatz Netzwerkzugriff benötigen kann — etwas, das du in deinem eigenen Image einmal nachstellen solltest, bevor du in eine air-gapped Umgebung gehst.

Die Import-Zahl, die lügt

Beim Cold-Start-Import wird eine naive Lesart der Zahlen irreführend. Über sieben frische Subprozess-Imports hinweg lag import botasaurus auf Top-Level bei einem Median von 0,08 ms. Wer das isoliert zitiert, bekommt den Eindruck, es sei das leichteste Framework der Kategorie.

Ist es aber nicht. Es ist nur so schnell, weil dort fast nichts passiert. Das Top-Level-Paket botasaurus stellt kein __version__ bereit und besitzt praktisch keinen öffentlichen Namespace — beim Import wird fast keine Arbeit verrichtet, weil auch fast nichts enthalten ist. Die Zahl, die für ein CLI-Tool oder einen Serverless-Cold-Start wirklich zählt, ist der Import der Engine: from botasaurus_driver import Driver liegt bei etwa 135 ms, mit nur wenigen Millisekunden Schwankung über die Läufe. Das ist die reale feste Startkosten, bevor überhaupt eine einzige Seite abgerufen wird. Und sobald das Driver-Modul importiert ist, liegt der resident memory bei etwa 29–30 MB — ebenfalls noch bevor ein Chrome-Prozess existiert. Startest du einen echten Browser, wächst das deutlich; Speicher mit laufendem Browser habe ich nicht gemessen, also nenne ich dafür keine Zahl.

Die Lehre ist klein, aber deutlich: Dass import botasaurus sofort zurückkommt, liegt daran, dass das Top-Level-Paket leer ist — nicht daran, dass das Framework billig wäre. Wenn du einen Cold-Start dimensionierst, messe genau den Import, auf den du dich auch wirklich verlassen wirst.

API-Form: 99 Methoden hinter einer fast leeren Eingangstür

Die Driver-Klasse der Engine bietet 99 öffentliche Methoden — eine breite Oberfläche für Navigation, Elementabfragen, Cookies und Local Storage, Maus- und Tastaturaktionen, Screenshots, Tab-Verwaltung, CDP-Durchreichung und Datei-Uploads. Der Konstruktor nimmt 18 Parameter entgegen, also eine recht vollständige Karte der einstellbaren Oberfläche: headless, proxy, profile, tiny_profile, block_images, block_images_and_css, wait_for_complete_page_load, chrome_executable_path, extensions, arguments, user_agent, window_size, lang und einige weitere. Als API zur Konstruktion deckt sie die üblichen Steuerungsoptionen eines Browser-Wrappers ab.

Die eigentliche Überraschung liegt ganz oben in der Struktur, und sie ist harmlos, aber real. import botasaurus gibt dir einen nahezu leeren Namespace — kein __version__, praktisch keine öffentlichen Top-Level-Namen. Alles, was du tatsächlich benutzt, liegt in Submodulen: from botasaurus.browser import browser, Driver, from botasaurus.request import request, from botasaurus.task import task. Wenn du nach botasaurus.__version__ suchst, um zu protokollieren, welche Build-Version du ausführst, wirst du nichts finden; dafür musst du importlib.metadata bemühen. Das bricht nichts. Es ist nur nicht die Struktur, die Python-Entwickler aus dem Reflex heraus erwarten, und das Wissen darum spart dir am ersten Tag fünf verwirrte Minuten.

Eine Beobachtung zu den früher markierten Methoden ist innerhalb meiner Abgrenzung fair: Von den Anti-Detection-benennten Methoden, die existieren, tragen nur 2 überhaupt einen Docstring im Code. Der Rest erklärt sich nur über den Namen, während die ausführlichere Dokumentation auf der externen Doku-Seite statt im installierten Quellcode liegt. Das ist eine Aussage über die Nähe der Dokumentation, kein Qualitätsurteil — viele gute Bibliotheken halten ihre Prosa-Doku bewusst außerhalb des Codes —, aber wenn dein Arbeitsstil lautet „erst Quelltext lesen, dann verstehen“, sagt dir ein Großteil dieser Oberfläche nur den Namen, nicht das Verhalten.

Lizenz: MIT, bis hinunter zum Treiber

Sowohl das Meta-Paket als auch botasaurus-driver stehen unter MIT und tragen den üblichen Classifier License :: OSI Approved :: MIT License. MIT ist permissiv: keine Copyleft-Pflicht, keine Verpflichtung, den eigenen Code offenzulegen, und wenig Reibung für den kommerziellen Einsatz. Das ist ein echter und nicht triviale Unterschied zu nodriver, dem benachbarten Anti-Detect-Treiber, der unter AGPL-3.0 ausgeliefert wird — einer Copyleft-Lizenz, deren Netzwerk-Nutzungsklausel viele Rechtsabteilungen nervös macht. Wenn die Lizenzierung für dich ein Gate ist, spricht die MIT-Ausrichtung von Botasaurus klar für ihn.

Der Haken ist wieder die Meta-Paket-Struktur. Die permissive MIT-Lizenz gilt für die First-Party-Wheels von Botasaurus. Sie sagt aber nicht automatisch etwas über die etwa 40 transitive Pakete aus, die die Installation mitzieht, denn jedes davon bringt seine eigene Lizenz mit. Ich habe die MIT-Lizenz der von Omkar Cloud veröffentlichten Top-Level-Pakete bestätigt; ich habe jedoch nicht jede Abhängigkeit im Baum lizenziell geprüft. Für ein Hobbyprojekt ist dieser Unterschied oft egal. Für eine vollständige Einführung in einem Unternehmen, das auf seine Software-Bill-of-Materials achtet, sollte dieser 40-Paket-Baum vor der Freigabe durch den eigenen Lizenzscanner laufen — nicht, weil ich ein Problem gefunden hätte, sondern weil ich nicht hingesehen habe, und genau dort versteckt ein Meta-Paket unerwartete Lizenzen besonders gern.

Vor- und Nachteile

Vorteile:

• Sauberes Drei-Decorator-Design (@browser / @request / @task), alle drei Einstiegspunkte sind vorhanden — das Framework hält den Standardfall kurz.
• MIT-Lizenz sowohl für das Meta-Paket als auch für den Treiber, ein echter Kontrast zur AGPL-3.0 eines vergleichbaren Treibers. Permissiv, kommerziell freundlich, kein Copyleft.
• Breite Treiberoberfläche: 99 öffentliche Methoden und ein Konstruktor mit 18 Parametern für die üblichen Browser-Automation-Anforderungen.
• Installation und Import-Smoke-Tests liefen bei mir unter Python 3.14.2 und 3.12.13, also jenseits der Classifier-Liste, die bei 3.11 endet; eine allgemeine Laufzeitkompatibilität ist damit nicht bewiesen.
• Das weiteste Standard-Abruffenster von allen getesteten Stacks: Inhalte, die 300 ms nach dem Load-Event eingefügt werden, werden noch erfasst, während nodriver, Playwright und Puppeteer sie bereits bei 100 ms verlieren. wait_for_complete_page_load=True leistet dabei echte Arbeit.
• Meldet navigator.webdriver standardmäßig als false, während beide Standard-Kontrollstacks true melden — ohne die Eigenschaft zu patchen; der Descriptor bleibt der native Getter des Browsers.
• Batteries included by design — Caching, Parallelisierung, Treiber-Wiederverwendung und JSON/CSV/Excel/HTML-Ausgabe gehören zum Framework und sind keine Zusatzmodule.

Nachteile:

• Groß auf der Platte: 122,3 MB über 44 Pakete, rund 7x ein fokussierter Treiber, getrieben von Abhängigkeiten wie numpy (30,9 MB) und lxml (19,2 MB) statt vom etwa 4 MB großen Treiber selbst.
• Der beruhigende 0,08-ms-Top-Level-Import ist irreführend; der Engine-Import, auf den du tatsächlich angewiesen bist, liegt bei etwa 135 ms, und der Speicher nach dem Import bei rund 29–30 MB, noch bevor ein Browser läuft.
• Das großzügigere Standard-Abruffenster ist nicht kostenlos: 401–431 ms pro Navigate-and-Read gegenüber 119–129 ms für einen schlanken Treiber auf derselben Seite und demselben Chrome.
• Headless-Läufe kündigen sich standardmäßig weiterhin als HeadlessChrome im User-Agent an, genau wie die Standard-Kontrollen; der user_agent-Parameter im Konstruktor existiert zwar, wird aber nicht automatisch gesetzt.
• Bei 122 MB liefert das Paket trotzdem keinen Browser mit — es steuert den Chrome, der bereits auf dem Host installiert ist, also ist die offengelegte Browser-Version schlicht die, die in deiner Umgebung vorhanden ist.
• Die erste Verwendung von @request löste in diesem Lauf einen einmaligen Download von rund 12,8 MB aus; Artefakt und Ziel konnten nicht sauber genug erfasst werden, um daraus einen stabilen Footprint-Zuwachs abzuleiten.
• Das Top-Level-Paket ist fast leer und stellt kein __version__ bereit; die eigentliche API und die Versionsinformation liegen an weniger offensichtlichen Stellen.
• Die meisten anti-detection-benennten Methoden tragen keinen Docstring im Code, sodass der Quelltext Namen liefert, aber nicht das Verhalten.

Außerhalb dessen, was diese Zahlen abdecken, und daher hier ungetestet: alles zur realen Anti-Bot-Wirksamkeit (absichtlich nicht getestet), Speicherverbrauch pro Seite, Proxy- und Profilhandling, Durchsatz bei hoher Last sowie jede Plattform außerhalb von macOS arm64. Die Footprint- und Importwerte wurden ohne gestarteten Browser erhoben; die Erkennungs- und Offenlegungswerte stammen von Browsern, die ausschließlich mit einem Fixture auf 127.0.0.1 gesprochen haben.

Für wen es geeignet ist — und wer besser weiterzieht

Botasaurus passt, wenn du eher ein Framework als ein Bauteil willst. Wenn du ein Scraping-Projekt auf einer leeren Datei startest und lieber eine Struktur übernimmst, statt sie selbst zusammenzusetzen — Decorators für die Einstiegspunkte, Caching und Parallelisierung inklusive, Ausgabe-Writer bereits eingebaut —, dann ist das eine stimmige, MIT-lizenzierte Option. MIT ist permissiv, aber dein Nutzungs- und Verteilungsmodell verdient natürlich trotzdem die übliche Compliance-Prüfung. Teams, die ohnehin in Scrapy- oder Crawlee-Kategorien denken, werden sich mit dem Ansatz schnell zurechtfinden.

Sinnvoll ist Vorsicht, oder gleich ein Verzicht, wenn dein Deployment-Target besonders klein bleiben muss. Eine 122-MB-Installation mit numpy und gevent im Baum ist viel, wenn das eigentliche Ziel nur lautet: „Browser steuern und ein paar Felder ziehen.“ Ein fokussierter Treiber liefert die Automatisierung zu einem Bruchteil des Gewichts — allerdings auf Kosten der Infrastruktur, die du selbst darum herum schreiben musst. Verzichte außerdem komplett darauf, wenn du eine Entscheidung über Anti-Detection-Wirksamkeit suchst, denn genau das habe ich absichtlich nicht getestet — du würdest dann einem Marketing-Claim vertrauen, den ich weder bestätigt noch widerlegt habe.

Alternativen und wo Thunderbit hineinpasst

Die ehrliche Einordnung zuerst: Botasaurus ist kostenlos, MIT-lizenziert und self-hosted. Du betreibst die Infrastruktur, du managst Updates, und du besitzt den gesamten Abhängigkeitsbaum — alle 44 Pakete inklusive Patches, Lizenz-Compliance und allem, was numpy in einer künftigen Version machen mag. Für viele Teams ist genau diese Verantwortung gewollt, und kein Managed Service schlägt ein bereits vorhandenes Framework beim reinen Kostenpunkt.

Innerhalb von Open Source sind die sinnvollen Vergleiche formbedingt. Wenn du mit Botasaurus auf der Framework-Seite stehst, sind Scrapy und Crawlee die naheliegenden Vergleichspartner — ausgereift, meinungsstark und jeweils mit eigenen Konventionen. Wenn du lieber LLM-fähiges Markdown aus einer Seite willst statt ein Framework zur Strukturierung eines Crawlers, dann zielen Crawl4AI und das auf Inhalte fokussierte Trafilatura genau auf diesen Job. Wenn dir der Python- und Anti-Detect-Winkel gefällt, du aber etwas Leichteres als ein Meta-Paket suchst, lohnt sich ein Blick auf Scrapling; und wenn eine kompilierte Sprache infrage kommt, tauscht die Go-Bibliothek Colly JavaScript-Rendering gegen Geschwindigkeit und einen kleinen Footprint ein. Jede Browser-steuernde Option, inklusive Botasaurus, übernimmt die Kostenstruktur, die unser Vergleich zwischen Playwright und Puppeteer beschreibt — echte Browser sind nicht billig zu betreiben, und genau deshalb wiegt das Framework darum herum so viel.

An einer anderen Stelle derselben Pipeline kommt eine Managed API ins Spiel. Botasaurus ist der selbst gehostete Entwickler-Stack; Thunderbit verkauft das gemanagte Gegenstück, ebenfalls für Entwickler gedacht. Die Open API besteht aus zwei Endpunkten. POST /distill (1 Credit) gibt eine Seite als sauberes, LLM-fähiges Markdown zurück, wobei Rendering und Anti-Bot serverseitig übernommen werden — du provisionierst also weder Browser noch Abhängigkeitsbaum. POST /extract (20 Credits) liefert strukturiertes JSON auf Basis eines von dir definierten JSON Schema, mit renderMode auf none, basic oder full, je nachdem, wie viel Browser die Seite wirklich braucht. Beide Endpunkte haben Batch-Versionen für bis zu hundert URLs auf einmal. Es gibt einen MCP-Server für Agents und Coding-Assistenten — thunderbit_suggest_fields ist kostenlos und zeigt, welche Felder eine Seite überhaupt hergibt, bevor du etwas ausgibst — sowie eine CLI via npx @thunderbit/thunderbit-cli für Cron und CI. Für Nicht-Entwickler, die nichts davon anfassen wollen, läuft die Chrome-Erweiterung als No-Code-Tool auf derselben Engine, und die Anleitungen auf Thunderbits YouTube-Kanal decken die typischen Workflows ab.

Der eigentliche Unterschied ist, wo die Arbeit liegt — nicht, welches Tool „besser“ ist. Botasaurus lässt Framework, Browser-Flotte, Abhängigkeiten, Infrastruktur und Wartung auf deiner Seite der Grenze, ohne Gebühr pro Request; Rechenleistung, Bandbreite, Proxies und Betrieb kosten aber weiterhin Geld. Eine gemanagte API nimmt Rendering und schemaförmige Ausgabe von deiner Liste und berechnet pro Call — das kannst du auf der Preisseite gegen ein Self-Hosting-Setup rechnen.

Thunderbit für Web-Datenextraktion testen

Fazit

Botasaurus ist ein vernünftiger Kandidat, wenn du ein All-in-one-Python-Framework willst und seinen Abhängigkeits-Footprint akzeptierst. Das Drei-Decorator-Design ist sauber, die Treiberoberfläche breit, und die Installation sowie die Import-Smoke-Tests bestanden bei mir auch auf Python-Versionen, die neuer sind als die offiziell klassifizierten. Auf meinem lokalen Fixture fing der Standard-Snapshot außerdem Inhalte auf, die erst 300 ms nach dem Load-Event eingefügt wurden, während die anderen getesteten Stacks sie bereits bei 100 ms verfehlten; das ist ein Fixture-Ergebnis, kein allgemeines Ranking.

Die Aussagen müssen aber korrekt eingeordnet werden. Es ist eine 122-MB-Installation mit 44 Paketen, von denen der Treiber nur rund 4 MB ausmacht und der Rest aus numpy, lxml, gevent und Co. besteht — ungefähr 7x so viel wie ein fokussierter Treiber, und dieses Gewicht landet in deinem Container-Image und in deiner Cold-Deploy-Zeit. Der 0,08-ms-Top-Level-Import ist eine leere Eingangstür, kein leichter Framework-Body; der Engine-Import mit rund 135 ms ist die Zahl, die du tatsächlich bezahlst. Das großzügige Standard-Abruffenster kostet pro Navigation rund 250 ms. Und bei der Offenlegung, die ich tatsächlich überprüfen konnte, ist das Bild enger, als das Marketing vermuten lässt: Ein Boolean unterscheidet sich von Standard-Puppeteer, der User-Agent im Headless-Modus bleibt HeadlessChrome, und alle anderen gemessenen Eigenschaften waren über alle vier Stacks hinweg identisch. Das Anti-Detection-Versprechen, mit dem das Tool verkauft wird, ist genau der Punkt, den dieser Test nicht bewertet — ich habe bestätigt, dass die Methoden existieren, den Treiber auf einer Seite auf meinem eigenen Rechner laufen lassen und dort bewusst aufgehört. Kennt man den Footprint, ignoriert man die schmeichelhafte Importzahl und behandelt das Stealth-Marketing als offene Frage, dann ist Botasaurus ein solides Framework, das genau das tut, was Frameworks tun. Wer einen federleichten Treiber erwartet, wird bei docker build überrascht sein.

Thunderbit für Web-Datenextraktion testen Get Started Free

FAQs

Ist Botasaurus kostenlos, und unter welcher Lizenz steht es?
Ja, es ist kostenlos und MIT-lizenziert — sowohl das botasaurus-Meta-Paket als auch die botasaurus-driver-Engine tragen den OSI-klassifizierten MIT-Status. MIT ist permissiv, also ohne Copyleft-Pflicht und gut geeignet für den kommerziellen Einsatz; das ist ein klarer Kontrast zu vergleichbaren Anti-Detect-Treibern unter AGPL-3.0. Ein wichtiger Hinweis: MIT gilt für die eigenen Pakete von Omkar Cloud, nicht automatisch für die rund 40 transitiven Abhängigkeiten, die mitinstalliert werden. Lass also vor einer unternehmensweiten Einführung den eigenen Lizenzscan über den Baum laufen.

Wie groß ist eine Botasaurus-Installation, und warum wirkt import botasaurus trotzdem sofort?
Eine saubere pip install botasaurus-Installation erzeugte auf meinem Rechner einen site-packages-Baum von 122,3 MB über 44 Pakete hinweg. Der Browser-Treiber selbst ist nur etwa 4 MB groß — das Gewicht entsteht durch den breiten Abhängigkeitsbaum des Meta-Pakets, vor allem durch numpy (30,9 MB), lxml (19,2 MB), botasaurus_requests (12,6 MB), gevent (11,3 MB) und pygments (8,4 MB). Das ist etwa 7x der Footprint eines fokussierten Treibers wie nodriver auf demselben Rechner. Nichts davon ist ein Defekt; es sind die Kosten von „Batteries included“, und sie sind vor allem für die Containergröße relevant. Die Importzeit verschleiert genau diesen Footprint: import botasaurus liegt bei etwa 0,08 ms, aber nur, weil das Top-Level-Paket fast leer ist — kein __version__, fast keine öffentlichen Namen, also passiert beim Import kaum etwas. Der Import, der tatsächlich kostet, ist die Engine from botasaurus_driver import Driver mit rund 135 ms; danach liegt der resident memory bei etwa 29–30 MB, noch bevor ein Browser gestartet wurde. Wenn du einen Serverless-Cold-Start dimensionierst, messe den Engine-Import, nicht den leeren Top-Level-Import.

Was gibt Botasaurus über sich selbst preis, und wurde es gegen echte Anti-Bot-Systeme getestet?
Die erste Hälfte wurde gemessen; die zweite Hälfte wurde absichtlich nicht getestet. Auf einer Seite, die ich unter 127.0.0.1 gehostet habe, und mit demselben Chrome-Build wie die Kontrollen gilt: navigator.webdriver kommt als false zurück, während Standard-Playwright und Standard-Puppeteer beide true melden. Dieser Wert wird beim Browser-Start festgelegt und nicht durch das Patchen der Eigenschaft — der Descriptor bleibt der native Getter von Chrome. Abgesehen von diesem Boolean stimmte fast alles mit den Kontrollen überein: derselbe Plattform-String, fünf Plugins, zwölf Kerne, 16 GB gemeldeter Arbeitsspeicher, dieselbe window.chrome-Form, kein Konflikt in der Permissions API und keine cdc_-Rückstände auf document oder window. Headless-Läufe melden weiterhin HeadlessChrome/151.0.0.0 im User-Agent, genau wie beide Kontrollen — der Driver-Konstruktor hat zwar einen user_agent-Parameter, aber standardmäßig wird dort nichts gesetzt. Zur Wirksamkeit: Ich habe den Treiber nie auf eine Live-Seite losgelassen, nie einen Anti-Bot-Dienst kontaktiert und kein CAPTCHA berührt. Der Treiber enthält zwar einige Methoden mit Anti-Detection-Namen, deren Existenz ich bestätigt habe, aber ich habe sie nicht aufgerufen, ihr Verhalten gegen ein Ziel nicht geprüft, keine Erfolgsquote gemessen und keinen Mechanismus beschrieben. Die obige Disclosure-Tabelle zeigt, was der Stack von sich preisgibt — und nichts darüber, wer zuhört oder was daraus gemacht wird.

Kann Botasaurus JavaScript-gerenderte Inhalte korrekt verarbeiten?
Ja, und der Standard ist großzügiger als bei den meisten anderen. Auf einem Fixture mit drei Inhaltsklassen lieferte driver.get() plus driver.page_html bei einer Einfügeverzögerung von 800 ms ein Ergebnis von 2 von 3 — JavaScript wird korrekt ausgeführt, aber sehr späte Inhalte werden vor dem Einfügen gelesen —, während driver.wait_for_element() 3 von 3 zurückgab. Der besondere Punkt ist, wo der Standard-Abruf aufgibt: Botasaurus erfasst Inhalte noch bei einer Einfügung 300 ms nach dem Load-Event, während nodriver, Playwright und Puppeteer sie bereits bei 100 ms verlieren. Das hängt mit wait_for_complete_page_load=True im Konstruktor zusammen und kostet etwa 250 ms pro Navigation.

Wie importiere und nutze ich Botasaurus nach der Installation eigentlich?
Nicht so, wie man es zuerst erwarten würde. Der Top-Level-Namespace botasaurus ist fast leer; die eigentliche API liegt in Submodulen: from botasaurus.browser import browser, Driver, from botasaurus.request import request und from botasaurus.task import task. Du versiehst eine normale Funktion mit @browser, @request oder @task, und das Framework übernimmt Treiber, Caching und Ausgabe. Da es kein botasaurus.__version__ gibt, nutze importlib.metadata, wenn du protokollieren möchtest, welche Build-Version du ausführst.