ScraperFlyWebdaten-API für KI

rendering

Gerenderte HTML-API für mit JavaScript erstellte öffentliche Seiten

Rufen Sie öffentliche Seiten ab, nachdem JavaScript auf der Client-Seite das nützliche DOM erstellt hat. ScraperFly hilft Entwicklern, den rohen Quell-HTML mit gerendertem HTML zu vergleichen, parserbereite Markup zurückzugeben und das Rendering als evidenzbasierte Anforderungssteuerung zu verwenden, anstatt es als Standardkosten für jede URL zu betrachten.

Gerenderte HTML-Erfassung

Erfassen Sie das DOM, nachdem JavaScript die Seite abgeschlossen hat

Einige öffentliche Seiten liefern nützliche Inhalte in der ersten HTML-Antwort. Andere senden eine dünne Hülle und erstellen den Artikel, die Produktliste, die Tabelle, die Route oder das Suchergebnis erst, nachdem das browserseitige JavaScript ausgeführt wurde. Gerenderte HTML ist für diesen zweiten Fall gedacht: wenn der Parser das endgültige DOM benötigt, nicht nur das Quell-Markup.

ScraperFly ermöglicht es Teams, rohes HTML mit browsergerenderter HTML zu vergleichen und das Rendering nur für Ziele zu aktivieren, die nachweisen, dass sie es benötigen. Sie halten einfache Seiten schnell und kostengünstig, während Sie dennoch einen klaren Upgrade-Pfad für öffentlich zugängliche Inhalte, die mit JavaScript erstellt wurden, haben.

roh vs gerendertDOM vollständigparser-bereites Markup
Entwickler vergleichen Quell-HTML mit gerendertem HTML, nachdem die Browserausführung das DOM abgeschlossen hat

Was ist eine gerenderte HTML-API?

Eine gerenderte HTML-API ruft eine öffentliche Seite ab, führt browserseitiges JavaScript aus, wartet, bis der Seitenstatus stabil ist, und gibt das resultierende HTML-Markup zurück. Anstatt die ursprüngliche Quellantwort zu parsen, erhält Ihre Anwendung das DOM, nachdem das Frontend die nützlichen Inhalte erstellt hat.

Dies unterscheidet sich von einem Screenshot oder PDF. Ein Screenshot beweist, wie die Seite aussah. Ein PDF bietet einen tragbaren visuellen Nachweis. Gerenderte HTML behält die Seite als Markup, sodass Parser weiterhin Überschriften, Links, Tabellen, Attribute, Produktkarten, Artikeltexte, Seitenzahlen, eingebettete Daten und wiederholte DOM-Muster inspizieren können.

Praktische Erkenntnis: Verwenden Sie gerenderte HTML, wenn JavaScript das Markup ändert, das Ihr Parser benötigt, nicht wenn eine einfache Quellanforderung bereits vollständige Inhalte zurückgibt.

Wann sollte eine Seite gerenderte HTML anstelle von rohem HTML verwenden?

Die Entscheidung sollte auf Beweisen basieren. Beginnen Sie mit rohem HTML, überprüfen Sie, was zurückkommt, und vergleichen Sie es mit einer gerenderten Erfassung. Wenn die Quellantwort bereits den nützlichen Artikeltext, die Tabelle, die Produktdaten, Links oder Metadaten enthält, halten Sie die Anfrage leicht. Wenn die Quellantwort den Inhalt vermisst, leere Routencontainer enthält oder nur Platzhalter anzeigt, ist gerenderte HTML der bessere Input.

ZielverhaltenWas rohes HTML zeigtBessere Anfrage
Statische öffentliche SeiteVollständiger Text, Links und Metadaten erscheinen in der ersten Antwort.Verwenden Sie rohes HTML, Text oder Markdown ohne Browser-Rendering.
Client-gerenderte SeiteDie Antwort enthält eine App-Hülle, einen Routencontainer oder einen leeren Inhaltsbereich.Verwenden Sie gerenderte HTML, damit der Parser das abgeschlossene DOM sieht.
Verzögerte InhalteWichtige Karten oder Tabellen erscheinen erst, nachdem asynchrone Anfragen abgeschlossen sind.Verwenden Sie Rendering mit einer gemessenen Wartezeit anstelle von blinden Wiederholungen.
Layout-Nachweis benötigtDer Parser benötigt Markup, aber die Prüfer benötigen auch visuelle Beweise.Verwenden Sie gerenderte HTML zum Parsen und Screenshots oder PDFs nur für ausgewählte Nachweisaufzeichnungen.
Regionale oder zustandsabhängige InhalteDas sichtbare Ergebnis ändert sich je nach Sprache, Standort, Cookies oder vorherigem Zustand.Testen Sie Header, Länderrouting oder Sitzungen, bevor Sie das Rendering zur Standardoption machen.

Was können Teams aus gerenderter HTML extrahieren?

Gerenderte HTML ist immer noch HTML. Das macht es nützlich, wenn nachgelagerter Code Selektoren, Attribute, strukturelle Beziehungen, kanonische Links, Seitenzahlen, Produktkarten, geladene Kommentare, hydratisierte Artikeltexte oder jeden Seitenabschnitt benötigt, der nach der Frontend-Ausführung erscheint. Es gibt Ihrem Parser das endgültige Markup, ohne dass ein Mensch einen Screenshot lesen muss.

Die API beseitigt nicht die Notwendigkeit für zielgerichtete Regeln. Ihre Anwendung entscheidet weiterhin, welche Felder wichtig sind, wie Datensätze validiert werden, wie Duplikate behandelt werden und wohin extrahierte Daten gehen. ScraperFly kümmert sich um die Erfassungsseite: Browserausführung, Anfrageoptionen, Antwortformate, Metadaten und Lieferkontrollen.

ParserbedarfGerenderte HTML hilft, weilNützliche Begleit-Ausgabe
Produkt- oder ListenkartenDas endgültige DOM enthält wiederholte Elemente, die die Quellantwort möglicherweise nicht enthält.JSON-Metadaten für Status und endgültige URL.
Artikeltext-ErfassungHydratisierte Inhalte können als Markup geparsed werden, nachdem der Browser ausgeführt wurde.Text oder Markdown für eine lesbare Überprüfung.
Such- oder KategorieseitenGerenderte Abschnitte zeigen Links, Filter, Seitenzahlen und sichtbare Anordnung.Screenshot für gelegentliche QA-Nachweise.
Überwachungs-WorkflowsDer Parser kann das abgeschlossene Markup vergleichen, anstatt leere Hüllen zu verwenden.Metadaten und Antwortgröße für Änderungsdiagnosen.
AI- oder RAG-EingabeGerenderte HTML kann in saubereren Text oder Markdown umgewandelt werden, nachdem dynamische Inhalte erscheinen.Markdown für modellbereiten Kontext.

Für breitere Formatentscheidungen vergleichen Sie die Antwortformate der Web-Scraping-API. Wenn Ihr Workflow den vollständigen Browserausführungsweg benötigt, überprüfen Sie auch die JavaScript-Rendering-API-Seite.

Wie sollten Teams gerenderte HTML vor der Produktion testen?

Wählen Sie einige repräsentative öffentliche URLs aus und testen Sie sie im API Builder. Vergleichen Sie rohes Quell-HTML, gerenderte HTML, Antwortgröße, endgültige URL, Inhaltstyp und Wartezeit. Das Ziel ist nicht, das Rendering überall zu aktivieren. Das Ziel ist es, herauszufinden, welche Zielgruppen es benötigen und welche auf einem günstigeren, schnelleren Anfrageprofil bleiben können.

Wenn eine gerenderte Anfrage leer ist, schreiben Sie den Parser nicht sofort um. Überprüfen Sie zuerst, ob die Seite umgeleitet wurde, einen Zustimmungs- oder Blockierungszustand zurückgegeben hat, eine längere Wartezeit benötigte, sich nach Land oder Sprache geändert hat oder eine Antwort zurückgegeben hat, die zu groß für die beabsichtigte Erfassung ist. Gutes Debugging trennt Erfassungsprobleme von Parserproblemen.

Praktische Erkenntnis: Gerenderte HTML sollte gegen echte Zielseiten validiert werden, bevor sie Teil eines wiederkehrenden Workflows wird.

Wie beeinflusst gerenderte HTML Kosten und Zuverlässigkeit?

Browserarbeit ist schwerer als ein einfacher Abruf. Genau deshalb behandelt ScraperFly das Rendering als bewusste Anfragekontrolle. Eine einfache öffentliche Seite sollte nicht die gleichen Betriebskosten wie eine JavaScript-intensive Seite zahlen, die eine Browserausführung, Wartezeiten, Screenshots, Dateien, Länderrouting oder Premium-Lieferung benötigt.

Verwenden Sie kostenlose Credits, um rohe und gerenderte Ergebnisse zu testen. Halten Sie einfache Erfassungen auf Quell-HTML, Text oder Markdown. Fügen Sie Rendering nur dort hinzu, wo es die Vollständigkeit verbessert. Verwenden Sie Pay-as-you-go-Credits, solange Ziele und Volumen noch unsicher sind, und wechseln Sie dann zu monatlichen Credits, sobald das Muster bewiesen ist. Die Preisseite und der Kreditkostenrechner helfen dabei, die Anfragegewichtung mit dem tatsächlichen Zielverhalten abzugleichen.

Wo passt gerenderte HTML in den ScraperFly-Workflow?

Gerenderte HTML sitzt zwischen der grundlegenden HTML-Erfassung und der vollständig visuellen Ausgabe. Beginnen Sie mit der HTML-Scraping-API, wenn das Quell-Markup vollständig ist. Wechseln Sie zu gerenderter HTML, wenn JavaScript das nützliche DOM erstellt. Wählen Sie Text oder Markdown, wenn der nachgelagerte Verbraucher lesbare Inhalte anstelle von Selektoren benötigt. Fügen Sie Screenshots oder PDFs hinzu, wenn der Workflow einen Nachweis über das Erscheinungsbild benötigt.

Dies ermöglicht es Teams, die erste Anfrage einfach zu halten, die Eskalation evidenzbasiert zu gestalten und den Parsern das Markup zu geben, das sie tatsächlich benötigen. Das Ergebnis sind weniger benutzerdefinierte Browserinfrastrukturen, weniger blinde Wiederholungen und ein klarerer Weg vom Testen der Ziele zur Produktionsaufnahme.

Gerenderte Zielanpassung

Bestätigen Sie, dass JavaScript das DOM ändert, bevor Sie das Rendering zur Standardoption machen.

Gerenderte HTML ist am stärksten, wenn das Quell-Markup unvollständig ist und die Browserausführung den Inhalt erstellt, den Ihr Parser benötigt. Überprüfen Sie rohes HTML, endgültige URL, Antwortgröße, sichtbaren Zustand und Wartezeit, bevor Sie ein gerendertes Anfrageprofil skalieren.

Roh-HTML-Antwort, die auf sichtbare Seitendaten abgebildet ist
01

Verfügbarkeit von Roh-HTML

Überprüfen Sie, ob die benötigten Felder bereits in der ersten HTML-Antwort vorhanden sind.

Bester erster Test für einfache Seiten, Artikel, Dokumente, Listen und Produktdetails.

Vergleich vor und nach der JavaScript-Rendering
02

JavaScript-Abhängigkeit

Vergleichen Sie das Roh-HTML mit dem gerenderten DOM oder Screenshot, bevor Sie das Browser-Rendering aktivieren.

Verwenden Sie Rendering, wenn das Roh-HTML nur eine Hülle ist und Skripte den nützlichen Inhalt erstellen.

Cookies, Zustimmung, Sitzung und Zugriffs-Kontext für das Scraping
03

Status & Zugriffs-Kontext

Identifizieren Sie, ob Cookies, Zustimmung, Anmeldegrenzen, Pagination oder der gleiche Besucherstatus die Antwort beeinflussen.

Verwenden Sie Sitzungen und Header, wenn die Kontinuität die Daten, die Sie erhalten, verändert.

Regionale Inhaltsvariationen über Länder und Routen hinweg
04

Geo-/Inhaltsvariation

Testen Sie, ob Land, Sprache, Währung, Inventar, SERP, Anzeigen oder Routenreputation das Ergebnis verändern.

Verwenden Sie Geo- oder Premium-Routing nur, wenn sichergestellt ist, dass die Antwort je nach Route variiert.

Fragen zur gerenderten HTML, die es wert sind, früh beantwortet zu werden.

Wo befindet sich das Ziel-Feld?

Finden Sie heraus, ob das Feld im Roh-HTML, im gerenderten DOM, einem API-Aufruf, strukturierten Daten, einer Datei oder einem späteren Interaktionszustand vorhanden ist.

Was ändert die Antwort?

Probieren Sie einige URLs aus und vergleichen Sie Status, endgültige URL, Inhaltslänge, Weiterleitungen, leere Zustände und sichtbare Ergebnisunterschiede.

Welcher Kontext ist erforderlich?

Markieren Sie alle Abhängigkeiten von Zustimmung, Gebietsschema, Cookies, Headern, Authentifizierungsgrenzen, Paginierung, Filtern oder vorherigen Anfragen.

Wie sieht ein Fehler aus?

Definieren Sie die Signale für blockierte, teilweise, veraltete, umgeleitete, leere, zeitüberschreitende oder regionsfremde Antworten, bevor Sie skalieren.

Signale zum Vergleichen, bevor das Rendering aktiviert wird.

Abrufmodus

Die Verfügbarkeit von Roh-HTML entscheidet, ob die erste Anfrage einfach bleiben kann oder Rendering, Wartezeiten, Screenshots oder Extraktion benötigt.

Anfragekontext

Statusanforderungen entscheiden, ob Header, Cookies, Sitzungen, Zustimmungsverwaltung oder ein stabiler Besucherprofil hinzugefügt werden müssen.

Routing-Wahl

Geo- und Reputationsfunde entscheiden, ob das Standard-Routing ausreicht oder eine Länder-/Premium-Route gerechtfertigt ist.

Validierungsregeln

Bekannte Fehlerzustände werden zu Prüfungen für Wiederholungen, Eskalationen, QA-Überprüfungen und zur Entscheidung, wann ein leichteres Profil dennoch vollständig ist.

Gerendeter HTML-Builder

Erstellen Sie eine Anfrage, die nur dann browsergerendertes Markup zurückgibt, wenn das Ziel es benötigt

Verwenden Sie den API Builder, um Quell-HTML mit gerenderter HTML zu vergleichen, das Warteverhalten auszuwählen und eine kanonische Anfrage zu kopieren, die Ihrem Parser das abgeschlossene DOM gibt, ohne einfache Ziele zu überlasten.

Markup
Markup

Rohes und gerendertes HTML

Beginnen Sie mit Quell-HTML und aktivieren Sie das Rendering, wenn die Browserausführung das nützliche DOM ändert.

Timing
Timing

Warten auf nützlichen Seitenstatus

Verwenden Sie Wartekontrollen, wenn Karten, Artikel, Tabellen oder Routeninhalte nach verzögerter clientseitiger Arbeit erscheinen.

Auswahl der Ausgabe
Auswahl der Ausgabe

Nach dem Rendern konvertieren, wenn es nützlich ist

Geben Sie gerendertes HTML für Parser zurück oder wählen Sie Text, Markdown, Screenshots oder PDFs, wenn der nachgelagerte Verbraucher sie benötigt.

Anforderungssteuerungen für die Erfassung von gerendertem HTML

url

Die öffentliche, mit JavaScript erstellte Seite, die erfasst werden soll.

render

Führen Sie die Browserausführung aus, wenn der Quell-HTML unvollständig ist.

render_wait

Warten Sie auf verzögerte Inhalte vor der Erfassung, wenn Beweise zeigen, dass das Timing wichtig ist.

format

Geben Sie gerendertes HTML oder ein anderes Ausgabeformat nach der Browserausführung zurück.

country

Verwenden Sie Länderrouting, wenn sich öffentliche Inhalte je nach Standort ändern.

download

Geben Sie visuelle Dateien zurück, wenn Screenshot- oder PDF-Beweise erforderlich sind.

cURL-Beispiel

Generieren Sie Markdown mit derselben Anfrageform, die Sie in die Produktion überführen können.

curl "https://scraperfly.com/api/v1?url=https%3A%2F%2Fexample.com&format=markdown" \
  -H "apikey: YOUR_API_KEY"

Kostenkontrolle für gerendertes HTML

Halten Sie das Rendering erschwinglich, indem Sie es nur dort verwenden, wo es die Vollständigkeit verbessert.

Die Ausführung im Browser ist schwerer als ein einfacher HTML-Abruf, daher sollte sie ihren Platz im Anforderungsprofil verdienen. ScraperFly hilft Teams, mit leichtgewichtigem Erfassen zu beginnen, das Rendering auf echten Zielen zu testen und schwerere Kontrollen für Seiten zu reservieren, bei denen sich das gerenderte DOM auf das Ergebnis auswirkt.

Eine leichte HTML-Anfrage, die eine einfache Antwort zurückgibt
01

Einfacher Abruf

Verwenden Sie einen einfachen Abruf, wenn das öffentliche HTML bereits die benötigten Felder enthält.

Leichtestes Anfrageprofil; behalten Sie es, wenn die Antwort vollständig ist.

JavaScript-Rendering, das ein vollständiges DOM erzeugt
02

Rendering

Verwenden Sie Rendering, wenn rohes HTML eine Hülle ist und JavaScript die Seite vervollständigt.

Schwereres Profil; verwenden Sie es nur, wenn die Browserausgabe das Ergebnis ändert.

Mehrere Anfragen, die Cookies und den Besucherstatus beibehalten
03

Zustandsbehaftete Sitzung

Verwenden Sie Sitzungen, wenn Cookies, Zustimmung, Sprache oder Paginierung die Antwort ändern.

Schwereres Zustandsprofil; bewahren Sie es nur, wenn Kontinuität wichtig ist.

Anforderungsrouting über Geo- und hochwertigere Routen
04

Premium-Routing & Geo

Verwenden Sie Premium-Routing oder Geo nur, wenn Herkunft, Land, Ruf oder regionale Inhalte das Ergebnis ändern.

Schwerstes Routing-Profil; wenden Sie es nur auf Ziele an, die nachweisen, dass sie es benötigen.

Was macht gerenderte Anfragen schwerer?

Mehr Infrastrukturarbeit

Browser-Rendering, Routing-Entscheidungen und längere Wartezeiten bedeuten, dass die Plattform mehr tun muss, als nur eine einfache Antwort zurückzugeben.

Mehr Zielunsicherheit

Weiterleitungen, leere Zustände, Ratenlimits und Challenge-Seiten erfordern oft stärkere Lieferoptionen oder Wiederholungen.

Mehr Zustand zu bewahren

Cookies, Sitzungen, Einwilligungen und mehrseitige Abläufe fügen bewegliche Teile hinzu, die ein einfacher zustandsloser Abruf nicht hat.

Mehr Beweise zurückzugeben

Screenshots, PDFs, gerenderte Ausgaben und reichhaltigere Antwortartefakte sind nützlich, aber sie sind schwerer als einfaches HTML.

Wie man gerendertes HTML vorhersehbar hält

Beispiel vor der Skalierung

Testen Sie zuerst eine kleine URL-Gruppe und gruppieren Sie Ziele nach dem leichtesten Profil, das vollständige Daten zurückgibt.

Standardmäßig nicht rendern

Überprüfen Sie das rohe HTML, bevor Sie das Rendering aktivieren. Viele öffentliche Seiten enthalten bereits die Daten, die Sie benötigen.

Eskalieren Sie anhand von Beweisen

Steigen Sie nur auf, wenn die Antwort fehlende Inhalte, Zustandsabhängigkeit, geo-variationen oder Routing-Probleme zeigt.

Nützliche Ergebnisse messen

Optimieren Sie basierend auf gültigen gelieferten Datensätzen, nicht auf dem Rohanfragevolumen. Ein leichteres Profil ist nur dann am besten, wenn es vollständig bleibt.

Gerenderte HTML FAQ

Häufige Fragen zum Erfassen von gerendertem HTML

Praktische Antworten für Teams, die entscheiden, wann öffentliche Seiten gerendert werden sollen, wie man rohen und gerenderten Markup vergleicht und wie man die richtige Ausgabe nach der Browserausführung auswählt.

Gerenderte FAQ

Anwendungsfälle für gerendertes HTML

Für Teams, die öffentlich zugängliche Seiten, die mit JavaScript erstellt wurden, ohne die Wartung einer Browserinfrastruktur parsen.

Was bedeutet gerendertes HTML?

Gerendertes HTML ist das Markup, nachdem JavaScript auf der Browserseite ausgeführt wurde und das endgültige DOM für die öffentliche Seite erstellt hat.

Wann reicht rohes HTML aus?

Roh-HTML reicht aus, wenn die erste Antwort bereits den nützlichen Text, Links, Tabellen, Karten oder Metadaten enthält, die Ihr Workflow benötigt.

Roh- vs. gerenderte Überprüfungen

Vergleichen Sie Beweise, bevor Sie Anforderungsprofile ändern.

Wie weiß ich, ob Rendering erforderlich ist?

Vergleichen Sie das Quell-HTML mit dem gerenderten HTML und überprüfen Sie den Status, die endgültige URL, die Antwortgröße, den Inhaltstyp, den sichtbaren Zustand und die Wartezeit.

Sollte ich eine Render-Wartezeit verwenden?

Verwenden Sie Wartezeiten, wenn nützliche Inhalte nach verzögerten clientseitigen Anfragen erscheinen. Halten Sie es zielgerichtet und nicht global.

Formate nach dem Rendern

Rendering kann verschiedene nachgelagerte Verbraucher bedienen.

Kann ich nach dem Rendering Markdown erhalten?

Ja. Rendern Sie die Seite, wenn nötig, und wählen Sie dann Markdown, wenn lesbare Überschriften, Links und Abschnitte besser für die Überprüfung oder KI-Eingabe geeignet sind.

Wann sollte ich stattdessen Screenshots verwenden?

Verwenden Sie Screenshots, wenn ein Mensch visuelle Beweise für das Erscheinungsbild der Seite benötigt. Verwenden Sie gerendertes HTML, wenn ein Parser Markup benötigt.

Anfragegewicht

Halten Sie die Browserausführung an bewährte Ziele gebunden.

Kostet gerendertes HTML mehr als rohes HTML?

Gerenderte Erfassung ist schwerer, da sie Browserarbeit ausführt. Beginnen Sie mit rohem HTML und aktivieren Sie das Rendering nur, wenn es die Antwort verbessert.

Kann ich rohe und gerenderte Anfragen mischen?

Ja. Halten Sie einfache Quellen bei leichter Erfassung und verwenden Sie gerendertes HTML nur für Zielgruppen, die eine Browserausführung benötigen.