.4UVmK5aw_1uGpNi.svg){kind=small}
.AzQB9McO_PVSYK.svg){kind=small}
.DjhlE8MO_Z1DYVxU.svg){kind=small}
.DM2pllEO_1cxFXE.svg){kind=small}
.CvN5042A_Z10D5qc.svg){kind=small}
.Dcqs_gC__NRL3p.svg){kind=small}
<div id="root"></div> <!-- data still in the bundle -->
Sitzungen sind kostenlos – Sie zahlen nur für Traffic
Cloud-Browser für Web-Scraping
Eine Cloud-Browser-Sitzung lädt die Seite so, wie es bei einem echten Besucher geschähe – samt Skripten. Wenn Ihr Code sie ausliest, sind die Inhalte bereits da.
- React-, Vue- und Angular-Seiten werden vollständig gerendert – keine leere Hülle
- Residential-, Mobil- oder Rechenzentrums-IPs – Sticky oder rotierend
- Playwright und Puppeteer – in der Regel genügt eine geänderte Zeile
Web-Scraping
Ihr Code steuert
den Browser.
Verbinden Sie sich per CDP mit unserem Chromium, statt HTML abzurufen. Er lädt die Seite wie ein echter Besucher – mit sämtlichem JS, unseren Proxys und einem glaubwürdigen Fingerprint – und Sie lesen das gerenderte DOM aus.
Warum Cloud-Browser statt normaler HTTP-Anfragen?
Eine einfache HTTP-Anfrage lädt nur das HTML herunter, das der Server liefert – nicht mehr. Für statische Seiten reicht das völlig aus. Im Großteil des modernen Webs scheitert es jedoch, denn Seiten auf Basis von React, Vue oder Angular liefern ihre Inhalte nicht in dieser ersten Antwort aus – sie bauen sie erst im Browser auf, nachdem das JS ausgeführt wurde. Richten Sie einen reinen Anfrage-Scraper auf eine solche Seite, erhalten Sie eine leere Hülle zurück, während die eigentlichen Daten noch in einem Bundle stecken, das niemand ausgeführt hat.
Web-Scraping mit Cloud-Browser-Sitzungen umgeht dieses Problem. Die Seite lädt so, wie es bei einem echten Besucher geschähe – samt Skripten –, und wenn Ihr Code sie ausliest, sind die Inhalte bereits da. Sie müssen nicht erraten, welcher Endpunkt die Seite speist, und kein Bundle zerlegen, um das Anfragemuster zu finden – Sie erhalten einfach das fertige Ergebnis, bereit zum Abgreifen.
Sperren und Anti-Bot-Schutz auf Browserebene umgehen
Früher genügte es, die richtigen Header zu senden, um eine Seite zu erhalten. Das ist vorbei – Websites bewerten Dutzende kleiner Signale, bevor sie entscheiden, ob eine Anfrage überhaupt echt aussieht:
-
Die Reihenfolge der Header, nicht nur welche Header vorhanden sind
-
Zeitabstände zwischen Aktionen
-
Ob sich Maus oder Scrollen wie bei einem Menschen verhalten haben
-
Fingerprint-Eigenheiten: installierte Schriftarten, Canvas-Ausgabe und Ähnliches
Dynamisches JavaScript-Rendering und Single-Page-Anwendungen (SPA)
Single-Page-Apps laden einmal und schreiben sich dann beim Klicken selbst um – Tabs öffnen sich, Filter greifen, Ergebnisse aktualisieren sich –, und nichts davon steckt in der ersten Antwort. Ein Cloud-Browser durchläuft denselben Prozess wie ein Besucher und liest die Seite erst aus, wenn sie sich beruhigt hat. Wer diesen Schritt überspringt, erlebt bei allem, was stark clientseitig arbeitet, erstaunlich oft stille Ausfälle beim Scraping.
Automatische CAPTCHA-Lösung und Fingerprint-Verwaltung
Schriftarten, Canvas-Ausgabe, Audioverhalten, Bildschirmgröße – zusammen bilden sie einen Fingerprint, der mit dem verglichen wird, wie ein echter Browser aussehen sollte. Stimmt er nicht, stufen Websites ihn schnell als verdächtig ein, manchmal schon nach ein oder zwei Anfragen. Ob man es Antidetect-Cloud-Browser, Antidetect-Setup oder einfach nicht erkennbaren Modus nennt: Die Aufgabe ist dieselbe – den Fingerprint überzeugend halten, ohne dass jemand manuell eingreift. Die CAPTCHA-Lösung läuft meist in derselben Sitzung mit, sodass ein Auftrag nicht jedes Mal auf eine manuelle Lösung wartet, wenn eines auftaucht.
Integration mit rotierenden Proxys (Residential- und Rechenzentrums-Proxys)
Eine Sitzung kann je nach Empfindlichkeit der Zielseite über Residential-, Mobil- oder Rechenzentrums-IPs laufen. Die Rotation kann für die gesamte Sitzung sticky bleiben oder per Timer wechseln – und diese Wahl ist tatsächlich wichtig. Scraping hinter einem Login braucht durchgehend dieselbe IP, damit Cookies und Sitzungsstatus zusammenpassen. Scraping in großen Mengen braucht das Gegenteil: Die Anfragen werden verteilt, sodass keine einzelne Adresse die ganze Last trägt.
Funktioniert mit Playwright und Puppeteer
Dafür müssen Sie Ihren bestehenden Scraping-Code nicht verwerfen. Playwright und Puppeteer verbinden sich per CDP, statt eine lokale Chrome-Binärdatei zu starten, und alles darunter – Selektoren, Wartezeiten, Extraktion – bleibt unverändert. Ein Crawler, der vor zwei Jahren für lokales Headless-Chrome gebaut wurde, braucht meist nur eine geänderte Zeile, keine Neuentwicklung.
- Playwright
- Puppeteer
- Python
- Node.js
Schnellstart: Beispielcode zur Verbindung
Für den Start einer Sitzung genügen wenige Zeilen:
Geben Sie beim Öffnen der Sitzung einen Proxy-Typ und ein Land an – der Rest des Skripts unterscheidet sich kaum von dem, was ohnehin lokal laufen würde.
scrape.js
const browser = await chromium.connectOverCDP(connectUrl);const page = await browser.newPage();await page.goto('https://example.com');const data = await page.textContent('body');scrape.js
const browser = await puppeteer.connect({ browserWSEndpoint: connectUrl });const page = await browser.newPage();await page.goto('https://example.com');const data = await page.evaluate(() => document.body.innerText);Effizienzvergleich: Scraping mit Anfragen vs. Cloud-Browser
Scraping mit dem Cloud-Browser kostet pro Seite mehr als eine einfache Anfrage – daran führt kein Weg vorbei, denn eine vollständige Browser-Sitzung leistet schlicht mehr Arbeit. Hier unterscheiden sich die beiden Ansätze tatsächlich:
| Einfache HTTP-Anfragen | Scraping mit dem Floppydata-Cloud-Browser | |
|---|---|---|
| Per JavaScript gerenderte Seiten | Kommt leer zurück | Wird vollständig gerendert, wie bei einem echten Besucher |
| Kosten pro Seite | Niedriger | Höher, lässt sich aber durch Blockieren unnötiger Ressourcen senken |
| Inhalte hinter Login | Keine Sitzung, die erhalten bleibt | Cookies und Sitzung bleiben seitenübergreifend erhalten |
| Anti-Bot-Fingerprint | Keiner, leicht zu erkennen | Wird automatisch verwaltet |
| Bandbreite | Lädt alles | Kann Bilder, Schriftarten und CSS überspringen |
Bei statischen Inhalten ohne JavaScript und ohne Bot-Schutz gewinnen einfache Anfragen bei den Kosten weiterhin – es gibt keinen Grund, für eine Seite, die nie einen Browser brauchte, eine vollständige Browser-Sitzung zu starten. In allen anderen Fällen fällt Scraping mit dem Cloud-Browser meist günstiger aus, wenn man die Wiederholungsversuche, Proxys und manuellen Anpassungen einrechnet, die ein reines Anfrage-Setup ohnehin benötigt. Sobald eine Zielseite aktiv Gegenwehr leistet, spricht die Rechnung selten für einfache Anfragen.