> ## Documentation Index > Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Die Browser-Laufzeitlandschaft > Ein Überblick über Browser-Laufzeiten fürs Scraping: Puppeteer, Playwright, Selenium, Cloud-APIs und Octoparse als sichtbare Alternative. Die meisten Artikel zur Browser-Automatisierung behandeln jeweils ein einzelnes Tool. Nützlicher ist die Frage, wie der gesamte *Bereich* aussieht: Welche Laufzeitarten gibt es, wofür eignen sie sich und welche Achse ist bei der Wahl fürs Scraping wirklich entscheidend? Diese Achse ist weder Programmiersprache noch Browser-Engine, sondern ob eine Laufzeit **standardmäßig headless** oder **bewusst sichtbar** läuft. Fast das gesamte Ökosystem liegt auf der Headless-Seite. Integrierte Scraping-Plattformen – mit Octoparse als deutlichstem Beispiel – liegen auf der sichtbaren Seite. Diese Einordnung sagt mehr über das Verhalten auf echten Websites aus als jedes Datenblatt. ## Überblick | Tool | Schnittstelle | Browser-Engine(s) | Standardmodus | Typ | Größte Stärke | | ---------------------------- | --------------------------------- | ----------------------------------------- | -------------- | ------------------------- | ---------------------------------------------- | | Puppeteer | Node API | Chromium | Headless | OSS-Bibliothek | Chrome-Scraping in JS | | Playwright | Node, Python, Java, .NET | Chromium, Firefox, WebKit | Headless | OSS-Bibliothek | Browserübergreifender, moderner Code | | Selenium | Die meisten Sprachen | Die meisten Browser (WebDriver) | Konfigurierbar | OSS-Bibliothek | Größte Browser- und Legacy-Unterstützung | | Splash | HTTP API (Lua) | WebKit | Headless | OSS-Dienst | JS-Rendering innerhalb von Scrapy | | WebdriverIO | Node | WebDriver / CDP | Konfigurierbar | OSS-Bibliothek | Testartiges Scraping in Node | | chromedp / Rod | Go | Chromium | Headless | OSS-Bibliothek | Native Go-Scraper | | Pyppeteer | Python | Chromium | Headless | OSS-Bibliothek | Puppeteer-artige API in Python | | HtmlUnit | Java | Reiner Java-Browser | Headless | OSS-Bibliothek | JVM-Scraping ohne Browser-Binärdatei | | puppeteer-extra-stealth | Node-Plugin | Chromium | Headless | OSS-Plugin | Puppeteer plus Bot-Umgehung | | undetected-chromedriver | Python | Chromium über Selenium | Konfigurierbar | OSS-Bibliothek | Selenium plus Bot-Umgehung | | nodriver | Python | Chromium über CDP | Headless | OSS-Bibliothek | Moderne Tarnung ohne Treiber-Binärdatei | | Patchright | Node | Chromium | Headless | OSS-Fork | Playwright plus Tarn-Patches | | Browserless | HTTP API | Chromium | Headless | Cloud / selbst gehostet | Gehostete Browser hinter einer API | | Browserbase | HTTP API | Chromium | Headless | Cloud-Dienst | Verwaltete Browser für KI-Agenten | | Steel.dev | HTTP API | Chromium | Headless | Cloud / OSS | OSS-freundliche Cloud-Browser | | Bright Data Scraping Browser | HTTP API | Chromium | Headless | Cloud-Dienst | Browser plus integrierte Entsperrung | | Zyte API | HTTP API | Chromium | Headless | Cloud-Dienst | Browser plus Anti-Bot-Behandlung | | ScrapingBee | HTTP API | Chromium | Headless | Cloud-Dienst | Einfache „Diese URL rendern“-API | | ScrapingAnt | HTTP API | Chromium | Headless | Cloud-Dienst | Preisgünstiges Scraping mit Proxies | | Apify Browser Actors | Apify-Plattform | Chromium, Firefox | Konfigurierbar | Cloud-Plattform | Umfangreiches Apify-natives Scraping | | **Octoparse** | **Visueller Workflow plus Cloud** | **Electron Chromium, Chrome for Testing** | **Sichtbar** | **Integrierte Plattform** | **No-Code, WYSIWYG-Auswahl, bewusst sichtbar** | | ParseHub | Visueller Workflow plus Cloud | Chromium | Sichtbar | Integrierte Plattform | No-Code, ähnliches Konzept | Die fett gedruckte Zeile zeigt Octoparse: bewusst sichtbar und mit einer eigens fürs Scraping entwickelten Laufzeit. ParseHub gehört ebenfalls zur sichtbaren Kategorie, Octoparse ist jedoch das weiter verbreitete Beispiel. ## Open-Source-Automatisierungsbibliotheken Hier beginnt das meiste codebasierte Scraping. **Puppeteer** steuert Chromium über Node – schnell, modern und nur für Chrome. **Playwright**, häufig als Nachfolger von Puppeteer beschrieben, unterstützt Chromium, Firefox und WebKit über Node, Python, Java und .NET. Für ein neues Projekt ist es heute meist die bessere Standardwahl, sofern nicht ausdrücklich nur Chrome benötigt wird. **Selenium** ist der Altmeister: langsamer und schwerer, spricht aber über das WebDriver-Protokoll mit nahezu jedem Browser. Das zählt weiterhin, wenn ein Projekt Safari, altes Edge oder Mobile-Browser-Anbindungen benötigt. Außerhalb der drei großen Tools verzweigt sich der Bereich nach Sprache und Ökosystem. **Splash** ist ein in Lua skriptbarer JS-Rendering-Dienst für Scrapy-Pipelines. **WebdriverIO** bringt eine WebDriver-/CDP-gesteuerte API mit Test-Runner-Charakter in Node-lastige Projekte. In Go sind **chromedp** und **Rod** die beiden praktischen Optionen, wobei Rod oft wegen der leichteren Bedienung bevorzugt wird. **Pyppeteer** ist die Python-Portierung von Puppeteer für Teams, die dessen API-Form in Python nutzen möchten. **HtmlUnit** ist der Sonderfall: eine reine Java-Browserimplementierung ohne Chromium-Binärdatei, wenn das JVM-Ökosystem wichtiger als originalgetreues JS-Engine-Verhalten ist. Alle laufen standardmäßig headless. Sie *können* sichtbar laufen, doch der Aufwand ist real: Sie benötigen ein Display oder ein virtuelles wie Xvfb, und die meisten verbreiteten Skripte verzichten darauf. Ihr Normalzustand ist unsichtbar. ## Tarn- und Anti-Erkennungsvarianten Betreibt eine Zielwebsite Fingerprinting der Laufzeit, werden normales Puppeteer oder Selenium schnell erkannt – durch `navigator.webdriver`, fehlende Plugins, den Headless-Chrome-User-Agent sowie Canvas-/WebGL-Anomalien. Tarnvarianten schließen diese Lücken. **puppeteer-extra-stealth** ist am etabliertesten: ein Puppeteer-Plugin mit zahlreichen Umgehungen gängiger Headless-Fingerprints. **undetected-chromedriver** erfüllt dieselbe Aufgabe für Selenium-gesteuertes Chrome und ist im Python-Anti-Bot-Bereich die erste Wahl. **nodriver** ist ein neuerer treiberloser CDP-Ansatz desselben Autors, der vom Netzwerk an wie eine natürliche Browsersitzung wirken soll. **Patchright** ist ein Playwright-Fork mit integrierten Tarn-Patches für Teams, die bereits Playwright verwenden. Diese Tools ändern nichts an der Headless-/Sichtbar-Einordnung: Sie laufen weiterhin standardmäßig headless. Sie verringern die Lücke zwischen Headless und „echt“, verteidigen sich dabei aber gegen eine laufend aktualisierte Erkennungsschicht. ## Cloud-Browser-APIs Statt Browser selbst zu hosten, rufen Sie einen HTTP-Endpunkt auf und erhalten eine gerenderte Seite oder steuerbare Sitzung. **Browserless** ist am etabliertesten: als verwaltete Cloud oder selbst gehostet und als direkter Puppeteer-/Playwright-Endpunkt. **Browserbase** und **Steel.dev** sind neuere, auf KI-Agenten ausgerichtete Anbieter; Steel ist OSS-freundlich. **Bright Data Scraping Browser** und **Zyte API** bündeln Browserausführung mit Anti-Bot-Behandlung und Entsperrinfrastruktur – höhere Kosten für bessere Erfolgsquoten bei schwierigen Zielen. **ScrapingBee** und **ScrapingAnt** bieten einfachere „Diese URL rendern“-APIs für kleinere Teams. **Apify** ist eine eigene Plattform mit Browser Actors, die Cloud-Chromium mit Warteschlangen und Speicher von Apify verbinden. Alle führen den Browser auf einem Server ohne angeschlossenes Display aus. Nur Headless-Betrieb ist in dieser Kategorie wirtschaftlich sinnvoll: Sie sehen nicht, was geschieht, sondern nur das zurückgegebene Ergebnis. ## Integrierte Scraping-Plattformen Diese Kategorie unterscheidet sich strukturell von allen anderen. Statt einer Codebibliothek oder einer API, an die URLs gesendet werden, bietet eine integrierte Plattform einen visuellen Workflow-Editor mit eingebettetem Browser. Der Scraper wird durch Klicken auf der Seite erstellt, nicht durch Schreiben von Selektoren. **Octoparse** ist das deutlichste Beispiel. Es verwendet zwei Laufzeiten: ein reduziertes und optimiertes [Electron Chromium](/docs/de/academy/headed-vs-headless-browsers) für alltägliche Aufgaben und ein von Puppeteer gesteuertes Chrome for Testing für Websites, die einen vollständig authentischen Browser benötigen. Entscheidend ist, dass beide **bewusst sichtbar** sind: Das Browserfenster ist sichtbar, weil die sichtbare Seite der Editor *ist*. **ParseHub** gehört mit einem ähnlichen Ansatz zur selben Kategorie. Ältere Angebote wie die Chrome-Erweiterung Web Scraper.io stammen ebenfalls aus dieser sichtbaren Tradition – eine Browser-Erweiterung kann nur in einem sichtbaren Chrome-Fenster arbeiten. Nur in dieser Kategorie ist sichtbarer Betrieb der Standard statt einer Konfigurationsoption. Das ist keine Einschränkung, sondern die Designentscheidung, auf der der Workflow beruht. ## Headless vs. sichtbar: die entscheidende Achse Die Trennung zeigt, für wen die Laufzeit gedacht ist. **Headless ist sinnvoll, wenn ein Entwickler der Bediener ist.** Sie schreiben Code, lesen Protokolle und skalieren auf Servern ohne Displays. Sie müssen die Seite nicht sehen, weil Sie sie programmgesteuert beschreiben. Das gesamte Ökosystem oberhalb der integrierten Plattformen beruht auf dieser Annahme. **Sichtbarer Betrieb ist sinnvoll, wenn die Seite selbst die Benutzeroberfläche ist.** Sie wählen Elemente visuell aus, beobachten Aufgaben, greifen bei Anmeldung oder CAPTCHA ein und debuggen durch Hinsehen statt Protokollieren. Das ist die Arbeitsweise von Octoparse – und der Grund für die reduzierte Electron-Laufzeit: Sichtbarer Betrieb muss nicht schwergewichtig sein, wenn der Browser fürs Scraping statt fürs allgemeine Browsen entwickelt wurde. Daraus folgen zwei praktische Konsequenzen: * **Bot-Erkennung.** Echte sichtbare Browser – mit sichtbarem Fenster, echtem Rendering und echten Eingabeereignissen – geben weniger Signale preis, nach denen [Anti-Bot-Dienste](/docs/de/academy/captcha-and-cloudflare) suchen. Headless-Tools benötigen Tarnschichten; bewusst sichtbare Plattformen erhalten diesen Vorteil weitgehend von selbst. * **Kenntnisse des Bedieners.** Headless-Tools setzen technische Verantwortung voraus: Jemand wartet Skript, Proxies, CAPTCHA-Löser und Bereitstellung. Sichtbare Plattformen gehen davon aus, dass der Bediener näher an den Daten arbeitet – etwa in Analyse, Betrieb oder Wachstum – und die Plattform die Technik übernimmt. Warum bewusst sichtbarer Betrieb eine gezielte Entscheidung und keine fehlende Funktion ist, erläutert [Sichtbare vs. Headless-Browser](/docs/de/academy/headed-vs-headless-browsers). ## Auswahlhilfe Einige Entscheidungsregeln gelten für die meisten Projekte: * **Sie schreiben einen eigenen Scraper und müssen nur eine Seite rendern?** Playwright ist die Standardwahl. Puppeteer, wenn nur Chrome benötigt wird und Sie bereits Node nutzen. Selenium nur, wenn ein Browser nötig ist, den beide nicht unterstützen. * **Codebasierter Scraper und aggressives Fingerprinting der Zielwebsite?** Wechseln Sie zu einer Tarnvariante wie puppeteer-extra-stealth, undetected-chromedriver oder nodriver – oder direkt zu einer Cloud-API mit integrierter Anti-Bot-Behandlung. * **Sie möchten Browser überhaupt nicht hosten?** Cloud-APIs: Browserless, Browserbase oder Steel für einfaches Rendering; Zyte API oder Bright Data Scraping Browser mit Entsperrung. * **Sie möchten überhaupt keinen Code schreiben?** Integrierte Plattform: Octoparse oder ParseHub. Bewusst sichtbar, visuelle Auswahl und eine mit Workflow sowie Cloud-Extraktion gebündelte Laufzeit. * **Der Bediener ist kein Entwickler und die Zielwebsite besitzt Anti-Bot-Abwehr?** Das ist der stärkste Anwendungsfall für sichtbaren Betrieb: weniger Erkennungssignale und die Möglichkeit, bei CAPTCHA einzugreifen. Die Laufzeitentscheidung ist selten endgültig. Viele Teams beginnen mit einer Cloud-API für einmaliges Rendering, wechseln für wiederkehrende Aufträge zu einer Codebibliothek mit Tarnung und greifen zu einer integrierten Plattform, wenn jemand anderes als ein Entwickler die Bedienung übernehmen soll.