Headless-Browser

Ein Headless-Browser ist ein Webbrowser ohne sichtbare Benutzeroberfläche. Er führt automatisiert Aufgaben wie Screenshots, Tests und Web Scraping aus.

So funktionieren Headless-Browser

Ein Headless-Browser verwendet die vollständige Engine von Chrome, Firefox oder Safari, öffnet aber kein grafisches Fenster. Er lädt HTML, führt JavaScript aus, wendet CSS an und rendert die Seite wie ein sichtbarer Browser. Die Ausgabe landet lediglich in einem nicht sichtbaren Puffer statt auf einem Monitor.

Gesteuert wird er per Code, meist mit Puppeteer für Chrome/Chromium oder Playwright für Chromium, Firefox und WebKit. Ein Skript ruft eine URL auf, wartet auf Inhalte, interagiert mit der Seite und erstellt Screenshots, ohne Maus oder Tastatur.

Ohne GUI braucht der Browser weniger Speicher und kann auf Servern, in CI und in Containern ohne Display laufen.

Typische Einsatzbereiche

• Automatisierte Screenshots: Produktseiten, Marketing-Websites, Dokumentationen und Wettbewerberseiten werden in großer Zahl erfasst.
• Visuelle Regressionstests: Aufnahmen vor und nach einer Codeänderung zeigen unbeabsichtigte UI-Abweichungen.
• Web Scraping: JavaScript-lastige Seiten werden gerendert und anschließend ausgelesen.
• PDF-Erstellung: Eine Webseite wird mit ihrem Browserlayout als PDF exportiert.
• Performance-Tests: Ladezeiten, Ressourcengrößen und Rendering werden ohne sichtbares Fenster gemessen.

Headless- und sichtbare Aufnahme

Eine sichtbare Aufnahme ist einfach, aber manuell: Seite öffnen, Fenster anpassen und Tastenkombination drücken. Das reicht für Einzelbilder, skaliert aber nicht.

Headless-Aufnahmen sind programmierbar. Ein Skript kann Hunderte Seiten in mehreren Viewport-Größen nacheinander oder parallel erfassen, auf einem Server laufen und in CI eingebunden werden. Die Ergebnisse bleiben unabhängig von der ausführenden Person einheitlich.

Das Rendering ist nahezu gleich. Abweichungen entstehen vor allem durch fehlende Systemschriften, Software- statt GPU-Rendering und Animationen ohne passenden Wartepunkt.

Für Screenshot-Produkte ist diese Konsistenz entscheidend. Sobald Viewport, DPR, Wartebedingungen und Cookies im Skript festgelegt sind, folgt jede Aufnahme demselben Rezept und lässt sich besser vergleichen und veröffentlichen.

Häufige Fehler

• Nicht auf Inhalte warten. Nach der Navigation können Lazy-Loading-Bilder, Webfonts und asynchrone Bereiche fehlen. Warte auf einen Selektor, Netzwerkruhe oder ein bestimmtes Element.
• Viewport und DPR nicht setzen. Die Standardgröße ist häufig nur 800 × 600. Lege Abmessungen und Skalierungsfaktor ausdrücklich fest.
• Schriften fehlen lassen. Server besitzen oft nicht dieselben Fonts wie Desktops. Installiere die benötigten Schriften oder nutze ein passendes Container-Image.
• Cookie-Banner und Pop-ups vergessen. Automatische Aufnahmen gelten als neuer Besuch. Schließe Dialoge im Skript, sonst verdecken sie den Inhalt.