Skip to main content
Die meisten modernen Websites liefern Inhalte nicht mehr als statisches HTML aus. Frameworks wie React, Vue und Angular bauen Seiten dynamisch im Browser auf: Der Server sendet eine minimale HTML-Hülle und JavaScript-Bundles; die eigentlichen Inhalte erscheinen erst nach der clientseitigen Ausführung. Deshalb erhält ein einfacher HTTP-Scraper mit etwa Pythons requests häufig eine fast leere Seite: Er lädt das Roh-HTML, führt aber das JavaScript zur Datenanzeige nicht aus. Es gibt drei Lösungsansätze. Der günstigste geeignete Ansatz gewinnt – prüfen Sie sie daher in dieser Reihenfolge.

​
Ansatz 1: Seite in einem echten Browser rendern

Die universelle Lösung ist eine echte Browser-Engine, die JavaScript wie ein Nutzerbrowser ausführt. Die Seite lädt, Skripte laufen, APIs werden aufgerufen, Inhalte gerendert – erst danach extrahiert der Scraper Daten aus dem vollständigen DOM. Das funktioniert bei jeder JS-gerenderten Website, benötigt aber für jede Seite eine speicher- und CPU-intensive Browserinstanz. Auch die Engine ist eine Entscheidung: Puppeteer, Playwright, Selenium, Cloud-APIs sowie sichtbarer oder Headless-Betrieb. Einen Überblick bietet Die Landschaft der Browser-Laufzeiten; die fürs Scraping wichtige Entscheidung erläutert Browser mit Oberfläche und Headless-Browser. Bei großem Umfang ist der Overhead relevant; speziell entwickelte Engines kosten je Seite deutlich weniger als Standardbrowser.

​
Ansatz 2: Zugrunde liegende API abfangen

JS-gerenderte Seiten beziehen Inhalte über Backend-APIs per XHR oder fetch. Identifizieren Sie diese Endpunkte, können Sie strukturiertes JSON direkt abrufen – schneller, schlanker und stabiler als vollständiges Rendering: kein DOM-Warten, keine bei Layoutänderungen brechenden Selektoren und bereits geparste Daten. Solche APIs können undokumentiert, authentifizierungspflichtig oder ratenbegrenzt sein und sich unangekündigt ändern. Öffnen Sie die Seite mit dem Netzwerkbereich der DevTools, beobachten Sie beim Laden die Anfragen und suchen Sie XHR-/fetch-Antworten mit den gewünschten Daten. Oft lassen sie sich außerhalb des Browsers reproduzieren, manchmal mit einem einzigen curl-Befehl. Octoparse integriert dies in den visuellen Editor. Der integrierte Browser zeigt den Netzwerkbereich wie DevTools, ermöglicht aber die Auswahl einer API-Antwort wie eines DOM-Elements: anklicken, und die Aufgabe nutzt den Endpunkt statt die Seite zu rendern. Dadurch wird aus „DevTools öffnen, Aufruf finden, Header kopieren, Anfrage nachbauen“ ein visueller Schritt. Wann immer möglich, ist dies die beste Lösung – und häufiger möglich als angenommen. Prüfen Sie sie, bevor Sie einen Browser einsetzen.

​
Ansatz 3: Serverseitiges Rendering erkennen

Manche Client-Framework-Websites verwenden für Leistung und SEO auch serverseitiges Rendering (SSR) oder statische Generierung. Dann enthält die erste HTML-Antwort bereits den vollständigen Inhalt, sodass ein schlanker HTTP-Aufruf genügt. Zeigen Sie den Seitenquelltext an (Cmd+U / Ctrl+U, nicht „Untersuchen“, das den Live-DOM zeigt). Stehen die Daten im Roh-HTML, brauchen Sie keinen Browser. Manche Websites liefern verschiedenen User-Agents unterschiedliche Inhalte und rendern etwa für Suchmaschinen vor. Ein bekannter Suchbot als User-Agent kann gelegentlich eine servergerenderte Version zugänglich machen. Beachten Sie dabei stets die Bedingungen der Website.

​
Praktische Tipps für echte Browser

  • Auf das Richtige warten, nicht auf „load“. Warten Sie auf den benötigten Selektor oder Text; das Ladeereignis kann vor den clientseitigen Inhalten eintreten.
  • Lazy Loading beachten. Erst beim Scrollen gerenderte Inhalte existieren vorher nicht. Browser-Automatisierung kann scrollen.
  • Clientseitiges Routing täuscht traditionelle Scraper. In SPAs kann /products zu /products/42 wechseln, ohne eine neue HTTP-Anfrage auszulösen. Warten Sie auf Inhaltsänderungen statt pageload.
  • Endloses Scrollen und „Mehr laden“ erfordern Interaktion. Siehe Paginierung verarbeiten.

​
Zuerst den günstigsten Ansatz testen

  1. Quelltext anzeigen. Sind Inhalte im Roh-HTML, genügt eine HTTP-Anfrage.
  2. Netzwerkaufrufe prüfen. Ruft die Seite eine API auf, verwenden Sie diese direkt.
  3. In einem echten Browser rendern. Wenn beides nicht geht, führen Sie die Seite aus und wählen eine passende Laufzeit.
Jede Stufe erhöht Latenz, Infrastrukturaufwand und Ausfallrisiko. Echtes Browser-Rendering kann um Größenordnungen teurer sein als ein direkter API-Aufruf; über Tausende Seiten summiert sich das. Benötigt ein Workflow je Seitentyp verschiedene Ansätze – SSR, API oder vollständiges Client-Rendering –, spart eine Plattform, die innerhalb derselben Aufgabe zwischen visueller Auswahl, Netzwerkprüfung und Browser-Laufzeit wechseln kann, die Integration dreier Toolchains.