Service Worker-Caching und HTTP-Caching

Die Vor- und Nachteile der Verwendung einer einheitlichen oder unterschiedlichen Ablauflogik für die Service Worker-Cache- und HTTP-Cache-Ebenen.

Jonathan Chen

Service Worker und PWAs werden zwar immer mehr zum Standard moderner Webanwendungen, das Caching von Ressourcen ist aber komplexer als je zuvor. In diesem Artikel wird das große Bild des Browser-Caching behandelt, einschließlich:

• Die Anwendungsfälle und Unterschiede zwischen Service Worker-Caching und HTTP-Caching.
• Die Vor- und Nachteile verschiedener Ablaufstrategien für das Service Worker-Caching im Vergleich zu regulären HTTP-Caching-Strategien.

Übersicht über den Caching-Ablauf

Auf hoher Ebene folgt ein Browser bei der Anforderung einer Ressource der folgenden Caching-Reihenfolge:

1. Service Worker-Cache: Der Service Worker prüft, ob sich die Ressource in seinem Cache befindet, und entscheidet anhand seiner programmierten Caching-Strategien, ob er die Ressource selbst zurückgeben soll. Das geschieht nicht automatisch. Sie müssen einen Fetch-Event-Handler in Ihrem Service Worker erstellen und Netzwerkanfragen abfangen, damit die Anfragen aus dem Cache des Service Workers und nicht aus dem Netzwerk bereitgestellt werden.
2. HTTP-Cache (auch als Browser-Cache bezeichnet): Wenn die Ressource im HTTP Cache gefunden wird und noch nicht abgelaufen ist, verwendet der Browser die Ressource automatisch aus dem HTTP-Cache.
3. Serverseitig:Wenn im Service Worker-Cache oder im HTTP-Cache nichts gefunden wird, fordert der Browser die Ressource im Netzwerk an. Wenn die Ressource nicht in einem CDN im Cache gespeichert ist, muss die Anfrage bis zum Ursprungsserver zurückgehen.

Caching-Ebenen

Service Worker-Caching

Ein Service Worker fängt HTTP-Anfragen vom Typ „Netzwerk“ ab und verwendet eine Caching-Strategie um zu bestimmen, welche Ressourcen an den Browser zurückgegeben werden sollen. Der Service Worker-Cache und der HTTP-Cache dienen demselben allgemeinen Zweck, der Service Worker-Cache bietet jedoch mehr Caching-Funktionen, z. B. eine detaillierte Steuerung darüber, was genau im Cache gespeichert wird und wie das Caching erfolgt.

Service Worker-Cache steuern

Ein Service Worker fängt HTTP-Anfragen mit Ereignis Listenern ab (in der Regel das fetch Ereignis). Dieses Code-Snippet veranschaulicht die Logik einer Cache-First-Caching-Strategie.

Wir empfehlen dringend, Workbox zu verwenden, damit Sie das Rad nicht neu erfinden müssen. Sie können beispielsweise Ressourcen-URL-Pfade mit einer einzigen Zeile regulären Ausdruckscodes registrieren.

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

Service Worker-Caching-Strategien und Anwendungsfälle

In der folgenden Tabelle sind gängige Service Worker-Caching-Strategien und die jeweiligen Anwendungsfälle aufgeführt.

Zusätzliche Vorteile des Service Worker-Caching

Neben der detaillierten Steuerung der Caching-Logik bietet das Service Worker-Caching auch Folgendes:

• Mehr Arbeitsspeicher und Speicherplatz für Ihren Ursprung: Der Browser weist HTTP-Cache Ressourcen pro Ursprung zu. Wenn Sie also mehrere Subdomains haben, verwenden alle denselben HTTP-Cache. Es gibt keine Garantie dafür, dass die Inhalte Ihres Ursprungs/Ihrer Domain lange im HTTP-Cache bleiben. Ein Nutzer kann den Cache beispielsweise leeren, indem er die Einstellungen des Browsers manuell bereinigt oder eine harte Aktualisierung auf einer Seite auslöst. Mit einem Service Worker-Cache ist die Wahrscheinlichkeit viel höher, dass Ihre Inhalte im Cache bleiben. Weitere Informationen finden Sie unter Persistent storage.
• Höhere Flexibilität bei instabilen Netzwerken oder Offline-Nutzung:Mit dem HTTP-Cache haben Sie nur eine binäre Auswahl: Entweder die Ressource ist im Cache gespeichert oder nicht. Mit dem Service Worker-Caching können Sie kleine „Hickups“ viel einfacher abmildern (mit der Strategie „Stale-while-revalidate“), eine vollständige Offline-Nutzung anbieten (mit der Strategie „Nur Cache“) oder sogar etwas dazwischen, z. B. benutzerdefinierte UIs, bei denen Teile der Seite aus dem Service Worker-Cache stammen und einige Teile ausgeschlossen sind (mit der Strategie „Catch-Handler festlegen“).

HTTP-Caching

Wenn ein Browser eine Webseite und zugehörige Ressourcen zum ersten Mal lädt, werden diese Ressourcen im HTTP-Cache gespeichert. Der HTTP-Cache ist in der Regel automatisch in Browsern aktiviert, es sei denn, er wurde vom Endnutzer explizit deaktiviert.

Wenn Sie HTTP-Caching verwenden, müssen Sie sich darauf verlassen, dass der Server bestimmt, wann eine Ressource im Cache gespeichert wird und wie lange.

Ablauf des HTTP-Cache mit HTTP-Antwortheadern steuern

Wenn ein Server auf eine Browseranfrage nach einer Ressource antwortet, verwendet er HTTP-Antwortheader, um dem Browser mitzuteilen, wie lange er die Ressource im Cache speichern soll. Weitere Informationen finden Sie unter Antwortheader: Webserver konfigurieren.

HTTP-Caching-Strategien und Anwendungsfälle

HTTP-Caching ist viel einfacher als Service Worker-Caching, da es nur um die zeitbasierte (TTL) Ablauflogik für Ressourcen geht. Weitere Informationen zu HTTP-Caching-Strategien finden Sie unter Welche Werte für Antwortheader sollten Sie verwenden? und Unnötige Netzwerkanfragen mit dem HTTP-Cache verhindern (Zusammenfassung).

Ablauflogik für den Cache entwerfen

In diesem Abschnitt werden die Vor- und Nachteile der Verwendung einer einheitlichen Ablauflogik für die Service Worker-Cache- und HTTP-Cache-Ebenen sowie die Vor- und Nachteile einer separaten Ablauflogik für diese Ebenen erläutert.

Einheitliche Ablauflogik für alle Cache-Ebenen

Um die Vor- und Nachteile zu veranschaulichen, betrachten wir drei Szenarien: langfristig, mittelfristig und kurzfristig.

Szenario: Langfristiges Caching (Cache, Fallback auf Netzwerk)

• Wenn eine im Cache gespeicherte Ressource gültig ist (<= 30 Tage): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück, ohne das Netzwerk zu verwenden.
• Wenn eine im Cache gespeicherte Ressource abgelaufen ist (> 30 Tage): Der Service Worker ruft die Ressource im Netzwerk ab. Der Browser hat keine Kopie der Ressource im HTTP-Cache, daher wird die Ressource serverseitig abgerufen.

Nachteil: In diesem Szenario bietet das HTTP-Caching weniger Wert, da der Browser die Anfrage immer serverseitig weiterleitet, wenn der Cache im Service Worker abläuft.

Szenario: Mittelfristiges Caching (Stale-while-revalidate)

• Wenn eine im Cache gespeicherte Ressource gültig ist (<= 1 Tag): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource im Netzwerk ab. Der Browser hat eine Kopie der Ressource im HTTP-Cache und gibt diese Kopie an den Service Worker zurück.
• Wenn eine im Cache gespeicherte Ressource abgelaufen ist (> 1 Tag): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource im Netzwerk ab. Der Browser hat keine Kopie der Ressource im HTTP-Cache, daher wird die Ressource serverseitig abgerufen.

Nachteil: Der Service Worker erfordert zusätzliches Cache-Busting, um den HTTP-Cache zu überschreiben und den Schritt „Revalidieren“ optimal zu nutzen.

Szenario: Kurzfristiges Caching (Netzwerk, Fallback auf Cache)

• Wenn eine im Cache gespeicherte Ressource gültig ist (<= 10 Minuten): Der Service Worker ruft die Ressource im Netzwerk ab. Der Browser hat eine Kopie der Ressource in seinem HTTP-Cache und gibt diese an den Service Worker zurück, ohne serverseitig zu agieren.
• Wenn eine im Cache gespeicherte Ressource abgelaufen ist (> 10 Minuten): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource im Netzwerk ab. Der Browser hat keine Kopie der Ressource im HTTP-Cache, daher wird die Ressource serverseitig abgerufen.

Nachteil: Ähnlich wie beim mittelfristigen Caching erfordert der Service Worker zusätzliche Cache-Busting-Logik, um den HTTP-Cache zu überschreiben und die neueste Ressource serverseitig abzurufen.

Service Worker in allen Szenarien

In allen Szenarien kann der Service Worker-Cache weiterhin im Cache gespeicherte Ressourcen zurückgeben, wenn das Netzwerk instabil ist. Der HTTP-Cache ist dagegen nicht zuverlässig, wenn das Netzwerk instabil oder ausgefallen ist.

Unterschiedliche Ablauflogik für den Cache auf der Service Worker-Cache- und HTTP-Ebene

Um die Vor- und Nachteile zu veranschaulichen, betrachten wir wieder langfristige, mittelfristige und kurzfristige Szenarien.

Szenario: Langfristiges Caching (Cache, Fallback auf Netzwerk)

• Wenn eine im Service Worker-Cache gespeicherte Ressource gültig ist (<= 90 Tage): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück.
• Wenn eine im Service Worker-Cache gespeicherte Ressource abgelaufen ist (> 90 Tage): Der Service Worker ruft die Ressource im Netzwerk ab. Der Browser hat keine Kopie der Ressource im HTTP-Cache, daher wird die Ressource serverseitig abgerufen.

Vor- und Nachteile:

• Vorteil: Nutzer erhalten sofort eine Antwort, da der Service Worker im Cache gespeicherte Ressourcen sofort zurückgibt.
• Vorteil: Der Service Worker hat eine detailliertere Kontrolle darüber, wann er seinen Cache verwenden und wann er neue Versionen von Ressourcen anfordern soll.
• Nachteil: Eine gut definierte Service Worker-Caching-Strategie ist erforderlich.

Szenario: Mittelfristiges Caching (Stale-while-revalidate)

• Wenn eine im Service Worker-Cache gespeicherte Ressource gültig ist (<= 30 Tage): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück.
• Wenn eine im Service Worker-Cache gespeicherte Ressource abgelaufen ist (> 30 Tage): Der Service Worker ruft die Ressource im Netzwerk ab. Der Browser hat keine Kopie der Ressource im HTTP-Cache, daher wird die Ressource serverseitig abgerufen.

Vor- und Nachteile:

• Vorteil: Nutzer erhalten sofort eine Antwort, da der Service Worker im Cache gespeicherte Ressourcen sofort zurückgibt.
• Vorteil: Der Service Worker kann dafür sorgen, dass bei der nächsten Anfrage für eine bestimmte URL eine aktuelle Antwort aus dem Netzwerk verwendet wird, da die Revalidierung im Hintergrund erfolgt.
• Nachteil: Eine gut definierte Service Worker-Caching-Strategie ist erforderlich.

Szenario: Kurzfristiges Caching (Netzwerk, Fallback auf Cache)

• Wenn eine im Service Worker-Cache gespeicherte Ressource gültig ist (<= 1 Tag): Der Service Worker ruft die Ressource im Netzwerk ab. Der Browser gibt die Ressource aus dem HTTP-Cache zurück, wenn sie dort vorhanden ist. Wenn das Netzwerk ausgefallen ist, gibt der Service Worker die Ressource aus dem Service Worker-Cache zurück.
• Wenn eine im Service Worker-Cache gespeicherte Ressource abgelaufen ist (> 1 Tag): Der Service Worker ruft die Ressource im Netzwerk ab. Der Browser ruft die Ressourcen über das Netzwerk ab, da die im HTTP-Cache gespeicherte Version abgelaufen ist.

Vor- und Nachteile:

• Vorteil: Wenn das Netzwerk instabil oder ausgefallen ist, gibt der Service Worker im Cache gespeicherte Ressourcen sofort zurück.
• Nachteil: Der Service Worker erfordert zusätzliches Cache-Busting, um den HTTP-Cache zu überschreiben und „Network-First“-Anfragen zu stellen.

Fazit

Angesichts der Komplexität der Kombination von Caching-Szenarien ist es nicht möglich, eine Regel zu entwerfen, die alle Fälle abdeckt. Basierend auf den Ergebnissen in den vorherigen Abschnitten gibt es jedoch einige Vorschläge, die Sie beim Entwerfen Ihrer Cache-Strategien berücksichtigen sollten:

• Die Service Worker-Caching-Logik muss nicht mit der Ablauflogik des HTTP-Caching übereinstimmen. Verwenden Sie nach Möglichkeit eine längere Ablauflogik im Service Worker, um ihm mehr Kontrolle zu geben.
• HTTP-Caching spielt nach wie vor eine wichtige Rolle, ist aber nicht zuverlässig, wenn das Netzwerk instabil oder ausgefallen ist.
• Überprüfen Sie Ihre Caching-Strategien für jede Ressource, um sicherzustellen, dass Ihre Service Worker-Caching-Strategie ihren Wert bietet, ohne mit dem HTTP-Cache in Konflikt zu geraten.

Weitere Informationen

• Netzwerkzuverlässigkeit
• Unnötige Netzwerkanfragen mit dem HTTP-Cache verhindern
• HTTP-Cache-Codelab
• Auswirkungen von Service Workern auf die Leistung in der Praxis messen
• Cache-Control vs. Expires
• Caching entmystifiziert: Caches prüfen, leeren und deaktivieren