Die meisten Ratgeber zu JavaScript-lastigen Websites hören bei der ersten Entscheidung auf: Braucht diese Seite überhaupt einen Browser? Diese Frage ist wichtig, und sie wird ausführlich beantwortet in wann Sie wirklich einen Headless-Browser zum Scrapen brauchen. Ein überraschend großer Anteil der „JavaScript-Websites“ stellt sich als gar nicht darauf angewiesen heraus.
Dieser Leitfaden setzt dort an, wo jener aufhört. Sie haben bestätigt, dass das Ziel tatsächlich Rendering benötigt. Jetzt gibt es eine zweite Entscheidung, die Ihre Kosten und Ihren Bereitschaftsdienst weitaus stärker prägt als die erste: Betreiben Sie die Browser selbst, oder senden Sie die Seite an eine Web-Scraping-API, die sie für Sie betreibt?
Bestätigen Sie zunächst, dass die Seite wirklich Rendering benötigt
Ein kurzer Check, bevor Sie sich auf einen der beiden Wege festlegen, denn Rendering ist immer die langsamere und schwerere Option.
Vergleichen Sie die Quelle mit der gerenderten Seite. Öffnen Sie die rohe HTML-Antwort. Wenn die gewünschten Daten darin enthalten sind, brauchen Sie keinen Browser.
Achten Sie auf eingebetteten Zustand. Viele JavaScript-Frameworks liefern die anfänglichen Seitendaten als JSON in einem Script-Tag aus, damit der Browser die Seite ohne zusätzliche Anfrage hydrieren kann. Wenn Ihre Daten in diesem JSON stecken, genügt eine einfache HTTP-Anfrage plus JSON-Parsing.
Beobachten Sie die Netzwerkanfragen. Wenn die Seite ihre Daten nach dem Laden von einem JSON-Endpunkt abruft, ist es meist günstiger, diesen Endpunkt direkt anzufragen, als die Seite drumherum zu rendern.
Wenn keiner der drei Wege zu den Daten führt, oder der Endpunkt signiert, undurchsichtig oder auf eine Weise geschützt ist, die Sie nicht nachbilden können, brauchen Sie Rendering. Lesen Sie weiter.
Was der Betrieb eigener Browser tatsächlich bedeutet
Ein Headless-Browser auf einem Laptop ist einfach. Eine Flotte davon in Produktion ist ein Betriebsproblem, und die Kosten werden leicht unterschätzt, weil keine von ihnen in einem Prototyp sichtbar wird.
Kapazität. Jede Browser-Instanz ist speicherhungrig, was begrenzt, wie viele auf einer Maschine laufen können, und Nebenläufigkeit zu einer Infrastrukturrechnung macht.
Stabilität. Browser hängen sich auf, verlieren Speicher und stürzen bei feindseligen Seiten ab. Produktionsflotten brauchen Watchdogs, Recycling und eine Warteschlange, die überlebt, wenn ein Worker mitten auf einer Seite stirbt.
Wartung. Browser-Versionen, Automatisierungsbibliotheken und der Automatisierungs-Fingerabdruck ändern sich alle. Eine Flotte, die letztes Quartal funktionierte, kann ausfallen, ohne dass sich eine Zeile Ihres Codes geändert hat.
Proxys. Gerendeter Traffic braucht weiterhin gute IPs, korrekt in den Browser eingebunden mit Authentifizierung und Isolation pro Kontext. Das richtig hinzubekommen ist eine eigene Aufgabe; siehe Residential Proxys mit Playwright verwenden.
Blockaden und Herausforderungen. CAPTCHAs und Anti-Bot-Prüfungen brauchen Erkennung, Behandlung und Wiederholungsversuche, und ein gescheiterter Versuch hat trotzdem die dafür aufgewendete Browserzeit verbraucht.
Wiederholungen und Warten. Zu wissen, wann eine dynamische Seite fertig geladen hat, und was zu tun ist, wenn nicht, ist Logik, die Sie pro Website schreiben und pflegen müssen.
Nichts davon ist exotisch. Es ist einfach Arbeit, die niemand einem Kunden in Rechnung stellt, und sie wächst mit jedem neuen Ziel.
Was eine Web-Scraping-API Ihnen abnimmt
Eine Web-Scraping-API verwandelt diese Liste in Anfrageparameter. Mit der Shifter Web Scraping API:
- Rendering.
render_js=1führt die Seite in headless Chrome aus, abgerechnet mit demselben einen Credit wie ein statischer Abruf. - Warten.
wait_for_csshält die Erfassung an, bis ein Selektor erscheint, undtimeoutbegrenzt die Browserzeit pro Seite. - Interaktion.
js_instructionsführt eine Kette vonscrollTo,clickundwait-Schritten vor der Erfassung aus, was Cookie-Banner, Load-more-Buttons und scroll-ausgelöste Inhalte abdeckt. - Strukturierte Ausgabe.
extract_rulesliefert JSON aus CSS-Selektoren, sodass kein Parser bereitgestellt werden muss. - Wiederholungen. Gescheiterte Abrufe, CAPTCHAs und vorübergehende Zielfehler werden automatisch wiederholt, bis zu dreimal, mit unterschiedlichen Proxys.
- Herausforderungen. Der Stealth-Modus ist standardmäßig aktiviert, und reCAPTCHA sowie hCaptcha werden während gerenderter Anfragen im laufenden Betrieb behandelt.
- IPs. Growth-Pläne und höher leiten über den Residential- und Mobile-Pool mit globaler Geolokalisierung. Starter nutzt Rechenzentrums-IPs in den USA und der EU, was für viele ungeschützte Seiten ausreicht.
- Sitzungen.
session_idhält Cookies, Browserzustand und die vorgelagerte IP über einen mehrstufigen Ablauf hinweg aufrecht und läuft nach 10 Minuten Inaktivität ab. - Abrechnung. Ein Credit pro erfolgreicher Antwort. Gescheiterte Anfragen, Zielfehler und die eigenen Wiederholungsversuche der API werden nicht berechnet.
Die Nebenläufigkeit ist pro Plan gedeckelt, von 20 bei Starter bis 500 bei Enterprise, und Anfragen über dem Limit liefern 429 zurück. Die vollständige Parameterreferenz beginnt bei JavaScript rendern.
Wann eigene Browser weiterhin die richtige Wahl sind
Eine API ist nicht immer die Antwort, und es lohnt sich, klar zu benennen, wo sie es nicht ist.
Lange interaktive Sitzungen. Ein Ablauf, bei dem ein Browser lange auf einer Website bleiben muss, mit Pausen länger als das Leerlauf-Fenster einer Sitzung, passt besser zu einem eigenen Browser.
Beliebige Browser-Logik. Wenn eine Seite eigene Skripte, Erweiterungen oder Interaktionen über Scrollen, Klicken und Warten hinaus benötigt, ist ein von Ihnen kontrollierter Browser flexibler.
Eigene Infrastruktur ist eine Anforderung. Manche Workloads müssen aus vertraglichen oder Sicherheitsgründen innerhalb eines bestimmten Netzwerks oder einer bestimmten Umgebung laufen.
Sehr großes, sehr stabiles Volumen. Bei ausreichender Skalierung auf Zielen, die sich selten ändern, kann eigene Infrastruktur pro Seite weniger kosten, vorausgesetzt Sie haben bereits die Ingenieure, um sie zu betreiben.
Testen und Debuggen. Visuelle Regression, schrittweises Debuggen und alles, wo ein Mensch den Browser beobachten muss, gehört auf die eigenen Maschinen.
Eine Entscheidungstabelle pro Ziel
Treffen Sie die Wahl pro Ziel, nicht pro Unternehmen. Die meisten ausgereiften Scraping-Stacks nutzen alle drei Wege.
| Ziel sieht so aus | Bester Weg |
|---|---|
| Daten im rohen HTML oder eingebetteten JSON | Einfache HTTP-Anfrage |
| Daten von einem wiederholbaren JSON-Endpunkt | Einfache HTTP-Anfrage an den Endpunkt |
| Gerenderter Inhalt, ungeschützt, geringes Volumen | Beides; eine API ist weniger Arbeit |
| Gerenderter Inhalt hinter Anti-Bot-Prüfungen | Web-Scraping-API |
| Gerenderter Inhalt über viele Märkte hinweg | Web-Scraping-API mit Land pro Anfrage |
| Lange authentifizierte Sitzungen oder eigene Browser-Logik | Eigene Browser mit Residential Proxys |
| Riesiges, stabiles Volumen mit internem Team | Eigene Browser, bewertet nach Gesamtkosten |
Vergleichen Sie nach Kosten pro nutzbarer Seite
Der übliche Fehler bei dieser Entscheidung ist, den Preis pro Anfrage einer API mit den Kosten eines Servers zu vergleichen und zu schließen, der Server sei günstiger.
Der faire Vergleich sind die Kosten pro nutzbarer Seite. Für Ihre eigene Flotte umfasst das Rechenleistung für Browser, die leerlaufen oder abstürzen, Proxy-Bandbreite für gescheiterte Versuche und die Ingenieurszeit, die für Wartung, Wiederholungen und die Behandlung von Herausforderungen aufgewendet wird, geteilt durch die Seiten, die tatsächlich korrekte Daten geliefert haben. Bei einer API, die nur für erfolgreiche Antworten berechnet wird, werden Fehlversuche nicht in Rechnung gestellt, sodass der Preis pro Credit den tatsächlichen Kosten pro nutzbarer Seite viel näher kommt, auch wenn Sie weiterhin für erfolgreiche Seiten bezahlen, die sich als nutzlos herausstellen, etwa wenn ein geänderter Selektor leere Felder zurückgibt.
Führen Sie dieselbe Stichprobe echter Ziel-URLs eine Woche lang über beide Wege aus, zählen Sie die Seiten, die korrekte, vollständige Daten geliefert haben, und vergleichen Sie die beiden Kosten pro nutzbarer Seite. Diese Zahl entscheidet den Streit schneller als jede Feature-Liste. Pläne für die API finden sich auf der Preisseite.
Wo sich die beiden treffen
Die Wahl ist selbst für eine einzelne Website nicht binär. Ein häufiges und sinnvolles Muster ist, überall dort einfaches HTTP zu verwenden, wo eine Seite kein Rendering benötigt, gerenderte und geschützte Seiten an die API zu senden und eine kleine Browser-Einrichtung für die wenigen Abläufe zu behalten, die eigene Logik brauchen.
Infinite Scroll und Load-more-Feeds liegen genau auf dieser Grenze, und die Techniken zu deren Behandlung innerhalb eines Renderings werden behandelt in wie man Infinite Scroll und dynamische Paginierung handhabt. Wie eine API all das hinter einer einzigen Anfrage zusammensetzt, wird erklärt in wie funktioniert eine Web-Scraping-API.
FAQ
Ist Rendering mit einer API teurer?
In Bezug auf Latenz ja, weil ein Browser länger braucht als eine einfache Anfrage. In Credits nein: Eine gerenderte Anfrage kostet denselben einen Credit wie ein statischer Abruf.
Kann eine API jedes Anti-Bot-System handhaben?
Nicht jedes, jedes Mal. Die meisten Prüfungen werden behandelt, und ein durchgehend blockierendes Ziel ist etwas, das der Support anpassen kann. Messen Sie Ihre eigene Erfolgsrate bei Ihren eigenen Zielen, bevor Sie sich darauf verlassen.
Brauche ich noch Proxys, wenn ich eine API verwende?
Keine separate Proxy-Einrichtung. Die API leitet Anfragen über ihre eigenen Pools, Residential und Mobile bei Growth-Plänen und höher.
Wann sollte ich von einer API zu eigenen Browsern wechseln?
Wenn Sie Browser-Verhalten benötigen, das die API nicht bereitstellt, oder wenn ein gemessener Vergleich der Kosten pro nutzbarer Seite bei Ihrem tatsächlichen Volumen eigene Infrastruktur begünstigt, einschließlich der Ingenieurskapazität, sie zu betreiben.
Das Fazit
Zu entscheiden, dass eine Website JavaScript-Rendering benötigt, ist die einfache Hälfte. Die teure Hälfte ist zu entscheiden, wer die Browser betreibt. Ihre eigene Flotte kauft Flexibilität und bezahlt dafür mit Kapazität, Stabilität, Wartung, Proxys und der Behandlung von Herausforderungen. Eine API tauscht diese Flexibilität gegen Parameter, Wiederholungen und eine Abrechnung nur bei Erfolg.
Bestätigen Sie, dass eine Seite wirklich Rendering benötigt, wählen Sie pro Ziel statt pro Unternehmen, und klären Sie die Frage Eigenbau versus Kauf anhand gemessener Kosten pro nutzbarer Seite. Das Produkt finden Sie auf der Seite Web Scraping API.