Wie Thumbshot-Dienste arbeiten: Warteschlange, Cache, Aktualisierung

Warum braucht ein Screenshot-Dienst eine Warteschlange?

Eine Warteschlange entkoppelt beim Screenshot-Dienst den schnellen Abruf vom langsamen Rendern. Der Webserver legt nur den Auftrag ab. Eigene Worker-Prozesse arbeiten die Aufträge nacheinander mit dem Browser ab. Dass ein Auftrag scheitern kann, sieht schon die HTTP-Semantik vor. MDN beschreibt den Status 202 als unverbindlich: Die Verarbeitung ist nicht garantiert. Es gibt auch keinen Weg, das Ergebnis später asynchron per HTTP-Antwort mitzuteilen (Quelle: developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202, Stand: Oktober 2026). Der Client muss also erneut nachfragen.

Ist die Warteschlange eines Screenshot-Dienstes voll, hilft der Header Retry-After. Er teilt mit, wann sich eine neue Anfrage lohnt. MDN nennt zwei Hauptfälle. Bei 503 Service Unavailable gibt der Header die erwartete Dauer der Nichtverfügbarkeit an. Bei 429 Too Many Requests nennt er die Wartezeit vor der nächsten Anfrage (Quelle: developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Retry-After, Stand: Oktober 2026).

Wie verhindert man, dass sich Aufnahmen gegenseitig beeinflussen?

Jede Screenshot-Aufnahme sollte in einem frischen, isolierten Browserkontext laufen. So sickern Cookies, Speicher und besuchte Links nicht in die nächste Aufnahme durch. Playwright beschreibt Browser-Kontexte genau für diesen Zweck: Jeder Kontext beginnt neu. Aufräumen zwischen zwei Durchläufen wird dagegen leicht vergessen. Bei Dingen wie besuchten Links ist es laut Playwright gar nicht möglich (Quelle: playwright.dev/docs/browser-contexts, Stand: Oktober 2026).

const context = await browser.newContext({ viewport: { width: 1280, height: 800 } });
const page = await context.newPage();
await page.goto(url, { waitUntil: 'load', timeout: 15000 });
const png = await page.screenshot({ animations: 'disabled' });
await context.close();

Wann ist eine Seite „fertig“ für den Screenshot?

Den Zeitpunkt einer Screenshot-Aufnahme bestimmt die Wartebedingung beim Laden. Playwright kennt für page.goto() vier Optionen: commit, domcontentloaded, load (Standard) und networkidle. networkidle wartet mindestens 500 Millisekunden ohne Netzwerkverbindungen. Die Playwright-Dokumentation bezeichnet diese Option ausdrücklich als nicht empfohlen (Quelle: playwright.dev/docs/api/class-page#page-goto, Stand: Oktober 2026).

Eine harte Zeitgrenze pro Aufnahme verhindert, dass eine hängende Seite einen Worker blockiert. Chrome bietet dafür im Headless-Modus den Schalter --timeout. Nach seinem Ablauf wird der Inhalt erfasst, auch wenn die Seite noch lädt. Der Schalter --virtual-time-budget lässt zeitabhängigen Code wie setTimeout im Zeitraffer ablaufen (Quelle: developer.chrome.com/docs/automation-and-testing/headless-cli, Stand: Oktober 2026).

Wie lange sollte ein Thumbnail im Cache bleiben?

Wie lange ein Thumbnail gültig ist, legt der HTTP-Header Cache-Control fest. Mit max-age=N bleibt eine Antwort N Sekunden nach ihrer Erzeugung frisch. stale-while-revalidate erlaubt einem Cache, eine abgelaufene Antwort noch eine Weile auszuliefern. Währenddessen erneuert er sie im Hintergrund. MDN zeigt dafür das Beispiel max-age=604800, stale-while-revalidate=86400. Das heißt: sieben Tage frisch, danach einen weiteren Tag nutzbar bei gleichzeitiger Neuvalidierung (Quelle: developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control, Stand: Oktober 2026).

Für die Aktualisierung von Thumbnails eignet sich der HTTP-Header ETag. Er ist eine Kennung für eine bestimmte Version einer Ressource. Hat sich das Bild nicht geändert, muss der Server die vollständige Antwort nicht erneut senden (Quelle: developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag, Stand: Oktober 2026). Ein Dienst kann etwa eine Prüfsumme des PNG als ETag verwenden. Clients mit unverändertem Bild bekommen dann nur „nicht geändert“.

Statt per ETag zu prüfen, kann ein Screenshot-Dienst jedem neuen Thumbnail eine eigene Adresse geben. Datum oder Prüfsumme stehen dann im Dateinamen. Das Bild kann mit langer max-age und dem Zusatz immutable ausgeliefert werden. immutable besagt, dass sich die Antwort nicht ändert, solange sie frisch ist. MDN beschreibt dieses Muster als Cache-Busting. Ressourcen werden nie verändert, sondern bei Bedarf durch neue Versionen mit neuer URL ersetzt (Quelle: developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control, Stand: Oktober 2026). Facebook arbeitet bei Link-Vorschauen ähnlich. Zwischengespeicherte Bilder aktualisiert Facebook nur, wenn sich ihre URL ändert (Quelle: developers.facebook.com/docs/sharing/webmasters/, Stand: Oktober 2026).

Was zeigt man, solange das Bild fehlt?

Bis ein Thumbnail fertig ist, braucht die einbindende Seite einen Platzhalter derselben Größe. Sonst entsteht ein Layoutsprung. Web.dev empfiehlt, Bildern immer width und height oder ein CSS-aspect-ratio mitzugeben. Dann reserviert der Browser den Platz schon vor dem Laden (Quelle: web.dev/articles/optimize-cls, Stand: Oktober 2026). Ein neutraler Platzhalter mit dem Hostnamen ist ehrlicher als ein Bild, das wie ein echter Screenshot aussieht.

Muss ein Screenshot-Crawler robots.txt beachten?

Ein Screenshot-Crawler sollte die robots.txt der besuchten Websites beachten. Er ruft fremde Seiten automatisiert ab und ist damit ein Crawler im Sinne des Robots Exclusion Protocol. RFC 9309 bittet Crawler, die Regeln einzuhalten. Zugleich betont der Standard, dass die Regeln keine Zugriffsberechtigung darstellen. Ein Crawler findet die für ihn geltenden Regeln über einen eigenen Namen, das Product Token. Es sollte Teil seines User-Agent-Strings sein. Eine zwischengespeicherte robots.txt soll in der Regel nicht länger als 24 Stunden verwendet werden (Quelle: rfc-editor.org/rfc/rfc9309.html, Stand: Oktober 2026).

Für einen Screenshot-Dienst kommt das Urheberrecht hinzu. Jede Aufnahme ist eine Vervielfältigung der abgebildeten Inhalte. § 16 UrhG erfasst ausdrücklich auch vorübergehende Kopien, gleich in welchem Verfahren (Quelle: gesetze-im-internet.de/urhg/__16.html, Stand: Oktober 2026). Die Rolle der Einwilligung nach dem BGH-Urteil „Vorschaubilder“ erklärt Urheberrecht bei Website-Screenshots. Welche Daten beim Einbinden fremder Dienste fließen, steht unter Screenshot-APIs Dritter und Datenschutz.