Browserless-Test: Chrome als Service mit begrenzten Ressourcen

Browserless ist Headless Chrome als selbst gehosteter Service verpackt. Der Docker-Container läuft dauerhaft, nimmt Aufgaben per HTTP oder WebSocket entgegen und setzt gemeinsame Annahmegrenzen durch, statt in jeden einzelnen Aufrufer eingebettet zu werden. In den hier getesteten REST-Aufrufen hatte der Dienst im Leerlauf null Chrome-Prozesse, erzeugte während eines aktiven Requests Chrome-Prozesse und fiel danach wieder auf null zurück. Gepoolt werden also Service-Kapazität und Warteschlangenlogik — nicht ein verifizierter Satz vorgewärmter Browserprozesse.

Ich habe v2.55.0 in einer kontrollierten lokalen Testumgebung geprüft: der Start wurde in einzelne Phasen zerlegt, die Annahmekontrolle in drei Konfigurationen getestet, die Endpunkte gegen bekannte Referenzwerte abgeglichen, ein 30-Sitzungs-Soak ausgeführt und die Timeout-Grenze überprüft. Der nützliche Effekt war eher betrieblich als ein Geschwindigkeitsgewinn: Die Annahmelimits passten zu den für den Client sichtbaren Antworten, und die größten Fallstricke lagen vor allem in der Art der Bereitstellung.

Das wichtigste Ergebnis war kein Latenzwert. Browserless lässt Chrome nicht schneller starten — es versieht Chrome mit einer Türpolitik: eine feste Anzahl an Sessions im Inneren, eine Warteschlange dahinter und ein HTTP 429 für alle anderen. Diese Obergrenze verschob sich von 4 auf 8 auf 10, als ich zwei Umgebungsvariablen änderte, und die interne Zählung des Containers stimmte bei jedem einzelnen Request mit den Statuscodes meines Clients überein.

Was Browserless eigentlich ist

An der Einordnung scheitern viele. Browserless ist keine Bibliothek, die man importiert und aufruft. Es ist ein Docker-Image — ghcr.io/browserless/chromium — das man als langlebigen Dienst betreibt. Es vermittelt Browser-Aufgaben und stellt sie auf zwei Arten bereit: über REST-Endpunkte (/content, /scrape, /screenshot, /pdf sowie /function und /unblock) und über eine CDP/WebSocket-Schnittstelle, an die sich Puppeteer und Playwright per connect() anhängen können.

Ich habe die REST-Schnittstelle getestet. Der WebSocket-Pfad ist echt und weit verbreitet, wurde von mir aber nicht gemessen.

Die getestete Version war v2.55.0, geprüft am 27. Juli 2026.

Die Sternzahlen schwanken; betrachten Sie das als Momentaufnahme.

Die Lizenzgrenze: SSPL-1.0 oder kommerziell

Das Repository bietet Browserless unter SSPL-1.0 oder einer kommerziellen Browserless-Lizenz an. Lesen Sie die aktuelle Repository-LICENSE und die offizielle Open-Source-Bereitstellungsanleitung von Browserless, bevor Sie sich entscheiden. Dieser Artikel hat keine rechtliche Prüfung kommerzieller Produkte, proprietärer Anwendungen, CI-Systeme, gehosteter Dienste oder interner Deployments vorgenommen und ordnet diese Szenarien daher keiner Lizenz zu. Lassen Sie die Bereitstellungs- und Verteilungsform von einer Rechtsberatung oder der für Softwarelizenzen verantwortlichen Person prüfen.

Browserless verkauft außerdem gehostete Pläne. Preise und Definitionen von Nutzungseinheiten ändern sich häufig und waren nicht Teil dieses Self-Hosting-Tests; prüfen Sie sie daher auf der offiziellen Website und nicht in einer veralteten Tabelle hier als Beschaffungsnachweis.

Wie das Sitzungsmodell intern funktioniert

Der gemessene REST-Pfad verhielt sich wie browserbasierte Arbeit pro Request, aber dieser Testaufbau hat Browserless intern nicht tief genug analysiert, um einen neuen Browserprozess von jeder denkbaren Strategie zur Wiederverwendung von Kontexten zu unterscheiden. Was sich eindeutig zeigte, ist einfacher: im Leerlauf null Chrome-Prozesse, während eines aktiven Requests 11 Prozesse aus der Chrome-Familie und nach dem sequentiellen Lauf wieder null. In dieser Konfiguration gab es keinen Hinweis auf einen vorgewärmten Browser-Pool.

Der langlebige Node-Dienst lässt eine begrenzte Anzahl an Browser-Jobs zu, stellt weitere begrenzte Anfragen in eine Warteschlange und lehnt den Rest ab. Betrachten Sie dieses Annahmemodell als die unten gemessene architektonische Zusage. Leiten Sie aus dem Wort „Pool“ keine Wiederverwendung von Prozessen oder Kontexten ab; der Timing-Harness kann das nicht beweisen.

Die Annahmekontrolle wird über zwei Regler gesteuert:

• CONCURRENT — wie viele Sessions gleichzeitig laufen.
• QUEUED — wie viele zusätzliche Anfragen auf einen Slot warten dürfen.

Der /config-Endpunkt des Containers meldete Standardwerte von CONCURRENT=10, QUEUED=10, TIMEOUT=30000. Alles oberhalb von CONCURRENT + QUEUED wird sofort abgewiesen.

Authentifizierung ist nicht optional. Browserless v2 verlangt immer ein Token — wenn Sie TOKEN nicht setzen, erzeugt es beim Start zufällig eines und schreibt es auf stdout. Jeder REST-Aufruf trägt ?token=.

Für die Beobachtbarkeit gibt es /pressure (laufend, in Warteschlange, CPU, Speicher, kürzlich abgelehnt), /sessions und /config. Außerdem existiert ein /metrics-JSON-Export, der jedoch METRICS_JSON_PATH voraussetzt; ich habe ihn nicht verwendet. Das Image läuft zudem mit dumb-init als PID 1 — die dokumentierte Antwort auf die Zombie-Prozess-Probleme, die Container-Chrome seit Jahren begleiten.

Die Realität des Setups: ein Befehl und vier Dinge, die niemand in diesen einen Befehl packt

Die Installationszeile, die alle zitieren, ist tatsächlich nur ein docker run. Alles drumherum sollten Sie trotzdem einplanen.

Das Image ist 4,34 GB groß. Diese Zahl sollte Ihre Erwartungen prägen, nicht die Startlatenz. Das Manifest enthält sowohl linux/arm64 als auch linux/amd64; auf meinem arm64-Host zog Docker die native arm64-Variante. (Der User-Agent von Chrome im Container lautet trotzdem X11; Linux x86_64 — das ist nur der kosmetische Linux-UA von Chrome, keine Emulation. uname -m sagt aarch64. Dazu werden regelmäßig Bugs gemeldet.)

Ich habe bei jeder Messung --shm-size=2g verwendet. Der Testaufbau enthielt keinen Kontrolllauf mit dem Docker-Standard für /dev/shm, daher kann dieser Artikel 2 GiB nicht pauschal als zwingend bezeichnen oder die Fehlergrenze quantifizieren. Dimensionieren Sie es nach Browserzahl und Arbeitslast.

Das Token ist ein Bereitstellungsthema, keine Formalität. Ohne Token kann jeder, der Port 3000 erreicht, in Ihrem Netz einen Browser steuern.

Container-Netzwerk ist Ihr Problem. Mein Fixture lief auf dem Host, also erreichte der Container es über host.docker.internal (colima mappt das mit --add-host host.docker.internal:host-gateway). Ich habe mit einem reinen curl geprüft, dass der Container das Fixture wirklich erreicht, bevor ich irgendeiner Messung vertraute.

Meine Umgebung: colima 0.10.3 (6 CPU / 11,6 GiB) mit Docker 29.2.1 auf macOS 26.5.2 arm64. Der Test-Harness verwendete nur die Python-3-Standardbibliothek. Bei PNG und PDF prüfte er Dateisignaturen, nicht Decoder-Gültigkeit, Abmessungen, Seitenzahl, Vollständigkeit oder visuelle Genauigkeit.

Ein minimales, gleichwertiges Startkommando nutzt das fest gepinnte Image, ein explizites Token und die hier verwendete Shared-Memory-Zuweisung:

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

Sobald /pressure?token=... antwortet, testet ein authentifiziertes POST /content?token=... mit einem JSON-Body, der die Ziel-URL enthält, den REST-Pfad. Produktive Aufrufer brauchen außerdem begrenztes Retry mit Jitter für 429-Antworten; sofortiges erneutes Senden lässt sie nur wieder in dieselbe volle Warteschlange rennen.

Die Startkosten, zerlegt

Drei frische docker run-Starts, Mediane mit Min–Max:

Die mittlere Zeile lädt leicht zu viel Interpretation ein. Sie misst nicht den Browser-Start isoliert und zeigt nicht, dass Browserless Chrome schneller startet als eine In-Process-Bibliothek. Es handelt sich um einen HTTP-Roundtrip in einen Container plus Browserarbeit, Navigation und Antwortübertragung. Der ungefähr 0,17 Sekunden große Abstand zwischen erstem und späterem Aufruf kann Datei-, OS-, Chrome-, Node- oder Container-Cache-Effekte enthalten. Da die Chrome-Prozesse im Leerlauf null waren und der Test keine CDP-Spur oder Prozess-Timeline für diese Aufrufe erfasste, lässt sich dieser Unterschied nicht auf Browser-Wiederverwendung oder „amortisierte“ Startkosten zurückführen.

Außerdem: Das sind Werte aus der colima-VM auf macOS. Nacktes Linux auf echter Hardware verhält sich anders. Zitieren Sie die 0,78 s nicht als portablen SRE-Wert.

Hands-on: die Obergrenze von beiden Seiten finden

Der Vertrag CONCURRENT + QUEUED → 429 wird überall wiederholt, aber nirgends konkret demonstriert.

Das Setup: eine Fixture-Route, die serverseitig 5 Sekunden schläft, sodass jeder Request zuverlässig eine Session für eine bekannte Dauer belegt. Dann feuern Sie CONCURRENT + QUEUED + 4 Anfragen gleichzeitig ab und schauen, was zurückkommt — während ein separater Sampler-Thread /pressure abfragt, um die interne Zählung des Containers zu lesen.

Drei Dinge ergaben sich daraus.

Die Obergrenze ist jedes Mal exakt CONCURRENT + QUEUED. Erfolgreiche Antworten waren 4, 8 und 10 — jeweils genau die konfigurierte Summe. Die Ablehnungen entsprachen dem Überschuss, der in allen drei Läufen 4 betrug.

Die Obergrenze verschiebt sich. Sie ist keine im Image fest verdrahtete Konstante, sondern das, was Sie konfigurieren. Von 4 → 8 → 10 zu wechseln, indem man Umgebungsvariablen ändert, ist der Punkt, der das Ganze nützlich statt bloßer Trivia macht.

Und die beiden Signale sind unabhängig. Die Statuscodes meines Clients kamen aus echten HTTP-Antworten; /pressure kam aus der internen Zählung des Containers, abgefragt von einem anderen Thread. In diesen drei kurzen Läufen stimmten sie überein. Das macht /pressure zu einem brauchbaren Kandidaten für Produktionssignale, aber nicht zu einem vollständigen Autoscaling-Vertrag: Abfragefrequenz, Zurücksetzungssemantik, Aggregation über mehrere Replikate und Verhalten unter längeren gemischten Lasten müssen noch validiert werden.

Eine Nuance, die in den Bestehens-/Fehlschlagszahlen verborgen bleibt: Eine eingereihte Anfrage scheitert nicht — sie wartet, und sie kann lange warten. Bei (2, 2) und 5-Sekunden-Arbeit lagen die erfolgreichen Antworten irgendwo zwischen 5,7 s und 11,0 s, Median 8,3 s. Die End-to-End-Latenz erreichte also ungefähr zwei Session-Dauern. Der Testaufbau erfasste keine getrennten Zeitstempel für Annahme und Ausführung, kann also die gesamte Verzögerung nicht eindeutig der Warteschlange zuschreiben.

Wie das bei einem realen Job aussieht

Angenommen, Sie rendern jede Nacht 4.000 Produktseiten als PDF, und jede Seite dauert etwa 5 Sekunden. Sie setzen CONCURRENT=5, QUEUED=5. Ihre Durchsatzgrenze liegt dann bei 5 Seiten pro 5 Sekunden — also einer Seite pro Sekunde — und der Job dauert ungefähr 67 Minuten, wenn die Pipeline exakt voll bleibt. Das ist Mathematik auf Basis gemessenen Verhaltens, kein Benchmark; aber genau diese Rechnung sollten Sie vor dem Rollout anstellen.

Jede Anfrage, die eintrifft, nachdem alle laufenden und gepufferten Slots belegt sind, kann sofort ein 429 erhalten; die gleichzeitige Auslösung garantiert nicht, welche der ordinalen Anfragen das Rennen verliert. Ein Job-Runner sollte diese Antwort als Backpressure behandeln und mit begrenztem Retry plus Jitter arbeiten. Andernfalls droht, dass Seiten verloren gehen, während die übergeordnete Job-Buchhaltung weiterläuft — ein operatives Risiko, kein Fehlerszenario, das dieser Testaufbau demonstriert hat.

Hands-on: was die Endpunkte tatsächlich sehen

Um die Rendering-Treue ehrlich zu testen, versteckt die Fixture-Seite ihren Markierungs-Text vor jedem, der keinen echten Browser nutzt. Der sichtbare String Runtime Injected Marker 88 wird beim Laden aus JavaScript-Fragmenten zusammengesetzt, sodass in keinem Byte, das der Server sendet, ein zusammenhängendes Literal dafür existiert. Ein rein statischer Abruf dieser Seite liefert 702 Bytes und enthält keinen der Marker.

Dass /content 811 Bytes mit dem eingefügten Marker zurückgab, bedeutet, dass ein echtes Chromium die Seite gerendert hat, bevor das HTML zurückkam. /scrape holte einen Wert aus einem Node, der erst durch JavaScript existiert. Beides funktionierte mit null clientseitigem Automationscode — ein einziger authentifizierter POST.

Das ist das eigentliche Versprechen. Im selben Testdurchlauf verfehlte ein statischer Crawler diese Inhaltsklasse vollständig, und die In-Process-Browserbibliotheken (chromedp, rod, Selenium) erfassten sie erst, nachdem ich ein explizites Warten eingebaut hatte. Browserless erfasste sie mit einem curl-ähnlichen Request. Sie tauschen Automationscode gegen Bereitstellungsgewicht.

Zwei Grenzen dieser Aussage: Die Evidenz deckt die Inhaltsklassen meines Fixtures ab, nicht die Gesamtheit des modernen Webs. Und /unblock, der Anti-Detection-Endpunkt, wurde absichtlich nicht angefasst — aus diesen Ergebnissen sollte also kein Anti-Bot-Fähigkeitsversprechen abgeleitet werden. /function, /download und /performance wurden ebenfalls nicht getestet.

Hands-on: ein kurzer Rückstands-Check

Containerisiertes Chrome hat den Ruf, Leichen zurückzulassen, also habe ich 30 sequentielle Sessions mit CONCURRENT=3 ausgeführt und die Prozesse im Container gezählt.

Bevor ich dem Ergebnis vertraute, habe ich den Detektor kalibriert. Während eine Session lief, zählte der /proc-Enumerator 11 Prozesse aus der Chrome-Familie (Browser, Zygote, GPU, Renderer, Utilities). Das ist wichtig: Es beweist, dass das Instrument Chrome sehen kann, sodass die Null nach dem Lauf eine Messung und keine Blindheit ist. Ein Leak-Test, der „0 Prozesse“ meldet, ohne zu beweisen, dass er zählen kann, ist wertlos.

Nach 30 Sessions: 0 Chrome-Prozesse, 0 Zombies. Die einzigen Überlebenden waren dumb-init, node, Xvfb, start.sh und sh. /sessions zeigte im Leerlauf 0 an.

Container-Speicher laut docker stats (der für Betreiber sichtbare Wert, nicht der RSS eines einzelnen Prozesses):

Nettozuwachs über 30 Sessions: etwa 9,5 MB, und die Stichprobenkurve plattete nach Session 10 ab. Das passt nicht zu einem einfachen linearen Leak pro Session in diesem kurzen Fenster. Ein Node-Warmup ist eine plausible Erklärung — aber etwas, das diese Prozess- und Speicherreihe nicht beweisen kann.

Umfang: 30 sequentielle Sessions sind ein kleiner Soak-Test, kein Ausdauer- oder Lasttest mit Parallelität. Die seit Langem im Issue-Tracker auftauchenden EventEmitter-Listener-Warnungen sind genau die Art von Problem, das sich über Stunden und Tausende von Sessions zeigen kann; das habe ich nicht ausgeführt. Die belastbare Aussage ist nur, dass in diesem Fenster auf v2.55.0 kein Anwachsen von Chrome-Prozessen oder Zombies beobachtet wurde.

Die Timeout-Grenze

TIMEOUT ist als Regler dokumentiert. Ich wollte sehen, wie er zuschlägt.

Mit TIMEOUT=5000 lieferte eine Session, die eine Seite 15 Sekunden lang halten wollte, nach 5,007 s HTTP 408 statt einfach zu hängen. Diese einzelne Beobachtung bestätigt die Durchsetzung nahe der konfigurierten Grenze. Sie offenbart nicht die Timer-Implementierung und beweist auch nicht das Aufräumen des Slots; ein stärkerer Test würde den Versuch wiederholen, beobachten, dass /sessions und /pressure wieder in den Leerlauf zurückkehren, und dann bestätigen, dass eine folgende Anfrage den frei gewordenen Slot erhält.

Die Migrationsfalle: PREBOOT ist inert und verrät es nicht

Von allem, was ich gemessen habe, ist das der Befund, den ich vor einem Upgrade am liebsten auf den Tisch gelegt bekommen hätte.

Browserless 2.0.0 entfernte PREBOOT und KEEP_ALIVE — das Changelog sagt, sie seien entfernt worden, weil sie verwirrend waren, wenig bewirkten und Fehler verursachten. Nachvollziehbar. Das Problem entsteht, wenn eine v1-Konfiguration unverändert auf v2 kopiert wird — was der häufigste Upgradeweg ist.

Ich habe den Container mit -e PREBOOT=true gestartet und gegen den Standard gemessen:

Jeder Zeitwert liegt innerhalb des eigenen Min–Max-Bands der Standardvariante — das ist Rauschen, kein Effekt. Und nichts war vorgewärmt: Der PREBOOT=true-Container steht im Leerlauf mit null Browsern da, identisch zu einem ohne das Flag. Zwei weitere Signale, die keine Zahl sind:

• /config enthält gar keinen preboot-Schlüssel. Die Keys heißen concurrent, queued, timeout, token, maxCPU, maxMemory, retries und weitere.
• Kein Fehler. Keine Warnung. Nichts in den Container-Logs.

Ein v1-PREBOOT-Setup ist auf v2 also ein stiller Null-Effekt bei normalem Start und bei Log-Prüfungen. Der fehlende /config-Schlüssel plus unverändertes Verhalten ist das erkennbare Signal; Browserless gibt weder eine explizite Ablehnung noch eine Warnung aus. Eine Migrationsprüfung muss die tatsächlich angewendete Konfiguration inspizieren, statt einen grünen Start als Beweis dafür zu nehmen, dass jede Umgebungsvariable wirksam wurde.

KEEP_ALIVE ist der Gegenfall, und beide sollte man nicht in einen Topf werfen. Es wurde im selben Release entfernt, ist aber nicht still — ein kurzer Probeaufruf des Containers zeigt, dass es Environment variable of "KEEP_ALIVE" is deprecated and ignored. direkt auf stdout protokolliert. Das ist eine saubere Warnung für Betreiber. Ich habe KEEP_ALIVE nicht durch denselben Messaufbau geschickt wie PREBOOT, daher berichte ich das als Prüfung und nicht als Messwert. Die Richtung ist aber klar genug, um wichtig zu sein: Nur PREBOOT ist die stille Falle. Browserless ist bei KEEP_ALIVE ehrlicher, als es eine pauschale Zusammenfassung „v2 ignoriert Ihre v1-Flags“ vermuten ließe.

Vor- und Nachteile

Vorteile

• Annahmekontrolle, die exakt wie dokumentiert funktioniert und sich mit der Konfiguration verschiebt — bestätigt bei drei verschiedenen Obergrenzen, gleichzeitig über Client-Statuscodes und die interne Serverzählung.
• /pressure stimmte in drei kurzen Läufen mit den für den Client sichtbaren laufenden, wartenden und abgelehnten Werten überein; als einen möglichen Input für Autoscaling und Alerting kann man es durchaus betrachten.
• Echte Chromium-Renderings ohne clientseitigen Automationscode: Ein einziger authentifizierter POST machte JS-injizierten DOM-Inhalt sichtbar, den ein statischer Abruf derselben Seite nicht sehen kann.
• In einem 30-sequentiellen Lauf wurden keine sich anhäufenden Chrome-Prozesse beobachtet; nach dem Lauf gab es 0 Chrome-Prozesse und 0 Zombies.
• Ein TIMEOUT-Test lieferte bei 5,007 s ein 408 gegen ein Budget von 5,000 s; Aufräumen und Slot-Freigabe wurden nicht separat verifiziert.
• Auth standardmäßig aktiv: Alle vier REST-Endpunkte liefern ohne Token 401.
• Ein docker run bis zum bereiten Dienst in rund 0,78 s, und ein erstes Rendering 0,32 s danach.

Nachteile

• 4,34 GB Image. Das ist die ehrliche Hauptkostenposition und schlägt sich im Registry-Volumen, im CI-Cache und in der Kaltstartzeit des Deployments nieder.
• SSPL-1.0 oder kommerzielle Browserless-Lizenz. Prüfen Sie die genauen aktuellen Bedingungen gegen Ihr Bereitstellungs- und Verteilungsmodell.
• PREBOOT aus v1 wird in v2 akzeptiert und stillschweigend ignoriert — kein Fehler, keine Warnung, kein /config-Schlüssel.
• Sie betreiben einen Dienst statt nur eine Abhängigkeit einzubinden: Container, Token, Netzwerkpfad, Annahmegrenze und Upgrade-Verantwortung.
• Eingereihte Anfragen schoben die End-to-End-Latenz im (2, 2)-Lauf auf ungefähr zwei Session-Dauern; die reine Wartedauer wurde nicht separat gemessen.
• Die gemessene REST-Zeit enthält einen HTTP-Hop und isoliert weder die Browser-Startkosten noch beweist sie Browser-Wiederverwendung.

Wer es betreiben sollte — und wer nicht

Browserless rechtfertigt sein Gewicht, wenn mehr als eine Sache einen Browser braucht. Ein Rendering-Dienst, der von mehreren Apps gemeinsam genutzt wird, ein Team, das Screenshots und PDFs lieber hinter einem HTTP-Endpunkt als über eine Chrome-Abhängigkeit in jedem Dienst haben will, eine Job-Pipeline, die wirklich eine messbare Kapazitätsgrenze mit Backpressure braucht — genau dafür ist das gedacht. Wenn Sie ohnehin Docker betreiben und jemand den Deployments gehört, ist die Betriebsstory klar: vorhersehbare Annahme, beobachtbare Backpressure und im 30-Session-Check keine sich ansammelnden Chrome-Prozesse oder Zombies.

Es ist auch die richtige Wahl, wenn die Alternative wäre, dass jeder Dienst in Ihrem Stack sein eigenes Chromium installiert. Das in einem Container mit Token und Obergrenze zu zentralisieren, ist architektonisch wirklich sinnvoll.

Lassen Sie es weg, wenn Sie nur ein Skript schreiben. 4,3 GB herunterzuladen und einen Container zu betreiben, damit eine einzelne Python-Datei eine gerenderte Seite abholen kann, ist viel Zeremonie für einen kleinen Job — eine Browser-Bibliothek im eigenen Prozess macht das ohne separaten Service-Deploy. Lassen Sie es weg, wenn die SSPL-Bedingungen für Ihr kommerzielles Produkt nicht passen und Sie sie nicht auflösen können. Lassen Sie es weg, wenn Sie eigentlich einen Browser wollen, der vorgewärmt und ohne Kaltstartkosten auftaucht, denn PREBOOT liefert das auf v2 nicht. Und lassen Sie es weg, wenn Ihr eigentliches Problem Anti-Bot-Handling ist, denn das steckt in einem Endpunkt, den ich absichtlich nicht getestet habe und für den ich nicht bürge.

Alternativen, inklusive der Rolle von Thunderbit

Der Vergleich, der sich wirklich lohnt, ist nicht Browserless gegen einen anderen Container. Es geht darum, wo der Browser läuft und wer dafür verantwortlich ist, ihn am Leben zu halten.

Verwandte Rezension: Browsertrix Crawler review.

Verwandte Rezension: chromedp review.

Wenn Sie einen Browser im eigenen Prozess wollen und es Ihnen nichts ausmacht, Waits zu schreiben, ist eine Bibliothek leichter und erfordert kein Deployment. Die entsprechende Seite habe ich im Playwright-vs-Puppeteer-Vergleich und im breiteren Überblick über Open-Source-Scraping-Projekte beschrieben.

Wenn Sie überhaupt keinen Browser betreiben wollen, ist unser eigenes Thunderbit eine verwaltete Alternative. Browserless liefert gerendertes Material, das Ihr Code interpretiert; Thunderbit kann Markdown oder schematisch passende Daten zurückgeben, während der Anbieter die Rendering-Infrastruktur betreibt. Dieser Artikel hat weder Thunderbits Latenz, Kapazität, Fehlverhalten, Extraktionsqualität noch Kosten gebenchmarkt, daher beschreibt die Tabelle Verantwortungsgrenzen und keinen Performance-Vergleich.

Verwandte Lektüre aus derselben Testreihe: Die Crawl4AI review behandelt eine Browser-gestützte Markdown-Pipeline, die Sie selbst betreiben, und der Überblick über Web-Scraping-Tools ordnet die breitere Kategorie ein.

Thunderbit für Web-Datenextraktion testen

Fazit

Sollten Sie Browserless betreiben? Ja, wenn mehrere Aufrufer Browser-Arbeit benötigen, jemand den Container betreiben kann und Ihre Lizenzprüfung das Bereitstellungsmodell freigibt. In drei synthetischen Annahme-Tests entsprach die akzeptierte Anzahl CONCURRENT + QUEUED, Überschuss erhielt 429, und /pressure stimmte mit den für den Client sichtbaren Werten überein. In einem separaten 30-Session-Sequenztest sammelten sich keine Chrome-Prozesse oder Zombies an. Ein Timeout-Test lieferte nahe der konfigurierten Grenze ein 408. Das sind nützliche, begrenzte Beobachtungen — keine universellen Garantien.

Kalkulieren Sie die Verpflichtung aber ehrlich. Es ist ein 4,34 GB großes Image und ein Dienst, den Sie betreiben, nicht nur eine Bibliothek, die Sie hinzufügen; dieser Test hat keinen Geschwindigkeitsvergleich mit einer Browser-Bibliothek im selben Prozess erbracht. Der Nutzen ist ein Browser, den Sie rationieren können: eine bekannte Obergrenze und messbare Backpressure. Im 30-Session-Sequenzcheck wurden keine sich anhäufenden Chrome-Prozesse oder Zombies beobachtet. Die Kosten sind Deployment-Gewicht und eine Lizenz, die Sie lesen müssen. Wenn Sie nur ein paar Seiten aus einem Skript rendern, lohnt sich dieser Tausch nicht. Wenn Sie aber eine Rendering-Schicht betreiben, von der mehrere Dienste abhängen, dann schon — prüfen Sie nur vor dem Umstieg Ihre v1-Umgebungsvariablen, denn PREBOOT sitzt sonst da, als wäre es beschäftigt, und tut absolut gar nichts.

Thunderbit für Web-Datenextraktion testen Get Started Free

FAQs

Macht Browserless Headless Chrome schneller? Dieser Test kann das nicht beantworten. Der HTTP-Endpunkt war 0,78 s nach docker run erreichbar; der erste /content-Aufruf dauerte dann 0,32 s und spätere Aufrufe im selben Container etwa 0,15 s. Diese Werte kombinieren HTTP-Roundtrip, Browserarbeit, Navigation und Antwortübertragung. Der Testaufbau hat die Startzeit nicht isoliert, die Prozess-Wiederverwendung nicht getraced und keinen vergleichbaren In-Process-Benchmark veröffentlicht. Nutzen Sie Browserless als gemeinsam genutzte Dienstgrenze mit Annahmekontrolle und benchmarken Sie dann Ihre eigene Latenzstrecke.

Was passiert, wenn ich das Browserless-Limit für Parallelität überschreite? Sie erhalten sofort HTTP 429. Die Obergrenze ist exakt CONCURRENT + QUEUED, und ich habe das in drei Konfigurationen bestätigt: (2,2) akzeptierte 4 und lehnte 4 ab, (3,5) akzeptierte 8 und lehnte 4 ab, (5,5) akzeptierte 10 und lehnte 4 ab. Der /pressure-Endpunkt des Servers meldete jedes Mal passende Werte für laufend, in Warteschlange und recentlyRejected. Wichtig: Warteschlangen-Anfragen scheitern nicht, sie warten — bei (2,2) und 5-Sekunden-Arbeit lagen erfolgreiche Antworten zwischen 5,7 s und 11,0 s. Behandeln Sie 429 im Client als Backpressure mit Retry und Backoff.

Funktioniert PREBOOT in Browserless v2 noch? Nein. PREBOOT wurde in 2.0.0 entfernt, und v2 akzeptiert -e PREBOOT=true ohne Fehler oder Warnung, macht aber nichts damit. Ich habe die Inertheit auf drei Arten bestätigt: Die Latenz war vom Standard nicht zu unterscheiden, ein im Leerlauf laufender PREBOOT=true-Container hatte 0 wartende Chrome-Prozesse, und /config zeigt überhaupt keinen preboot-Schlüssel. Wenn Sie eine v1-Konfiguration migriert haben, sind Ihre Instanzen nicht vorgewärmt. Beachten Sie, dass KEEP_ALIVE, das im selben Release entfernt wurde, tatsächlich eine Warnung „deprecated and ignored“ protokolliert — das stille Fehlerproblem betrifft also speziell PREBOOT.

Ist Browserless für kommerzielle Nutzung kostenlos? Das Repository bietet SSPL-1.0 oder eine kommerzielle Browserless-Lizenz an, aber dieser Artikel ordnet keine konkreten kommerziellen oder proprietären Szenarien einer der beiden Optionen zu. Prüfen Sie die aktuelle LICENSE und die offizielle Bereitstellungsanleitung und lassen Sie dann die für Softwarelizenzen verantwortliche Person Ihr Bereitstellungs- und Verteilungsmodell bewerten.

Lässt Browserless Zombie-Chrome-Prozesse zurück? In dem getesteten kurzen Fenster wurde keiner angesammelt. Nach 30 sequentiellen Sessions hatte der Container 0 Chrome-Prozesse und 0 Zombies; übrig blieben nur dumb-init, node, Xvfb, start.sh und sh. Der Detektor zählte 11 Prozesse aus der Chrome-Familie, während eine Session lief, war also nicht blind. Der Container-Speicher stieg von 294 MiB auf 303 MiB und plateauierte dann in den Stichproben. Das ist kein Ausdauerergebnis über Stunden, Parallelität oder Tausende von Sessions.