Stale-While-Revalidate vs Cache First: welche Service Worker Cache-Strategie wählen

Wenn ein Service Worker bereits registriert ist, ändert sich die Hauptfrage: Nicht „sollte ich cachen“, sondern „wie genau“. Cache First liefert eine Datei aus dem Cache und fragt nicht den Server, Stale-While-Revalidate liefert den Cache und aktualisiert ihn sofort im Hintergrund. Der Unterschied scheint gering, aber er bestimmt, was der Benutzer nach der Veröffentlichung sieht, wie viel Traffic die Anwendung verbraucht und ob die Website in der alten Version stecken bleibt. Ich habe bereits analysiert, warum Cache First für HTML gefährlich ist, im Artikel „8 kritische Fehler bei der PWA-Integration“. Hier analysiere ich die Wahl selbst: was jede Strategie tut, für welche Ressourcen sie geeignet ist und was man dafür bezahlen muss. Das Material basiert auf der offiziellen Dokumentation von Workbox, web.dev und WebKit.

⚡ Kurz: Welche Strategie wofür

• ✅ Cache First eignet sich gut für statische Inhalte, insbesondere mit einem Hash im Dateinamen (CSS, JS, Schriftarten): laut Workbox-Dokumentation bietet es Geschwindigkeitsvorteile für unveränderliche Dateien, da es die Aktualitätsprüfungen auf dem Server überspringt.
• ✅ Stale-While-Revalidate (SWR) eignet sich für Ressourcen, die etwas wichtig sind, frisch zu halten, aber nicht kritisch: Workbox nennt als Beispiel Avatare in sozialen Netzwerken.
• ⚠️ Der Preis von SWR: Der Benutzer sieht eine Version, die einen Besuch älter ist, und die Anwendung macht immer eine Netzwerkanfrage im Hintergrund.
• ⚠️ HTML sollte normalerweise besser über Network First als über Cache First geliefert werden.

Dies ist ein Ausgangspunkt, kein Gesetz. Unten finden Sie Erklärungen, warum das so ist und wovon Abweichungen abhängen.

📚 Inhalt des Artikels

• Wie Service Worker cacht: Cache API, fetch und Lebenszyklus
• Cache First: Wie es funktioniert und wo es fehlschlägt
• Stale-While-Revalidate: Wie es funktioniert und was es kostet
• Vergleich von Cache First und SWR
• Auswahlmatrix nach Ressourcentyp
• Implementierung: reines JS und Workbox
• Updates ohne Überraschungen
• Typische Fehler
• iOS und Speicher
• Caching zusammen mit Push-Diensten
• Wie man das Ergebnis überprüft
• Häufig gestellte Fragen (FAQ)
• Schlussfolgerungen
• Quellen

🧠 Wie Service Worker cacht: Cache API, fetch und Lebenszyklus

Die Caching-Strategie ist eine Interaktion zwischen dem fetch-Ereignis im Service Worker und der Cache-Schnittstelle. Das fetch-Ereignis fängt die Anfrage ab, und die Cache API ermöglicht das manuelle Speichern und Abrufen von Antworten (caches.open, cache.put, cache.match, cache.delete).

Es ist wichtig, dies nicht mit dem HTTP-Cache zu verwechseln. Laut Dokumentation ist Cache ein separater Mechanismus, und die Cache-Control-Einstellungen beeinflussen nicht, was in ihn gelangt. Daher steuern Sie den Cache im Service Worker selbst, und jede Ressource, die Sie dort ablegen, bleibt dort, bis Sie sie aktualisieren oder löschen.

Was den Lebenszyklus betrifft: Ein neuer Service Worker durchläuft die Installation und das Warten und wird aktiviert, wenn der alte keine offenen Tabs mehr steuert (mehr auf web.dev). Dies beeinflusst Updates, dazu später mehr. Um den Anfragetyp zu erkennen, empfiehlt Workbox die Verwendung von request.destination anstelle der Dateierweiterung: So werden Fehler bei der Übereinstimmung nach Erweiterung vermieden.

📦 Cache First: Wie es funktioniert und wo es fehlschlägt

Algorithmus laut Workbox-Dokumentation: Die Anfrage geht zuerst in den Cache; wenn eine Antwort dort vorhanden ist, wird sie geliefert; wenn nicht, wird das Netzwerk kontaktiert, die Antwort in den Cache gelegt und dem Benutzer zurückgegeben.

Wann Cache First wählen

• Dateien sind für ihre URL unveränderlich: Der Build fügt einen Hash in den Namen ein (app.3f9a1c.js), die neue Version erhält eine neue Adresse.
• Die Geschwindigkeit des wiederholten Besuchs und die Offline-Funktionalität sind wichtig.
• Die Ressource ist groß oder ändert sich selten: Schriftarten, Icons, Bibliotheken.

Wann nicht wählen

• Der Dateiname ändert sich nicht zwischen den Releases (style.css), aber der Inhalt ändert sich.
• Es handelt sich um HTML, API-Antworten oder persönliche Daten.
• Die Antwort kann undurchsichtig (opaque) sein: Ohne Statusprüfung kann ein Fehler in den Cache gelangen (siehe Abschnitt über Fehler).

🔄 Stale-While-Revalidate: Wie es funktioniert und was es kostet

Algorithmus laut Workbox-Dokumentation: Bei der ersten Anfrage wird die Ressource aus dem Netzwerk bezogen und in den Cache gelegt; bei nachfolgenden Anfragen wird sie aus dem Cache geliefert, und im Hintergrund wird das Netzwerk erneut abgefragt und der Eintrag aktualisiert; die nächste Anfrage erhält dann eine aktuellere Version. Wenn die Ressource nicht im Cache ist, wartet SWR auf das Netzwerk.

Wann SWR wählen

• Die Ressource ändert sich von Zeit zu Zeit, aber sofortige Aktualität ist nicht kritisch (Profilbilder, Vorschauen, optionale Verzeichnisse).
• Die Datei hat eine stabile URL ohne Hash, und Sie möchten, dass sie sich selbst aktualisiert.
• Sie benötigen die Geschwindigkeit von Cache First, aber ohne das Risiko von „eingefrorenen“ Dateien.

Wann nicht wählen

• Daten müssen immer korrekt sein (Guthaben, Verfügbarkeit, Preise im Warenkorb): Besser Network First oder Network Only.
• Der Traffic ist teuer oder begrenzt, und die Ressource ist groß und ändert sich selten: Dann spart Cache First das Netzwerk.

SWR ohne Service Worker: Cache-Control-Direktive

Die Idee von SWR kann auch auf HTTP-Ebene implementiert werden: web.dev beschreibt den Header Cache-Control: max-age=1, stale-while-revalidate=59, dessen Unterstützung in Chrome 75 und Firefox 68 erschien. Für die Wahl des Ansatzes empfiehlt web.dev die Orientierung wie folgt: Wenn Sie bereits einen Service Worker haben, ist sein Ansatz bequemer; wenn Sie keinen Worker bereitstellen und warten möchten, reicht der Header aus. Wenn der Worker bereits eine Anfrage verarbeitet, antwortet er zuerst, und das Verhalten des Headers tritt nur in Kraft, wenn der Worker nicht antwortet oder fetch() selbst aufruft.

⚖️ Vergleich von Cache First und SWR

Andere Strategien kurz

Network First geht zuerst ins Netzwerk und liefert bei dessen Abwesenheit die letzte gecachte Version: laut Dokumentation ist dies eine gute Wahl für HTML und APIs, wenn online eine aktuelle Version benötigt wird und offline die letzte verfügbare ausreicht. Network Only holt immer die Antwort aus dem Netzwerk, garantiert Aktualität, funktioniert aber nicht offline. Cache Only liefert nur gecachte Inhalte, daher müssen die Ressourcen vorab gecacht werden, und sie werden nicht aktualisiert, bis der Worker aktualisiert wird. Warum Cache First für HTML gefährlich ist, wird im Artikel über 8 PWA-Fehler analysiert.

🗂️ Auswahlmatrix nach Ressourcentyp

Schnelle Auswahl nach Fragen

• Ändert sich der Inhalt bei derselben URL? Nein → Cache First. Ja → weiter.
• Ist die Aktualität in jedem Moment kritisch? Ja → Network First oder Network Only. Nein → SWR.
• Enthält die Antwort persönliche Daten? Ja → nicht cachen.
• Ist Offline-Funktionalität erforderlich? Ja → Cache First, SWR oder Network First (mit Fallback auf Cache).

🛠️ Implementierung: reines JS und Workbox

Cache First mit reinem JS

const STATIC_CACHE = 'static-v1';

self.addEventListener('fetch', (event) => {
  const { request } = event;
  const dest = request.destination;

  if (request.method !== 'GET') return;
  if (dest !== 'style' && dest !== 'script' && dest !== 'font') return;

  event.respondWith((async () => {
    const cache = await caches.open(STATIC_CACHE);
    const cached = await cache.match(request);
    if (cached) return cached;

    const response = await fetch(request);
    // Nur erfolgreiche Antworten in den Cache legen
    if (response.ok) {
      cache.put(request, response.clone());
    }
    return response;
  })());
});

Stale-While-Revalidate mit reinem JS

const IMAGES_CACHE = 'images-v1';

self.addEventListener('fetch', (event) => {
  const { request } = event;
  if (request.method !== 'GET' || request.destination !== 'image') return;

  event.respondWith((async () => {
    const cache = await caches.open(IMAGES_CACHE);
    const cached = await cache.match(request);

    // Hintergrundanfrage: Cache mit frischer Antwort aktualisieren
    const networkUpdate = fetch(request)
      .then((response) => {
        if (response.ok) cache.put(request, response.clone());
        return response;
      })
      .catch(() => undefined);

    // Verhindern, dass der Worker beendet wird, solange der Cache aktualisiert wird
    event.waitUntil(networkUpdate);

    return cached || (await networkUpdate) || Response.error();
  })());
});

Die Basis dieser Beispiele entspricht den Beispielen aus der Workbox-Dokumentation. Von mir hinzugefügt wurden die Überprüfung von response.ok und event.waitUntil. Die Beispiele sind vereinfacht und wurden nicht ausgeführt, also überprüfen Sie sie in Ihrem Projekt.

Dasselbe mit Workbox

import { registerRoute } from 'workbox-routing';
import { CacheFirst, StaleWhileRevalidate } from 'workbox-strategies';
import { ExpirationPlugin } from 'workbox-expiration';
import { CacheableResponsePlugin } from 'workbox-cacheable-response';

// CSS und JS mit Hash im Namen: Cache First
registerRoute(
  ({ request }) => request.destination === 'script' || request.destination === 'style',
  new CacheFirst({
    cacheName: 'static-assets',
    plugins: [
      new ExpirationPlugin({ maxEntries: 60, purgeOnQuotaError: true }),
    ],
  })
);

// Bilder: Stale-While-Revalidate
registerRoute(
  ({ request }) => request.destination === 'image',
  new StaleWhileRevalidate({
    cacheName: 'images',
    plugins: [
      new CacheableResponsePlugin({ statuses: [200] }),
      new ExpirationPlugin({
        maxEntries: 100,
        maxAgeSeconds: 30 * 24 * 60 * 60,
        purgeOnQuotaError: true,
      }),
    ],
  })
);

Die Werte für maxEntries und maxAgeSeconds im Beispiel sind Richtwerte: passen Sie sie an Ihre Website an. Separate Caches für verschiedene Ressourcentypen (Parameter cacheName) helfen sowohl bei der Organisation als auch bei der Bereinigung (Workbox-Dokumentation).

🔁 Updates ohne Überraschungen

• Versionierung. Für Cache First in einer vernünftigen Build-Pipeline erhalten Dateien einen Hash im Namen, und alte Einträge werden zusammen mit der Cache-Version gelöscht. Ein Beispiel mit skipWaiting(), clients.claim() und dem Löschen alter Caches finden Sie im Artikel über 8 PWA-Fehler, und zum Aktualisieren von Workern in Workbox: Handle updates immediately.
• Benachrichtigung über neue Version für SWR. Da SWR die vorherige Version ausliefert, ist es für den Benutzer nützlich zu erfahren, dass es eine neuere gibt. Workbox hat dafür das BroadcastUpdatePlugin: es sendet eine Nachricht an die Seite, wenn die gecachte Antwort aktualisiert wurde.

// sw.js
import { StaleWhileRevalidate } from 'workbox-strategies';
import { BroadcastUpdatePlugin } from 'workbox-broadcast-update';

new StaleWhileRevalidate({
  cacheName: 'api-public',
  plugins: [new BroadcastUpdatePlugin()],
});

// Auf der Seite
navigator.serviceWorker.addEventListener('message', async (event) => {
  if (event.data.meta === 'workbox-broadcast-update') {
    const { cacheName, updatedURL } = event.data.payload;
    // Zeigen Sie dem Benutzer "Es gibt eine neue Version. Aktualisieren?"
  }
});

Das Nachrichtenformat (type: 'CACHE_UPDATED', meta: 'workbox-broadcast-update', payload mit cacheName und updatedURL) stammt aus der Dokumentation des Moduls.

⚠️ Typische Fehler

• Caching von Fehlern und undurchsichtigen Antworten. In Workbox werden Antworten ohne CORS (opaque) standardmäßig vorsichtig nicht gecacht, da der Status nicht sichtbar ist und ein gecachter Fehler bei Cache First lange bestehen bleibt. Für solche Antworten empfiehlt die Dokumentation Network First oder SWR, und Anfragen von HTML sollten mit dem Attribut crossorigin markiert werden, um eine transparente Antwort zu erhalten. In Ihrem eigenen Code sollten Sie immer response.ok überprüfen.
• Unbegrenztes Cache-Wachstum. Verwenden Sie ExpirationPlugin. Laut Dokumentation ist maxEntries effektiver als maxAgeSeconds zur Kontrolle des Volumens, und purgeOnQuotaError ermöglicht die automatische Cache-Bereinigung bei Platzmangel. Undurchsichtige Antworten "wiegen" viel: in Chrome wird selbst eine kleine solche Antwort mit etwa 7 MB Kontingent berechnet.
• Audio und Video. Benötigt workbox-range-requests, das Attribut crossorigin im Element <video> oder <audio>, und Medien sollten im Voraus gecacht werden (über precache oder cache.add()), da während der Wiedergabe nur ein Teil heruntergeladen wird und das "on the fly" Caching nicht funktioniert.
• Autorisierte Seiten und POST. Cachen Sie keine Antworten mit persönlichen Daten und verwenden Sie nicht Cache First für Anfragen, die den Zustand ändern. Ein Beispiel für eine Whitelist von Routen finden Sie im Artikel über 8 PWA-Fehler.
• Fehler beim Worker-Update. Wenn ein Worker die Website beschädigt hat, gibt es eine Anleitung von Workbox zum Entfernen eines fehlerhaften Service Workers.

🍎 iOS und Speicher

Kontingente. Gemäß der Speicherrichtlinie von WebKit kann ab Safari 17 und iOS 17 das Kontingent für eine Webanwendung pro Origin bis zu 60 % des gesamten Festplattenspeichers betragen, und für andere WebKit-Anwendungen 15 %. Eine Webanwendung vom Startbildschirm hat dieselben Kontingente wie im Browser. Der Cache wird pro Origin gelöscht, wenn die Gesamtnutzung das Gesamt-Kontingent überschreitet, und wenn ein Origin den permanenten Modus über die Storage API angefordert hat, ist er davon nicht betroffen. WebKit entscheidet, ob die Anfrage erfüllt wird, anhand von Heuristiken, z. B. ob die Website als Webanwendung vom Startbildschirm geöffnet wurde.

Die "7-Tage-Regel". Es wird oft geschrieben, dass Safari den PWA-Cache nach 7 Tagen Inaktivität löscht. WebKit präzisiert: Dies bezieht sich auf das Löschen von Daten, die von einem Skript geschrieben wurden, nach sieben Tagen Nutzung von Safari ohne Interaktion mit der Website, und Webanwendungen vom Startbildschirm haben ihren eigenen Nutzungszähler, der beim Start der Anwendung zurückgesetzt wird. Für eine Website, die nur in Safari-Tabs geöffnet wird, ist das Risiko, den Cache zu verlieren, real, für eine installierte PWA ist es jedoch deutlich geringer. Speichern Sie dennoch keine einzige Kopie wichtiger Daten im Cache: speichern Sie sie auf dem Server und halten Sie den Cache als Beschleuniger.

Weitere Bedingungen für iOS (Startbildschirm, Push) finden Sie im Artikel "PWA Push-Benachrichtigungen auf iOS im Jahr 2026".

🔌 Caching zusammen mit Push-Diensten

Wenn Sie einen Push-Dienst hinzufügen, haben Sie zwei Aufgaben für denselben Service Worker: Caching und Push-Verarbeitung. Die Dokumentation mehrerer Dienste beschreibt, wie sie kombiniert werden können:

• OneSignal erlaubt es, eine Zeile importScripts zu Ihrem Worker hinzuzufügen oder ihn separat unter einem anderen Pfad oder Bereich zu platzieren, und erwähnt direkt, dass der OneSignal-Worker mit dem Stammverzeichnis des PWA-Bereichs in Konflikt geraten kann.
• FCM erfordert eine Datei firebase-messaging-sw.js im Stammverzeichnis der Domain.
• Pushwoosh beschreibt den Parameter serviceWorkerUrl und die Einbindung seines Workers über importScripts.

Praktische Regel aus Sicht des Cachings: Behandeln Sie in Ihrem fetch-Handler nur Anfragen, die Sie tatsächlich cachen (GET von Ihrem Origin mit bekannten Ressourcentypen), und fangen Sie keine Anfragen an den Push-Dienst selbst ab. Ein Vergleich von Diensten und Risiken von Worker-Konflikten wird im Artikel "Push-Dienste für PWA" behandelt.

📈 Wie man das Ergebnis überprüft

• DevTools → Application. Die Tabs Service Workers und Cache Storage zeigen den Status des Workers und den Inhalt der Caches (so beschreibt es die Workbox-Dokumentation).
• Network. Sehen Sie, welche Anfragen vom Worker bedient werden und welche ins Netzwerk gehen. Bei SWR sollte bei jedem Zugriff eine Hintergrundanfrage erfolgen.
• Offline-Modus. Aktivieren Sie die Offline-Simulation und laden Sie die Seite neu: Zumindest die Hülle und kritische Ressourcen sollten sich öffnen.
• Updates nach der Veröffentlichung. Stellen Sie eine neue Build bereit und stellen Sie sicher, dass der Benutzer (auch in einem bereits geöffneten Tab) die neue Version innerhalb der erwarteten Zeit erhält.
• Lighthouse. Hilft bei der Überprüfung des Gesamtbildes von PWA und Leistung.

❓ Häufig gestellte Fragen (FAQ)

Was wählt man für CSS und JS: Cache First oder SWR?

Wenn die Dateien einen Hash im Namen haben, ist Cache First normalerweise geeignet: Eine neue Build ergibt eine neue URL. Wenn sich der Name zwischen den Releases nicht ändert, verwenden Sie SWR oder Network First, sonst kann der Benutzer bei einer alten Datei bleiben.

Kann HTML über SWR gecacht werden?

Technisch ja, aber der Benutzer sieht die Version, die einen Besuch älter ist. Wenn dies akzeptabel ist und Sie eine Update-Benachrichtigung anzeigen, funktioniert SWR. Für Seiten, bei denen die Aktualität wichtig ist, ist Network First besser.

Wird Workbox benötigt?

Nein, alles kann manuell geschrieben werden, wie in den obigen Beispielen. Workbox bietet fertige Strategien und Plugins (ExpirationPlugin, BroadcastUpdatePlugin, RangeRequestsPlugin), die die Fehlerzahl reduzieren. Die Workbox-Dokumentationsseiten, auf die ich verweise, wurden zuletzt 2018–2021 aktualisiert, prüfen Sie also die Versionen vor der Verwendung.

Was ist der Unterschied zwischen SWR in Service Worker und stale-while-revalidate in Cache-Control?

Die Idee ist dieselbe, aber die Ebene ist unterschiedlich: Der Header funktioniert auf der Ebene des Browser-HTTP-Caches und benötigt keinen Worker, während SWR im Worker von Ihrem Code (oder Workbox) gesteuert wird und mit der Cache API arbeiten kann. Wenn der Worker bereits auf eine Anfrage antwortet, greift er zuerst.

Warum sieht der Benutzer nach der Veröffentlichung die alte Version?

Typische Gründe: HTML wird über Cache First ausgeliefert, der Dateiname hat sich bei Cache First nicht geändert, der neue Worker wartet auf das Schließen von Tabs. Überprüfen Sie die Strategie für jeden Ressourcentyp und den Lebenszyklus des Workers.

✅ Schlussfolgerungen

• 🔹 Die Wahl der Strategie ist nicht "eine ist die beste", sondern die Übereinstimmung mit dem Ressourcentyp: unveränderliche Dateien mit Hash reagieren gut auf Cache First, während Ressourcen, die ohne großen Aufwand aktualisiert werden sollten, für SWR geeignet sind.
• 🔹 SWR zahlt für Frische mit zwei Dingen: Der Benutzer sieht die vorherige Version, und das Netzwerk erhält eine zusätzliche Anfrage.
• 🔹 HTML und sich schnell ändernde Daten werden besser über Network First ausgeliefert, persönliche Antworten werden nicht gecacht.
• 🔹 Überprüfen Sie immer den Antwortstatus, bevor Sie in den Cache schreiben, und begrenzen Sie die Cache-Größe.
• 🔹 Berücksichtigen Sie unter iOS Quoten und den Unterschied zwischen einem Safari-Tab und einer installierten PWA.
• 🔹 Wenn Sie einen Push-Dienst hinzufügen, überlegen Sie im Voraus, wie Sie dessen Worker mit Ihrem kombinieren.

Einen allgemeinen Vergleich von PWA und nativer Anwendung, wenn Sie die Plattform wählen, finden Sie hier: PWA vs. Native in 2026.

📖 Lesen Sie auch

• 8 kritische Fehler bei der PWA-Integration: Szenarien, Ursachen und Lösungen mit Code
• Push-Dienste für PWA: OneSignal, FCM, Pushwoosh, WonderPush und Braze
• PWA Push-Benachrichtigungen unter iOS in 2026: Was wirklich funktioniert
• PWA vs. Native in 2026: Vergleich, Auswahl-Szenarien und ein realer Fall

📎 Quellen

• Workbox: Strategien für Service Worker Caching
• Workbox: Ressourcen während der Laufzeit cachen
• Workbox: workbox-strategies
• Workbox: Speicherquoten verstehen
• Workbox: Gecachte Audio- und Videodateien bereitstellen
• Workbox: workbox-broadcast-update
• Workbox: Updates sofort behandeln
• Workbox: Fehlerhafte Service Worker entfernen
• Workbox: Navigation Preload für Network-first HTML
• web.dev: Dinge frisch halten mit stale-while-revalidate
• web.dev: Der Lebenszyklus von Service Workern
• WebKit: Updates zur Speicherrichtlinie
• WebKit: Vollständige Blockierung von Drittanbieter-Cookies und mehr
• OneSignal: Service Worker
• Firebase: Cloud Messaging für Web
• Pushwoosh Docs: Web Push SDK 3.0

Wichtig: Die Dokumentation, auf die ich mich beziehe, ist teilweise auf die Jahre 2018–2021 datiert (Workbox-Seiten), und Browserrichtlinien ändern sich. Überprüfen Sie die aktuellen Versionen der Bibliotheken und das Verhalten der Browser, bevor Sie sie verwenden. Das Material ist auf dem Stand von Oktober 2026.