> ## 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.

# Sichtbare vs. Headless-Browser

> Headless-Browser dominieren das Scraping, doch Octoparse läuft bewusst sichtbar. Warum diese Wahl zählt und welcher Ansatz wann passt.

Bei der Wahl eines Web-Scraping-Tools ist die wichtigste Entscheidung weder Programmiersprache noch Browser-Engine, sondern ob der Browser **headless** (ohne sichtbares Fenster, nur programmgesteuert) oder **sichtbar** (mit echtem Browserfenster) läuft. Fast das gesamte Ökosystem – Puppeteer, Playwright, Selenium und jede Cloud-Browser-API – verwendet standardmäßig Headless-Betrieb. Eine kleinere Gruppe integrierter Scraping-Plattformen ist bewusst sichtbar; Octoparse ist das deutlichste aktuelle Beispiel. Beide Optionen richten sich an andere Anwender, funktionieren bei unterschiedlichen Websites und scheitern auf unterschiedliche Weise.

## Warum Headless zum Standard wurde

Headless-Browser wurden für Entwickler gebaut. Sie laufen auf Servern ohne Displays, passen sauber in Container und CI/CD-Pipelines, überspringen für Menschen nötigen Rendering-Aufwand wie Fensterrahmen, GPU-Compositing, Autofill und Telemetrie und ermöglichen viele parallele Sitzungen auf einem Rechner. Wer Code schreibt, Protokolle liest und Seiten programmgesteuert beschreibt, muss sie nicht sehen. Alles in der [Browser-Laufzeitlandschaft](/docs/de/academy/browser-runtime-landscape) oberhalb der integrierten Plattformen – Puppeteer, Playwright, Selenium, Splash und jede Cloud-Browser-API – setzt diese Arbeitsweise voraus. Headless ist der stille Standard des codebasierten Scrapings.

## Die Kosten des Headless-Betriebs

Die Nachteile treten regelmäßig an vier Stellen auf:

* **Bot-Erkennungssignale.** `navigator.webdriver` wird `true`, der User-Agent enthält `HeadlessChrome`, Plugins fehlen und Canvas sowie WebGL erzeugen ungewöhnliche Fingerprints. [Anti-Bot-Dienste wie Cloudflare und DataDome](/docs/de/academy/captcha-and-cloudflare) sind darauf abgestimmt. Das gesamte Ökosystem der Tarnvarianten – puppeteer-extra-stealth, undetected-chromedriver, nodriver und Patchright – existiert, weil normaler Headless-Betrieb diese Signale preisgibt.
* **Viewport-gesteuertes Verhalten.** Lazy-Loading-Bilder, Intersection-Observer-Inhalte und an Sichtbarkeit gebundene Skripte setzen voraus, dass eine Seite tatsächlich gerendert und „gesehen“ wird. Headless kann den Viewport simulieren, doch diese Grenze ist fragil und Verhalten wird leicht übersehen.
* **Kein Mensch im Prozess.** Bei CAPTCHA, unerwartetem Dialog oder abgelaufener Anmeldung ist Headless blind. Das Skript weiß nicht, dass es feststeckt, sondern nur, dass es keine Daten mehr liefert.
* **Debugging per Protokoll statt Sichtprüfung.** Fällt ein Selektor auf Seite 42 eines Nachtlaufs aus, reproduzieren Sie den Fehler lokal – oft sichtbar –, um die Änderung zu erkennen. Das Debugging ist sichtbar, die Produktion nicht.

Nichts davon ist ein Ausschlusskriterium. Es ist die dauerhafte Zusatzbelastung des codebasierten Headless-Scrapings.

## Die bewusst sichtbare Kategorie

Bei einer kleineren Tool-Kategorie ist die Seite kein internes Implementierungsdetail, sondern die Benutzeroberfläche. Anwender wählen Elemente auf der gerenderten Seite aus, beobachten jeden Ausführungsschritt, sehen und lösen CAPTCHAs und debuggen visuell. **Octoparse** ist das deutlichste aktuelle Beispiel. ParseHub folgt demselben Muster; auch die ältere Chrome-Erweiterung Web Scraper.io gehört zu dieser Tradition.

Bewusst sichtbarer Betrieb ist nur mit einer eigens entwickelten Laufzeit wirtschaftlich. Ein unverändertes Chrome mit Erweiterungen, Synchronisierung, Autofill, vollständigem GPU-Compositing und Telemetrie ist für Scraping im großen Maßstab zu schwer. Integrierte Plattformen liefern deshalb speziell dafür gebaute Laufzeiten: authentisch genug und zugleich leicht genug für einen dichten Parallelbetrieb.

## Die zwei sichtbaren Laufzeiten von Octoparse

Octoparse bietet zwei auf ihren Zweck abgestimmte sichtbare Laufzeiten und wechselt je nach Anforderungen der Zielwebsite.

### Reduziertes und optimiertes Electron Chromium

Die erste Laufzeit ist ein angepasstes, in Electron integriertes Chromium. Octoparse hat sie speziell fürs Scraping reduziert und optimiert und unnötigen Aufwand wie Erweiterungen, Hintergrundprozesse und Rendering-Funktionen entfernt, die Menschen benötigen, ein Scraper aber nicht. Das Ergebnis lädt Seiten schneller, verbraucht deutlich weniger Arbeitsspeicher und CPU und bewältigt viele parallele Sitzungen, ohne einen Rechner auszubremsen. Gegenüber einer vollständigen Browserinstanz über Puppeteer oder Selenium bietet dieser zweckgebundene Ansatz einen spürbaren Leistungsvorteil, besonders bei lokalen Aufgaben oder begrenzter Hardware. Durch die enge Integration in den visuellen Editor werden Aufgaben in derselben Umgebung konfiguriert und ausgeführt.

### Von Puppeteer gesteuertes Chrome for Testing

Die zweite Laufzeit ist Chrome for Testing, gesteuert von Puppeteer. Dabei handelt es sich um einen vollständigen, unveränderten und programmgesteuerten Chrome-Browser, der sich genauso verhält, wie ein echter Benutzer es sehen würde. Er eignet sich besser für Websites mit [aggressiver Bot-Erkennung, Fingerprinting oder Kompatibilitätsprüfungen](/docs/de/academy/captcha-and-cloudflare), die eine normale Chrome-Umgebung erwarten. Er benötigt mehr Ressourcen als die Electron-Laufzeit, doch seine Browserauthentizität ist mitunter unverzichtbar.

<Note>
  Ein dritter Laufzeitmodus wird entwickelt: eine Browser-Erweiterung, die Ihren eigenen Chrome-Browser direkt steuert. Da die Extraktion in einem echten Alltagsbrowser mit authentischen Fingerprints und authentischem Verhalten läuft, bildet sie reale Benutzeraktivität sehr genau nach und reduziert das Risiko, eine Anti-Bot-Erkennung auszulösen, erheblich.
</Note>

### Welche Laufzeit wann geeignet ist

Der zentrale Vorteil beider integrierten Laufzeiten ist Flexibilität ohne Komplexität. Bei eigenständigen Tools wie Puppeteer oder Playwright müssen Benutzer Browser-Binärdateien, Versionen, Startoptionen und Infrastruktur selbst verwalten. Octoparse abstrahiert all dies. Die optimierte Electron-Laufzeit erledigt die große Mehrheit der Aufgaben effizient, während Chrome for Testing bereitsteht, wenn vollständige Browserauthentizität benötigt wird. Der Wechsel ist eine Konfigurationsoption, kein Entwicklungsprojekt. Ob eine Aufgabe [auf Ihrem Rechner oder in der Cloud](/docs/de/academy/cloud-web-scraping) läuft, die Laufzeit bleibt derselbe einfache Umschalter.

## Wann sichtbar und wann Headless besser ist

| Diese Option wählen                                                                     | Wenn                                                                                                                                                            |
| --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Headless-Codebibliothek (Puppeteer / Playwright / Selenium)                             | Ein Entwickler den Scraper betreibt, Sie auf Servern skalieren und die Zielwebsite keine starke Anti-Bot-Abwehr besitzt                                         |
| Headless-Cloud-API (Browserless / Zyte / Browserbase)                                   | Wie oben, Sie den Browser aber nicht selbst hosten möchten                                                                                                      |
| Headless plus Tarnvariante (puppeteer-extra-stealth, undetected-chromedriver, nodriver) | Wie oben, die Zielwebsite aber aggressiv Fingerprinting betreibt                                                                                                |
| Bewusst sichtbare Plattform (Octoparse / ParseHub)                                      | Der Bediener kein Entwickler ist, die Zielwebsite starke Anti-Bot-Abwehr besitzt oder visuelles Debugging und Eingriffe bei CAPTCHAs und Anmeldungen nötig sind |

Die Wahl lautet nicht abstrakt „einfacher“ oder „besser“, sondern hängt von Bediener und Zielwebsite ab. Ein Entwickler, der eine öffentliche Datenwebsite scrapt, kann einfach Puppeteer verwenden und alle anderen Fragen dieser Seite überspringen. Je stärker das Ziel geschützt und je weiter der Bediener vom Code entfernt ist, desto überzeugender wird sichtbarer Betrieb.

Eine vollständige Aufstellung der Tools beider Seiten finden Sie unter [Die Browser-Laufzeitlandschaft](/docs/de/academy/browser-runtime-landscape).
