Playwright

Playwright ist ein quelloffenes Automatisierungs-Framework von Microsoft, das Chromium, Firefox und WebKit steuert. Es wird für Tests, Screenshots und Webautomatisierung mit allen großen Browser-Engines eingesetzt.

Was Playwright kann

Playwright stellt eine einheitliche API zur Automatisierung der drei großen Rendering-Engines bereit: Chromium, auf dem Chrome und Edge beruhen, Gecko von Firefox und WebKit, die Engine von Safari. Diese browserübergreifende Unterstützung ist das zentrale Merkmal. Ein einziges Skript kann unverändert mit allen drei Engines ausgeführt werden.

Zu den wichtigsten Funktionen gehören:

• Browserübergreifende Automatisierung: Ein Skript lässt sich mit Chromium, Firefox und WebKit ausführen. Die benötigten Browser-Binärdateien installiert und verwaltet die Playwright-CLI.
• Screenshots: Seiten als PNG oder JPEG speichern, den sichtbaren Viewport, die ganze Seite oder ein bestimmtes Element aufnehmen sowie Viewport-Abmessungen und Geräteemulation festlegen.
• PDF-Erstellung: Gerenderte Seiten als PDF exportieren und Seitengröße, Ränder und Skalierung genau steuern.
• Netzwerkanfragen abfangen: Requests für Tests und Datenerfassung überwachen, simulieren oder verändern.
• Browserkontexte: Isolierte Browser-Sessions ähnlich Inkognito-Fenstern anlegen, die weder Cookies noch Speicher oder Zustand teilen. Damit kannst du Seiten für verschiedene Nutzertypen aufnehmen, ohne den Browser neu zu starten.
• Mehrere Programmiersprachen: Offizielle Anbindungen gibt es für JavaScript und TypeScript, Python, Java und .NET.

Besonders hilfreich ist Playwrights automatisches Warten. Anders als Bibliotheken, die ausdrückliche Wartebefehle verlangen, wartet Playwright selbst darauf, dass ein Element im DOM vorhanden, sichtbar und stabil ist. Das macht Skripte zuverlässiger und verringert fehlgeschlagene Tests aufgrund ungünstigen Timings.

Screenshots mit Playwright

Die Methode page.screenshot() bietet genaue Kontrolle über die Ausgabe. Du kannst den sichtbaren Viewport, die gesamte scrollbare Seite oder über einen Locator ein bestimmtes DOM-Element aufnehmen.

Mit der Geräteemulation simulierst du bestimmte Geräte. Viewport-Abmessungen, Skalierungsfaktor und User-Agent werden dabei gemeinsam festgelegt. Playwright enthält ein Geräteverzeichnis mit Vorgaben für verbreitete Smartphones und Tablets. So lässt sich unkompliziert aufnehmen, wie eine Seite auf einem iPhone, Pixel oder iPad aussieht.

Bei Seiten mit Lazy Loading helfen Playwrights automatisches Scrollverhalten und seine Wartebedingungen dabei, Bilder und dynamische Inhalte vor der Aufnahme zu laden. Vor dem Screenshot kannst du CSS einschleusen, um Cookie-Banner oder Chat-Widgets auszublenden oder die Darstellung anzupassen.

Mit WebKit deckt Playwright Rendering-Unterschiede auf, die bei einem reinen Chromium-Lauf verborgen bleiben. Der gepatchte WebKit-Build ist jedoch nicht Safari selbst; auch Betriebssystemdetails wie Medien-Codecs können abweichen. Für den bestmöglichen Safari-Vergleich solltest du WebKit unter macOS ausführen.

In einem an Shotomatic angrenzenden Ablauf lohnt sich Playwright, wenn dieselbe Seite wiederholt in verschiedenen Browsern, Routen oder Anmeldestatus erfasst werden soll. Aus der manuellen Browser-Session wird ein festgelegtes Aufnahmerezept. Deshalb findet sich Playwright häufig in Monitoring- und QA-Pipelines.

Playwright und Puppeteer im Vergleich

Beide Bibliotheken eignen sich für Headless-Browser-Automatisierung, unterscheiden sich aber in Umfang und Ansatz.

Browserabdeckung: Playwright unterstützt Chromium, Firefox und WebKit über eine einheitliche API. Aktuelle Puppeteer-Versionen unterstützen Chrome for Testing und die stabile Firefox-Version, aber kein WebKit. Wenn WebKit Teil des Vergleichs sein muss, passt Playwright besser.

Automatisches Warten: Playwright wartet, bis Elemente für eine Interaktion bereit sind. Puppeteer benötigt mehr ausdrückliche Wartebefehle wie waitForSelector oder waitForNetworkIdle. Das bedeutet mehr Code und mehr mögliche Timing-Probleme.

Browserkontexte: Playwright kann mehrere voneinander getrennte Sessions in einer einzigen Browserinstanz ausführen und spart so Ressourcen. Puppeteer bietet Inkognito-Browserkontexte, die API ist jedoch weniger umfangreich.

Reife der API: Puppeteer gibt es seit 2017 und verfügt über ein größeres Angebot an Community-Ressourcen. Playwright erschien 2020, wächst schnell, wird häufiger veröffentlicht und deckt mehr Funktionen ab.

Bei Screenshot-Abläufen entscheiden meist die Browseranforderungen. Chrome- und Firefox-Aufnahmen sind mit beiden Werkzeugen möglich. Muss der Vergleich auch WebKit umfassen, brauchst du Playwright.

Häufige Fehler

• Browser-Binärdateien nicht installieren: Nach der Installation des Playwright-Pakets musst du den Installationsbefehl ausführen, damit die Browser heruntergeladen werden. Sonst schlägt das Skript mit dem Fehler „browser not found“ fehl.
• Grenzen des automatischen Wartens übersehen: Das automatische Warten verringert zwar Aussetzer, hat aber ein Standard-Zeitlimit. Bei langsamen Seiten kann eine Aktion ablaufen, bevor der Inhalt bereit ist. Passe die Zeitlimits für inhaltsreiche Seiten an.
• Vor dem Laden nachgelagerter Inhalte aufnehmen: Auch mit automatischem Warten scrollt Playwright nicht selbst durch die gesamte Seite. Füge vor einem Ganzseiten-Screenshot einen Scrollschritt hinzu, damit Inhalte mit Lazy Loading geladen werden.
• Den falschen Browser für den Zweck wählen: Alle Aufnahmen mit Chromium zu erstellen ist schneller, übersieht aber Unterschiede in Firefox und WebKit. Nutze browserübergreifende Aufnahmen, wenn die Ausgabe dem entsprechen muss, was Menschen in verschiedenen Browsern sehen.
• Browserkontexte nicht schließen: Offene Kontexte verursachen in lang laufenden Skripten Speicherlecks. Schließe nach der Aufnahme immer die Kontexte und Browserinstanzen.