Website-Screenshots mit Playwright automatisieren

Playwright ist eine Bibliothek zur Browser-Automatisierung von Microsoft. Sie steuert Chromium, Firefox und WebKit aus Node.js, Python, Java oder .NET. Dieser Beitrag verwendet das Node.js-Paket, um ein Screenshot-Skript zu erstellen. Er beginnt mit einer einzelnen Seite und endet mit einem URL-Batch, der fehlgeschlagene Aufnahmen wiederholt.

Wann Playwright das richtige Werkzeug ist

Ein Skript lohnt den Einrichtungsaufwand, wenn Screenshots Teil eines größeren technischen Prozesses sind:

• Aufnahmen laufen in der CI nach jedem Deployment
• Die URL-Liste stammt aus einer Sitemap, einer Datenbank oder einer API
• Die Dateien müssen in einer festen Ordnerstruktur oder einem Storage-Bucket landen
• Der Screenshot-Schritt steht neben Tests, Scraping oder PDF-Erstellung

Wenn die Person, die die Bilder braucht, keinen Code schreibt oder sich die Liste jede Woche ändert, ist ein No-Code-Werkzeug meist schneller. Dieser Abwägung widmet sich der letzte Abschnitt.

Das Beispiel in diesem Beitrag

Die Beispiele führen auf ein Ziel hin: Nach jedem Deployment werden die 200 Seiten erfasst, die in der Sitemap einer Website aufgelistet sind, jeweils in Desktop- und Telefongröße. Fehlgeschlagene Seiten meldet das Skript. Diese Aufgabe hat alle Merkmale, die Screenshot-Skripte schwierig machen: eine lange Liste, langsame Seiten, verzögert geladene Bilder, Cookie-Banner und gelegentliche Timeouts.

Die Zahlen für diese Aufgabe sind Schätzwerte. Die tatsächlichen Laufzeiten hängen von der Website, dem Netzwerk und dem Rechner ab.

Was der Betrieb des Skripts kostet

Das Skript ist kostenlos, aber nicht wartungsfrei. Ein Website-Redesign kann das Cookie-Banner, das Element als Bereitschaftssignal oder den Scroll-Container verändern. Jede dieser Änderungen unterbricht einen Teil des Batches.

Node.js oder eine andere Sprache

Die Screenshot-API ist in den vier Sprachbindungen nahezu identisch. page.screenshot(path=..., full_page=True) in Python bewirkt dasselbe wie fullPage: true in Node.js. Wählen Sie die Sprache, die die restliche Pipeline bereits verwendet. So liegt der Screenshot-Schritt im selben Repository und CI-Job wie der umgebende Code.

Planen Sie dafür Zeit ein. Ein Batch, der nach jedem Deployment läuft, rechtfertigt den Wartungsaufwand schnell. Ein Batch, der zweimal im Jahr läuft, schlägt beim ersten Versuch oft fehl, weil sich in der Zwischenzeit etwas geändert hat.

Playwright für ein Screenshot-Skript installieren

mkdir site-shots && cd site-shots
npm init -y
npm install -D playwright
npx playwright install chromium

Der letzte Befehl lädt einen Chromium-Build herunter, der zur installierten Playwright-Version passt. Die folgenden Skripte verwenden die Dateiendung .mjs, damit await auf oberster Ebene ohne Bundler oder zusätzliche Konfiguration funktioniert.

Version und Browser gemeinsam festlegen

Jede Playwright-Version erwartet bestimmte Browser-Builds. Führen Sie nach einem Upgrade des Pakets playwright den Befehl npx playwright install chromium erneut aus. Andernfalls bricht das Skript mit der Meldung ab, dass die ausführbare Datei nicht existiert.

Committen Sie package-lock.json, damit jeder Rechner dieselbe Version installiert. Auf einem Linux-CI-Runner installiert npx playwright install --with-deps chromium außerdem die Systembibliotheken, die der Browser benötigt.

Der Befehl screenshot eignet sich, um eine einzelne URL vor dem Aufnehmen in den Batch zu prüfen. Er akzeptiert auch --device und --wait-for-selector, sodass sich eine langsame Seite im Terminal testen lässt.

Einen Website-Screenshot aufnehmen

// one.mjs
import { chromium } from 'playwright';

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1920, height: 1080 } });

await page.goto('https://example.com');
await page.screenshot({ path: 'example.png' });

await browser.close();

Führen Sie das Skript mit node one.mjs aus. Der Browser startet im Headless-Modus, das heißt, er rendert die Seite, ohne ein Fenster zu öffnen. Der Eintrag zum Headless-Browser beschreibt dieses Modell.

Ohne weitere Optionen ist die Datei ein Viewport-Screenshot mit genau 1920×1080 Pixeln.

Optionen für wiederholbare Aufnahmen

Zwei Läufe derselben Seite sollten dasselbe Bild erzeugen, solange sich nichts geändert hat. Einige Screenshot-Optionen beseitigen die üblichen Störquellen: Animationen, die mitten im Ablauf erfasst werden, einen blinkenden Textcursor und eine Pixeldichte, die zwischen Rechnern abweicht.

await page.screenshot({
  path: 'example.jpg',
  type: 'jpeg',
  quality: 80,
  animations: 'disabled',
  caret: 'hide',
  scale: 'css',
  mask: [page.locator('.ad-slot'), page.locator('.live-chat')],
});

mask legt ein deckendes Feld über jedes passende Element. Das ist der einfachste Weg, damit rotierende Werbung, Live-Zeitstempel und Chat-Widgets nicht bei jedem Lauf ein anderes Bild erzeugen.

Eine leere oder falsche Aufnahme untersuchen

Wenn ein Screenshot leer ist, eine Fehlerseite zeigt oder eine Bot-Prüfung anzeigt, müssen Sie prüfen, was der Browser gesehen hat. Starten Sie mit headless: false und der Option slowMo, um jeden Schritt zu beobachten. Alternativ zeichnen Sie einen Trace auf und öffnen ihn im Trace Viewer.

Der Trace zeigt einen Filmstreifen der Seite und die Netzwerkanfragen für jede Aktion. Eine Seite, die im Filmstreifen vollständig gerendert war, aber leer aufgenommen wurde, deutet meist darauf hin, dass der Screenshot vor dem Ende einer Einblendung lief. animations: 'disabled' behebt dieses Problem.

Eine vollständige Seite aufnehmen

Fügen Sie fullPage: true hinzu, um das gesamte scrollbare Dokument zu erfassen.

await page.screenshot({ path: 'example-full.png', fullPage: true });

Die Breite bleibt auf der Viewport-Breite, die Höhe wächst, bis die Seite hineinpasst. Sehr lange Seiten ergeben sehr hohe Bilder, die manche Bildbetrachter stark verkleinern. Bei Seiten mit fixierten Kopfzeilen erscheint die Kopfzeile nur einmal oben, weil Playwright das Dokument in einem Durchgang erfasst und nicht gescrollte Ansichten zusammensetzt.

Um stattdessen ein einzelnes Element zu erfassen, rufen Sie screenshot auf einem Locator auf: page.locator('main').screenshot({ path: 'main.png' }).

Einen festen Bereich aufnehmen

clip speichert ein Rechteck der Seite in CSS-Pixeln, angegeben als x, y, width und height. Das eignet sich für Seiten, bei denen nur die ersten 1.200 Pixel wichtig sind, etwa eine Landingpage mit dem sichtbaren Bereich und dem ersten Abschnitt.

await page.screenshot({ path: 'hero.png', clip: { x: 0, y: 0, width: 1920, height: 1200 } });

Ein Clip, der unter den unteren Rand einer kurzen Seite reicht, wird am Seitenrand abgeschnitten. Prüfen Sie die Bildhöhe, wenn der Clip auf allen Seiten identisch sein soll.

Die Ziel-URLs in einem Batch-Skript verwenden

Speichern Sie die URLs in einer Textdatei, damit niemand Code ändern muss, um die Liste anzupassen.

// batch.mjs
import { readFile, mkdir } from 'node:fs/promises';
import { chromium } from 'playwright';

const urls = (await readFile('urls.txt', 'utf8'))
  .split('\n').map((l) => l.trim()).filter(Boolean);

await mkdir('shots', { recursive: true });
const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1920, height: 1080 } });

for (const [i, url] of urls.entries()) {
  const name = `shots/${String(i + 1).padStart(3, '0')}.png`;
  await page.goto(url, { waitUntil: 'load', timeout: 30000 });
  await page.screenshot({ path: name, fullPage: true });
  console.log('saved', url, name);
}

await browser.close();

Null-aufgefüllte Namen wie 001.png halten die Dateien im Finder in der Reihenfolge der Liste.

Die Liste aus einer Sitemap erstellen

Bei der Beispielaufgabe stammt die Liste aus sitemap.xml. Laden Sie die Datei einmal zu Beginn des Laufs und extrahieren Sie jeden loc-Eintrag. So werden neue Seiten erfasst, ohne urls.txt zu bearbeiten.

const xml = await (await fetch('https://example.com/sitemap.xml')).text();
const urls = [...xml.matchAll(/<loc>(.*?)<\/loc>/g)].map((m) => m[1].trim());

Dateien nach Seite benennen, nicht nur nach Position

Indexnamen wie 001.png brechen, sobald die Sitemap eine Seite hinzugewinnt, weil sich jede folgende Datei um eine Stelle verschiebt. Namen aus dem URL-Pfad bleiben über mehrere Läufe stabil: Aus /pricing/teams wird pricing-teams.png. Verwenden Sie den Index nur dann als Präfix, wenn die Reihenfolge der Liste für die Prüfung wichtig ist.

Zwei URLs können auf denselben Namen abbilden, zum Beispiel ein Pfad mit und ohne abschließenden Schrägstrich. Prüfen Sie vor dem Lauf auf doppelte Namen und ergänzen Sie den Index, um sie aufzulösen.

Große Websites teilen ihre Sitemap in einen Index auf, der auf weitere Sitemaps verweist. Folgen Sie diesen Links eine Ebene tiefer und filtern Sie Datei-URLs wie PDFs aus, da sie nicht als Seiten gerendert werden.

Parallelität für größere Batches

Eine Seite nach der anderen ist bei Hunderten URLs langsam. Führen Sie einige Seiten parallel aus, jede in einem eigenen Page-Objekt, und begrenzen Sie die Anzahl, damit der Speicherverbrauch kontrollierbar bleibt.

const LIMIT = 4;
const queue = [...urls.entries()];

async function worker() {
  const page = await browser.newPage({ viewport: { width: 1920, height: 1080 } });
  while (queue.length) {
    const [i, url] = queue.shift();
    await page.goto(url);
    await page.screenshot({ path: `shots/${i + 1}.png`, fullPage: true });
  }
  await page.close();
}

await Promise.all(Array.from({ length: LIMIT }, worker));

Vier Worker sind ein sinnvoller Start auf einem Laptop. Erhöhen Sie das Limit erst, nachdem Sie den Speicherverbrauch geprüft haben. Bei Websites, die Ihnen nicht gehören, halten Sie es niedrig, damit die Anfragerate moderat bleibt.

Wie die Anzahl der Worker die Laufzeit verändert

Die Laufzeit sinkt fast proportional zur Anzahl der Worker, bis der Rechner oder die Website zum Engpass wird. Bei geschätzten 4 Sekunden pro Seite benötigen 200 Seiten mit 1 Worker etwa 13 Minuten, mit 4 Workern etwa 3,5 Minuten und mit 8 Workern etwas weniger.

Darüber hinaus erhöhen zusätzliche Worker vor allem den Speicherdruck und die Serverlast. Wenn Screenshots bei steigender Anzahl in Timeouts laufen, ist die Website oder der Rechner ausgelastet. Die Anzahl sollte dann wieder sinken.

Die Anfragerate moderat halten

Jeder Seitenaufruf lädt außerdem Skripte, Bilder und Schriften. Vier Worker können daher zu Dutzenden Anfragen pro Sekunde an einen Server führen. Bei fremden Websites belassen Sie die Anzahl der Worker bei 1 oder 2 und fügen eine Pause von 1 bis 2 Sekunden zwischen den Seiten ein. Führen Sie große Batches außerhalb der Stoßzeiten der Website aus und brechen Sie ab, sobald die Antworten mit 429 Too Many Requests beginnen.

Seiten oder Kontexte

Der oben gezeigte Worker teilt sich einen Browser-Kontext, daher teilen sich alle Seiten die Cookies. Setzt eine Seite ein Einwilligungs-Cookie, überspringen spätere Seiten das Banner, und die Aufnahmen unterscheiden sich je nach Reihenfolge der Worker. Geben Sie jedem Worker mit browser.newContext() einen eigenen Kontext, wenn jede Aufnahme von einem sauberen Zustand ausgehen muss.

Mobile oder Tablet-Screenshots aufnehmen

Playwright liefert Geräte-Deskriptoren mit, die Viewport, User-Agent, Touch-Unterstützung und Pixel-Verhältnis gemeinsam setzen.

import { chromium, devices } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext({ ...devices['iPhone 13'] });
const page = await context.newPage();

Verwenden Sie pro Gerät einen eigenen Kontext, damit Cookies und Speicher getrennt bleiben. Für ein Tablet wählen Sie einen iPad-Eintrag aus derselben devices-Liste oder setzen einen einfachen Viewport wie 768×1024.

Pixeldichte und Dateigröße

Telefon-Deskriptoren setzen deviceScaleFactor auf 2 oder 3. Ein 390 Pixel breiter Telefon-Viewport mit Faktor 3 speichert ein Bild mit 1.170 Pixeln Breite, und eine lange Seite kann Zehntausende Pixel in der Höhe erreichen. Das entspricht dem Neunfachen der Pixel derselben Seite mit Faktor 1.

Für die Prüfung des Layouts behält scale: 'css' in den Screenshot-Optionen ein Bildpixel pro CSS-Pixel bei. Behalten Sie den Geräte-Skalierungsfaktor nur dann bei, wenn die Bilder auf einem Telefondisplay scharf wirken müssen.

Prüfen, ob das mobile Layout geladen wurde

Manche Websites wählen das Layout serverseitig anhand des User-Agents, andere anhand der Viewport-Breite in CSS. Ein Deskriptor setzt beides, eine einfache Änderung von viewport setzt nur die Breite. Wenn Telefon-Aufnahmen ein gequetschtes Desktop-Layout zeigen, wechseln Sie von einem reinen Viewport zu einem vollständigen Geräte-Deskriptor.

WebKit für Safari-ähnliches Rendering

Chromium ist in den meisten Skripten der Standard, doch iPhone-Layouts werden auf echten Geräten von WebKit gerendert. Installieren Sie WebKit mit npx playwright install webkit und starten Sie es mit webkit.launch(), wenn Safari-spezifisches Rendering relevant ist.

Verzögert geladene Inhalte behandeln

Viele Seiten laden Bilder erst, wenn sie in den sichtbaren Bereich scrollen. Eine vollständige Aufnahme direkt nach dem Laden kann weiter unten leere Felder zeigen. Scrollen Sie deshalb einmal durch die Seite, bevor Sie den Screenshot aufnehmen.

await page.evaluate(async () => {
  for (let y = 0; y < document.body.scrollHeight; y += window.innerHeight) {
    window.scrollTo(0, y);
    await new Promise((r) => setTimeout(r, 200));
  }
  window.scrollTo(0, 0);
});

Der Eintrag zu Lazy Loading erklärt, warum das geschieht.

Warten, bis Bilder dekodiert sind

Das Scrollen startet die Bildanfragen, doch der Screenshot kann trotzdem vor dem Eintreffen der Bilder laufen. Warten Sie nach dem Scrollen, bis jedes Bild auf der Seite meldet, dass es vollständig geladen ist.

await page.waitForFunction(() =>
  [...document.images].every((img) => img.complete && img.naturalWidth > 0)
);

Defekte Bild-URLs werden nie vollständig. Diese Wartebedingung kann daher bei einer fehlenden Datei in ein Timeout laufen. Fangen Sie das Timeout ab, nehmen Sie die Seite trotzdem auf und markieren Sie sie im Bericht.

Die richtige Wartestrategie wählen

Die Option waitUntil bestimmt, wann goto zurückkehrt.

Wert	Kehrt zurück, wenn
load	Das load-Ereignis wird ausgelöst. Dies ist der Standard.
domcontentloaded	Das HTML ist geparst, bevor Bilder fertig geladen sind.
networkidle	Mindestens 500 ms lang keine Netzwerkanfragen.

Die Playwright-Dokumentation rät bei Tests von networkidle ab, weil Seiten mit Polling oder Analytics womöglich nie zur Ruhe kommen. Zuverlässiger ist es, auf ein Element zu warten, das die Seite als bereit markiert, zum Beispiel await page.locator('main img').first().waitFor().

Eine feste Wartezeit von 5 Sekunden bei 200 Seiten addiert bei einem Worker etwa 17 Minuten Leerlauf und scheitert trotzdem an der einen Seite, die 6 Sekunden braucht. Eine Locator-Wartebedingung kehrt dagegen zurück, sobald die Seite bereit ist. await page.evaluate(() => document.fonts.ready) deckt den Fall der Schriften ab.

Wiederholungsversuche hinzufügen

Netzwerke fallen aus, und manche Seiten laufen einmal in ein Timeout und laden danach problemlos. Umschließen Sie die Aufnahme deshalb mit einer kleinen Hilfsfunktion für Wiederholungsversuche.

async function capture(page, url, path, tries = 3) {
  for (let attempt = 1; attempt <= tries; attempt++) {
    try {
      await page.goto(url, { timeout: 30000 });
      await page.screenshot({ path, fullPage: true });
      return true;
    } catch (error) {
      console.warn(`attempt ${attempt} failed for ${url}: ${error.message}`);
    }
  }
  return false;
}

Sammeln Sie die URLs, für die false zurückgegeben wird, und schreiben Sie sie in failed.txt, damit sie separat erneut ausgeführt werden können.

Nicht wiederholen, was sich nicht ändert

Wiederholungen helfen bei Timeouts und abgebrochenen Verbindungen. Bei einer Seite, die 404 oder 500 zurückgibt, helfen sie nicht, und drei Versuche bei 20 fehlenden Seiten kosten unnötig Minuten. page.goto liefert ein Response-Objekt zurück. Prüfen Sie daher response.status() und verzichten Sie auf den Wiederholungsversuch, wenn der Status 400 oder höher ist.

Tragen Sie den Status im Bericht neben der URL ein. Eine Liste der 404-Fehler aus einer Sitemap ist für sich genommen nützlich, weil sie auf veraltete Sitemap-Einträge hinweist.

Nach einem Absturz der Seite wiederherstellen

Eine Seite kann bei einer schweren Website abstürzen. Danach wirft jedes weitere goto auf diesem Page-Objekt einen Fehler. Schließen Sie innerhalb der Hilfsfunktion die Seite nach einem Fehler und öffnen Sie für den nächsten Versuch eine neue. Der Worker läuft weiter, und eine fehlerhafte URL bringt nicht mehr die restliche Warteschlange des Workers zum Scheitern.

Eine praktische Ordnerstruktur

site-shots/
  urls.txt
  batch.mjs
  shots/
    2026-03-24/
      desktop/001.png
      mobile/001.png
  failed.txt

Ein datierter Ordner pro Lauf hält ältere Aufnahmen intakt. Ein Unterordner pro Gerät vereinfacht den direkten Vergleich.

Was ein CI-Lauf hochladen sollte

In der CI wird der Runner nach dem Job gelöscht. Die Screenshots müssen daher als Build-Artefakte hochgeladen werden. Laden Sie den datierten Ordner, die Liste der Fehlschläge und einen kleinen JSON-Bericht hoch. Der Bericht enthält für jede Seite die URL, den Status, den Dateinamen und die Dauer.

Einen Lauf mit dem vorherigen vergleichen

Zwei datierte Ordner sind nur nützlich, wenn jemand die Unterschiede prüft. Bei wenigen Seiten öffnen Sie die passenden Dateien in Compare Images, das einen Schieberegler und eine Ansicht der Pixel-Differenz bietet. Bei Hunderten Seiten vergleicht die Assertion toHaveScreenshot aus Playwright Test jede Aufnahme mit einer gespeicherten Baseline und schlägt bei Abweichungen oberhalb eines Schwellenwerts fehl.

Schriften sind der häufigste Unterschied zwischen einem Lauf auf dem Laptop und einem CI-Lauf. Ein Linux-Runner ohne die Ersatzschriften der Website rendert Text mit anderen Breiten, sodass sich Zeilenumbrüche und Seitenhöhen ändern.

Häufige Fehler

1. await vergessen. Das Skript endet, bevor die Datei geschrieben ist.
2. Eine Seite nach einem Absturz weiterverwenden. Öffnen Sie eine neue Seite, wenn goto einen Fehler vom Typ target closed auslöst.
3. Überall auf networkidle vertrauen. Manche Seiten erreichen diesen Zustand nie, und jede betroffene Zeile läuft in ein Timeout.
4. Cookie-Banner in der Aufnahme belassen. Klicken Sie den Zustimmungs-Button über einen Locator oder blenden Sie das Banner mit page.addStyleTag aus.
5. Nutzungsbedingungen von Websites ignorieren. Prüfen Sie bei fremden Websites die Nutzungsbedingungen und die robots-Regeln und halten Sie die Anfragerate niedrig.

Cookie-Banner zuverlässig schließen

Banner unterscheiden sich von Website zu Website. Ein einzelner Selektor funktioniert daher selten für eine ganze Liste. Probieren Sie eine kurze Liste bekannter Zustimmungs-Buttons mit je 2 Sekunden Timeout aus und greifen Sie als Rückfall auf das Ausblenden des Banner-Containers per CSS zurück.

const consent = page.getByRole('button', { name: /accept|agree|reject all/i });
if (await consent.first().isVisible({ timeout: 2000 }).catch(() => false)) {
  await consent.first().click();
}

Ein Klick auf einen Zustimmungs-Button ändert die Cookies für den restlichen Kontext. Bei einem Kontext pro Worker ist das unproblematisch. Bei einem gemeinsamen Kontext ist es ein weiterer Grund, warum die Aufnahmen je nach Reihenfolge abweichen.

Alternativen zu einem Playwright-Screenshot-Skript

• Puppeteer bietet eine ähnliche API für Chrome und Firefox. Siehe Website-Screenshots mit Puppeteer automatisieren.
• Playwright Test vergleicht Screenshots mit Baselines. Siehe den Playwright-Leitfaden zum Screenshot-Testing.
• Gehostete Screenshot-APIs betreiben den Browser für Sie und liefern Bilder über HTTP zurück.
• Temposhot Website Capture führt eine URL-Liste lokal auf einem Mac ohne Code aus: Desktop 1920×1080, Tablet 768×1024 oder Mobile 390×844, Viewport oder Full page, bis zu 10 Browser gleichzeitig und pro Zeile Retry.

Skriptoptionen und ihre No-Code-Entsprechungen

Für die meisten Entscheidungen in diesem Beitrag gibt es in Website Capture eine direkte Einstellung. Der Unterschied liegt darin, wer die Entscheidung trifft: ein Entwickler im Code oder jede Person, die eine Liste einfügen kann. Website Capture hat keinen Scheduler und keine Anmeldeunterstützung. CI-Läufe und Seiten hinter einem Login bleiben daher beim Skript.

Häufige Fragen

Braucht Playwright ein sichtbares Browserfenster?

Nein. Browser starten standardmäßig im Headless-Modus. Übergeben Sie headless: false an chromium.launch, wenn Sie die Seite beim Debuggen beobachten möchten.

Kann Playwright JPEG statt PNG speichern?

Ja. Setzen Sie in den Screenshot-Optionen type: 'jpeg' und einen quality-Wert von 0 bis 100 oder verwenden Sie einen Dateinamen mit der Endung .jpg.

Warum ist mein Vollseiten-Screenshot abgeschnitten?

Manche Seiten scrollen in einem inneren Element statt im Dokument. Erfassen Sie dieses Element mit einem Locator-Screenshot oder ändern Sie vor der Aufnahme seine CSS-Höhe.

Kann Playwright Seiten hinter einem Login aufnehmen?

Ja. Melden Sie sich einmal an, speichern Sie die Sitzung mit context.storageState({ path: 'auth.json' }) und erstellen Sie spätere Kontexte mit storageState: 'auth.json'. Halten Sie diese Datei aus der Versionsverwaltung heraus, weil sie Sitzungs-Cookies enthält.

Wie verhindere ich, dass sich Werbung und Zeitstempel bei jeder Aufnahme ändern?

Übergeben Sie deren Locator in der Option mask. Playwright legt über jedes Element ein deckendes Feld, sodass sich Läufe ohne falsche Abweichungen vergleichen lassen.

Warum sehen CI-Screenshots anders aus als auf meinem Laptop?

Schriften, Pixel-Verhältnis und Locale unterscheiden sich meist. Installieren Sie auf dem Runner dieselben Schriften, setzen Sie scale: 'css' und fixieren Sie locale und timezoneId im Kontext, damit Datums- und Zahlenformate übereinstimmen.

Referenzen

• Playwright-Dokumentation zu Screenshots
• Playwright-Emulation und Geräte
• Playwright-Installation

Benötigen Sie No-Code-Automatisierung für Website-Screenshots?

Temposhot Website Capture übernimmt eine eingefügte URL-Liste und erfasst jede Seite auf Ihrem Mac, ohne dass Sie ein Skript warten müssen. Siehe Automatisierung von Website-Screenshots oder beginnen Sie mit dem Schnellstart für Website Capture.