Puppeteer vs. Playwright 2026: Vergleich

Puppeteer vs. Playwright ist die Wahl, vor der die meisten Node-Entwickler 2026 stehen, wenn sie einen Browser steuern müssen. Puppeteer ist die schlanke, Chrome-only-Bibliothek von Google. Playwright ist das vollständige Cross-Browser-Test-Kit von Microsoft. Beide funktionieren. Sie passen aber nicht für jeden Job gleich gut.

Wenn du nur Chrome für Scraping, PDFs oder schnelle Screenshots steuern willst, ist Puppeteer kleiner, einfacher und schneller zu lernen. Wenn du ein echtes Produkt über Chrome, Firefox und Safari hinweg testen willst — mit Auto-Waits, Retries und Trace-Dateien — gewinnt Playwright vom ersten Tag an.

Dieser Guide stellt beide Bibliotheken in Browser-Support, API-Design, Test-Runner, Geschwindigkeit, Sprach-Reichweite und CI-Kosten gegenüber. Code-Beispiele für dieselben fünf Aufgaben zeigen dir den Unterschied.

TL;DR: Welches solltest du wählen?

Den Tiefgang überspringen? Hier die kurze Antwort.

Wähle Playwright, wenn du End-to-End-Tests schreibst, Safari-Abdeckung brauchst, Code mit Python- oder .NET-Teams teilst oder einen Trace-Viewer für flaky CI-Läufe willst.

Wähle Puppeteer, wenn du Chrome-only-Sites scrapest, PDF- oder Screenshot-Tools baust, ein kleines Node-Binary ausliefern willst oder bereits ein Jest-Setup hast, an dem du nichts ändern willst.

Eine kurze Geschichte beider Bibliotheken

Puppeteer startete 2017. Das Chrome-Team von Google baute es auf dem Chrome DevTools Protocol auf, damit Node-Entwickler einen echten Chrome aus JavaScript steuern können. Drei Jahre lang war es das Mittel der Wahl für Headless-Arbeit. Jeder Screenshot-Service und jedes Scraping-Howto nutzte es.

Playwright startete 2020. Das Team, das Puppeteer gebaut hatte, verließ Google und ging zu Microsoft. Sie schrieben eine neue Bibliothek von Grund auf mit den Lehren der Vergangenheit: Cross-Browser von Tag eins, eine API für Chrome, Firefox und WebKit und ein eingebauter Test-Runner. Die API sieht absichtlich wie Puppeteer aus, was eine Portierung leicht macht.

Heute sind beide gesund. Puppeteer veröffentlicht etwa monatlich und folgt dem Release-Tempo von Chrome. Playwright pusht schneller — etwa alle drei Wochen — und hat Puppeteer bei den wöchentlichen npm-Downloads überholt.

Browser-Support: die größte Lücke

Hier driften die beiden Bibliotheken am stärksten auseinander.

Puppeteer steuert standardmäßig Chrome und Chromium. Firefox-Support existiert, aber die Doku markiert ihn weiterhin als Beta und er kommt als separater Build. Safari ist nicht im Programm.

Playwright steuert Chrome, Firefox und WebKit (Safaris Engine) als First-Class-Ziele. Dieselbe API funktioniert in allen drei. WebKit auf Linux ist ein spezieller Build, den das Playwright-Team aktuell hält, sodass du Safari-ähnliche Tests in einer Linux-CI-Box laufen lassen kannst — etwas, das Safari selbst nicht kann.

Wenn dein Produkt im öffentlichen Web ausgespielt wird, zählt Safari-Abdeckung. Etwa 18 Prozent der Desktop-Nutzer und rund die Hälfte aller mobilen US-Nutzer surfen mit Safari. WebKit handhabt CSS, Schriften und Formularfelder etwas anders als Chrome. Playwrights WebKit erwischt diese Bugs, bevor es Nutzer tun.

Wenn du ein internes Chrome-only-Tool baust, beißt dich diese Lücke nicht.

API-Unterschiede, die in echtem Code auftauchen

Die Puppeteer- und Playwright-APIs sehen auf den ersten Blick ähnlich aus — gleicher browser.newPage(), gleicher page.goto(). Unter der Oberfläche behandeln sie Waits, Selektoren und State sehr unterschiedlich.

Auto-Wait

In Puppeteer wartest du explizit auf Dinge:

// Puppeteer
await page.waitForSelector('#submit');
await page.click('#submit');
await page.waitForNavigation();

In Playwright ist das Warten in jede Aktion eingebaut:

// Playwright
await page.click('#submit'); // auto-waits for visible + enabled
await page.waitForURL('**/dashboard');

Playwrights Aktionen warten, bis das Element vorhanden, sichtbar, stabil und aktiviert ist, bevor sie feuern. Das tötet eine ganze Klasse flaky Tests, bei denen ein Button im DOM ist, aber noch nicht bereit zum Klicken.

Locators vs. Element-Handles

Puppeteer gibt Element-Handles zurück. Sie werden stale, wenn das DOM neu gerendert wird, also musst du erneut abfragen.

// Puppeteer
const btn = await page.$('#submit');
await btn.click(); // can fail after re-render

Playwright führte Locators ein, die lazy sind und bei jeder Aktion neu auflösen.

// Playwright
const btn = page.locator('#submit');
await btn.click(); // resolves at click time, survives re-renders

Für React-, Vue- oder Svelte-Apps, die bei jeder State-Änderung neu rendern, eliminieren Locators eine stetige Quelle von Flakes.

Selektor-Strategien

Puppeteer nimmt CSS und XPath. Playwright fügt Text-, Role- und Test-ID-Locators hinzu, die so funktionieren, wie echte Nutzer UI finden:

// Playwright — find by what users see
await page.getByRole('button', { name: 'Submit' }).click();
await page.getByLabel('Email address').fill('me@example.com');
await page.getByText('Welcome back').waitFor();

Diese Selektoren bleiben gültig, wenn sich Klassennamen bei einem CSS-Refactoring ändern. Sie schubsen dich auch zu besserem Markup — wenn Playwright den Button nicht über die Rolle findet, können Screenreader es auch nicht.

Network Interception

Beide Bibliotheken können Netzwerkaufrufe stubben oder blocken. Die APIs liegen nah beieinander.

// Puppeteer
await page.setRequestInterception(true);
page.on('request', (req) => {
  if (req.resourceType() === 'image') req.abort();
  else req.continue();
});

// Playwright
await page.route('**/*.{png,jpg,jpeg,webp}', (route) => route.abort());

Playwrights page.route() nimmt Glob-Patterns, ein kleiner ergonomischer Vorteil. Beide lassen dich JSON mocken, Offline-Zustand vortäuschen oder Bandbreite drosseln.

Tracing und Debugging

Playwrights Trace-Viewer ist das Feature, in das sich die meisten Entwickler verlieben. Nach einem fehlgeschlagenen Test zeigt der Viewer eine Timeline jeder Aktion, einen DOM-Snapshot bei jedem Schritt, Netzwerkaufrufe, Console-Logs und einen Shot vor und nach jedem Klick. Du kannst einen flaky Test wie ein Video durchscrubben.

// Playwright — record a trace on retry
test.use({ trace: 'on-first-retry' });

Puppeteer hat dafür kein Pendant. Du loggst, du machst Snapshots bei Fehlern, du rätst. Fürs Debugging flaky CI-Läufe ist das in der Praxis eine riesige Lücke.

Code-Beispiele: dieselben fünf Aufgaben in beiden Bibliotheken

Hier sind fünf häufige Jobs Seite an Seite. Die Form des Codes ist nah, weshalb eine Portierung meist einfach gelingt.

1. Einen Ganzseiten-Screenshot machen

// Puppeteer
import puppeteer from 'puppeteer';

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'page.png', fullPage: true });
await browser.close();

// Playwright
import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'page.png', fullPage: true });
await browser.close();

Wenn dein Ziel ist, UI-Aufnahmen über Builds hinweg in CI zu vergleichen, führt unser Visual-Regression-Testing-Guide durch Tools, die auf beiden Bibliotheken aufsetzen.

2. Ein Login-Formular ausfüllen

// Puppeteer
await page.type('#email', 'user@example.com');
await page.type('#password', 'secret');
await page.click('#login');
await page.waitForNavigation();

// Playwright
await page.getByLabel('Email').fill('user@example.com');
await page.getByLabel('Password').fill('secret');
await page.getByRole('button', { name: 'Log in' }).click();
await page.waitForURL('**/dashboard');

3. Auf einen Button klicken und auf Inhalt warten

// Puppeteer
await page.click('#load-more');
await page.waitForSelector('.item:nth-child(20)');

// Playwright
await page.getByRole('button', { name: 'Load more' }).click();
await expect(page.locator('.item')).toHaveCount(20);

4. Auf einen Selektor warten

// Puppeteer
await page.waitForSelector('.toast-success', { timeout: 5000 });

// Playwright
await expect(page.locator('.toast-success')).toBeVisible({ timeout: 5000 });

5. Einen Netzwerkaufruf abfangen und mocken

// Puppeteer
await page.setRequestInterception(true);
page.on('request', (req) => {
  if (req.url().includes('/api/users')) {
    req.respond({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify([{ id: 1, name: 'Test' }]),
    });
  } else {
    req.continue();
  }
});

// Playwright
await page.route('**/api/users', (route) =>
  route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify([{ id: 1, name: 'Test' }]),
  })
);

Test-Framework-Integration

Das ist der stille Entscheidungstreiber für die meisten Teams.

Puppeteer liefert keinen Test-Runner mit. Du bringst Jest, Mocha oder Vitest mit. Du schreibst deine eigenen Helfer für Fixtures, Retries, Parallelläufe und HTML-Reports. Die Community liefert jest-puppeteer und puppeteer-cluster, aber sie sind Drittpartei und lückenhaft.

Playwright liefert @playwright/test in derselben Installation. Du bekommst:

• Einen Test-Runner mit gesharded parallelen Läufen
• Fixtures für gemeinsamen State (Browser, Page, Auth)
• Auto-Retry bei Fehlschlag
• HTML-Report mit Aufnahmen, Videos und Traces
• Eingebautes expect() mit web-bewussten Checks (toBeVisible, toHaveURL, toContainText)
• Codegen — nimm einen Test auf, indem du dich durch deine App klickst

Wenn End-to-End-Testing das Ziel ist, reicht allein die Runner-Lücke, um Playwright zu wählen. Du sparst eine Woche Setup-Arbeit.

Wenn dein Ziel Scraping oder PDF-Jobs sind, brauchst du keinen Runner. Puppeteer ist der sauberere Fit.

Performance-Benchmarks

Beide Bibliotheken sind schnell. Sie liegen auch grob gleichauf — wenn du Vergleichbares stapelst, ist die Lücke klein.

Öffentliche Benchmarks (Skyvern 2025, Indie-Dev-Blogs) zeigen:

• Cold Start: Puppeteer startet Chrome auf einer sauberen Maschine etwa 5–10 Prozent schneller. Playwright cached seine Browser in einem eigenen Ordner und lädt etwas mehr Setup-Code.
• Single Page Load: Grob gleichauf. Der langsame Teil ist das Netzwerk und die Seite selbst, nicht die Bibliothek.
• Parallelläufe: Playwrights eingebauter Runner shardet sauber über Worker. Puppeteer braucht puppeteer-cluster oder deinen eigenen Pool, und die Ergebnisse hängen davon ab, wie gut du ihn geschrieben hast.
• Speicher pro Browser-Kontext: Grob gleichauf. Beide nutzen Kontexte gut wieder, wenn du es tust.

Reale Lücken kommen aus deinem Code, nicht aus der Bibliothek. Ein Pool aus 50 wiederverwendeten Puppeteer-Kontexten schlägt 50 frische Playwright-Starts. Die Kehrseite: Playwrights browserContext-Wände sind eingebaut, während Puppeteer dich bittet, sie selbst zu verwalten.

Für ein Side-by-Side bei Downloads und Stars aktualisiert sich die npm-Trends-Seite wöchentlich. Playwright überholte Puppeteer bei den wöchentlichen Downloads 2023 und der Abstand wächst weiter.

Gesponsert von den Machern

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Wunderschöne Hintergründe, professionelle Annotationen, GIF-Aufnahme und sofortiges Cloud-Sharing — alles in einer App. Einmalig 29 $, für immer deins.

Sieh, was es kann

CI/CD-Überlegungen

Beide Bibliotheken liefern Docker-Images. Beide unterstützen Headless-Modus. Es gibt echte Lücken im Alltag.

Docker-Images:

• Puppeteer: ghcr.io/puppeteer/puppeteer liefert Chrome und einen node-User.
• Playwright: mcr.microsoft.com/playwright liefert alle drei Browser plus System-Deps — etwa 1,5 GB. Es gibt auch einen Slim-Build.

Sharding und Parallelläufe: Playwrights Runner shardet Tests mit einem Flag über Worker. Puppeteer überlässt es dir.

Retries bei Flake: In Playwright eingebaut. DIY in Puppeteer.

Artefakte: Playwright speichert Traces, Videos und Aufnahmen bei Fehlern automatisch. Puppeteer speichert standardmäßig nichts.

Kosten: Playwrights größeres Image bedeutet langsamere Pulls, aber das parallele Sharding holt die Zeit meist wieder rein.

Wenn du einen Screenshot-Service betreibst, ist Puppeteer in einem schlanken Alpine-Image schwer zu schlagen, was die Kosten angeht. Wenn du eine E2E-Suite mit Hunderten Tests hast, spart Playwrights Runner jede Woche echte Stunden. Für Mac-Entwickler, die beim Debuggen von CI auch lokale Schnellaufnahmen brauchen, deckt unser Beitrag zum Automatisieren von Screenshots auf dem Mac die Desktop-Seite ab.

Sprach-Support

Puppeteer ist nur JavaScript und TypeScript. Es gibt einen Community-Python-Port (pyppeteer), der aber nicht mehr gepflegt wird und Chrome um ein Jahr oder mehr hinterherhinkt.

Playwright liefert First-Party-Clients für:

• JavaScript / TypeScript
• Python
• Java
• .NET (C#)

Die API ist über alle vier hinweg fast gleich. Ein Python-QA-Team und ein Node-Frontend-Team können Test-Patterns, Aufnahmen und sogar Fixtures mit dünnen Wrappern teilen.

Für mehrsprachige Shops entscheidet diese eine Tatsache oft die Debatte.

Entscheidungs-Framework: wann welche Bibliothek gewinnt

Nutze diese Kurzliste, um schnell zu entscheiden.

Wähle Puppeteer, wenn:

• Du nur Chrome ansprichst
• Du einen kleinen Scraping-, Screenshot- oder PDF-Service baust
• Du bereits Jest oder Mocha nutzt und keinen zweiten Runner willst
• Dir kleines Bundle und schneller Cold Start wichtig sind
• Das Team ausschließlich JavaScript spricht

Wähle Playwright, wenn:

• Du End-to-End-Tests gegen echte Nutzer-Browser schreibst
• Du Safari-/WebKit-Abdeckung brauchst
• Du einen Trace-Viewer für flaky CI-Läufe willst
• Du Code über Python-, Java- oder .NET-Teams hinweg teilst
• Du Auto-Wait, Locators und Codegen out of the box willst
• Deine App viel re-rendert (React, Vue, Svelte)

Nutze beides, wenn:

• Live-Scraping Puppeteer wegen Tempo und kleiner Deps nutzt
• Die QA-Suite Playwright fürs Cross-Browser-Vertrauen nutzt
• Sie in unterschiedlichen Services oder Repos leben und sich nie mischen

Das ist häufiger, als die Leute zugeben. Die beiden Bibliotheken lösen nahe, aber nicht gleiche Probleme.

Migration von Puppeteer zu Playwright

Die gute Nachricht: Die API-Überlappung macht den Port weniger schmerzhaft als die meisten. Die meisten Teams berichten von ein paar Tagen Arbeit für eine mittelgroße Codebase, nicht Wochen.

Schritte:

1. Installiere playwright und @playwright/test neben Puppeteer.
2. Tausche puppeteer.launch() gegen chromium.launch(). Die meisten Aufrufe funktionieren wie sie sind.
3. Tausche Element-Handles gegen Locators (page.$('#x') → page.locator('#x')).
4. Lass die waitForSelector-Aufrufe vor click weg — Auto-Wait erledigt das.
5. Tausche setRequestInterception gegen page.route().
6. Wenn du Jest genutzt hast, portiere Tests zu @playwright/test, um Fixtures und Traces freizuschalten (optional, aber eine gute Idee).

Microsoft pflegt einen Migrations-Guide mit einer kompletten Karte. Es gibt auch einen Community-Shim playwright-puppeteer, der alten Code mit leichten Anpassungen auf Playwright laufen lässt — praktisch für eine schrittweise Portierung.

Wenn du 2026 ein nagelneues Projekt startest und unsicher bist, nimm Playwright. Die Kosten eines späteren Wechsels sind real.

Wo ScreenSnap Pro hineinpasst (und wo nicht)

Wenn du hier aus Versehen gelandet bist — auf der Suche nach einem Desktop-Screenshot-Tool, nicht einer Code-Bibliothek — ist weder Puppeteer noch Playwright das, was du willst. Sie sind Tools, die du aus Node aufrufst, keine Apps zum Anklicken. Für lokale Bildschirmaufnahme, GIF-Aufnahme und schnelles Markup auf Mac oder Windows ist ScreenSnap Pro für 29 $ einmalig der nähere Fit. Für serverseitige Webseiten-Aufnahme bleib bei diesem Guide.

Für einen breiteren Blick auf SaaS- und selbstgehostete Screenshot-Optionen im großen Stil siehe unsere Übersicht der besten Screenshot-APIs 2026, die ScreenshotOne, Urlbox und selbstgehostetes Puppeteer oder Playwright nach Kosten und Tempo gegenüberstellt.

Detaillierte Feature-Matrix

Ein zweiter Durchgang mit mehr Zeilen für Käufer, die die volle Sicht wollen.

Häufig gestellte Fragen

Was ist schneller, Puppeteer oder Playwright?

Für eine einzelne Chrome-Aufgabe sind beide etwa gleich. Puppeteer startet den Browser etwas schneller (rund 5–10 Prozent beim Cold Start). Für parallele Test-Suites gewinnt Playwrights eingebauter geshardeter Runner oft, weil er die Parallelarbeit für dich erledigt — und die meisten handgestrickten Puppeteer-Pools sind weniger getrimmt.

Kann ich von Puppeteer zu Playwright migrieren?

Ja, und es ist einfacher als die meisten Library-Wechsel. Die APIs teilen Wurzeln (gleiche Autoren), sodass der meiste Code eins zu eins übersetzt werden kann. Plane ein paar Tage für eine mittelgroße Codebase. Tausche puppeteer.launch() gegen chromium.launch(), Element-Handles gegen Locators und lass die waitForSelector-Aufrufe vor Klicks weg. Microsoft hat einen offiziellen Migrations-Guide.

Funktioniert Playwright mit Safari?

Playwright steuert WebKit, die Open-Source-Engine hinter Safari. Es ist nicht Safari selbst, aber es teilt die Render-Schicht, sodass Layout-, CSS- und JS-Bugs, die Safari-Nutzer treffen, fast immer auch in WebKit auftauchen. WebKit läuft auch auf Linux-CI, was Safari nicht kann. Für die meisten Teams ist Playwrights WebKit das Nächste an automatisiertem Safari-Testen.

Was ist der Unterschied zwischen Puppeteer und Playwright?

Puppeteer (Google, 2017) ist eine fokussierte Chrome-Automatisierungs-Bibliothek. Playwright (Microsoft, 2020) ist ein Cross-Browser-Test-Kit. Playwright deckt Chrome, Firefox und WebKit mit einer API ab, liefert einen eingebauten Test-Runner, unterstützt vier Sprachen und ergänzt einen Trace-Viewer. Puppeteer ist kleiner und schneller zu lernen, aber Chrome-only.

Welches hat den besseren Community-Support?

Beide sind gesund. Puppeteer hat die längere Historie und mehr StackOverflow-Antworten, vor allem fürs Scraping. Playwright hat mehr aktuelle Aktivität, schnellere Releases und einen größeren Discord. Bei den wöchentlichen npm-Downloads überholte Playwright Puppeteer 2023 und liegt jetzt 3- bis 4-mal vorn.

Wird Playwright Puppeteer endgültig ablösen?

Wahrscheinlich nicht. Puppeteer hat eine Nische, in der es einfach besser ist: kleine Chrome-only-Services, in denen du eine winzige Installation, keine Meinung zu Test-Runnern und den schnellsten Cold Start willst. Fürs End-to-End-Testen ist Playwright 2026 die Top-Wahl. Beide werden weiter koexistieren, wie Express und Fastify es tun — nah, aber jeder am besten in unterschiedlichen Jobs.

Kann ich Puppeteer oder Playwright fürs Web-Scraping nutzen?

Ja. Beide funktionieren. Puppeteer ist in Scraping-Howtos verbreiteter und hat einen kleineren Footprint, also ist es der schlanke Default für einen Scraper. Playwright funktioniert genauso gut und gibt dir Firefox- oder WebKit-Fingerprints, was helfen kann, wenn Sites Chrome-only-Traffic blocken. Prüfe immer die Nutzungsbedingungen der Zielseite und die robots.txt, bevor du scrapest.

Endgültiges Urteil

Fürs End-to-End-Testen 2026 ist Playwright der Default. Der Runner, die Locators, der Trace-Viewer und die Cross-Browser-Abdeckung summieren sich zu jeder Woche eingesparten Stunden.

Für Chrome-only-Scraping, Screenshots oder PDF-Jobs verdient Puppeteer weiterhin seinen Platz. Kleinere Installation, einfacheres Modell, weniger zu lernen.

Wenn du beides baust — eine öffentliche App, die du testest, plus eine Scraping-Pipeline — ist es in Ordnung, das richtige Tool für jeden Job zu nutzen. Code-Sharing zählt weniger als das Tool zu wählen, das zur Last passt.

Was auch immer du ausspielst — lehn dich an den Trace-Viewer (Playwright) oder solide Logs plus Failure-Aufnahmen (Puppeteer). Browser-Automatisierung ist von Natur aus flaky. Gutes Debugging ist die Lücke zwischen einer ruhigen CI und einem Slack-Feed roter Alarme. Und wenn ein echter Bug durchrutscht, hilft eine saubere Bug-Report-Vorlage deinem Team, schneller zu triagieren.