Service Worker-Caching und HTTP-Caching

Die Vor- und Nachteile der Verwendung einer einheitlichen oder unterschiedlichen Ablauflogik in den Service Worker-Cache- und HTTP-Cache-Ebenen.

Jonathan Chen

Während Service Worker und PWAs zu Standards moderner Webanwendungen werden, ist das Ressourcen-Caching komplexer geworden als je zuvor. In diesem Artikel werden die wichtigsten Aspekte des Browser-Cachings behandelt, darunter:

• Die Anwendungsfälle und Unterschiede zwischen dem Service Worker-Caching und dem HTTP-Caching.
• Die Vor- und Nachteile der unterschiedlichen Strategien für das Ablaufen des Cachings von Service Workern im Vergleich zu normalen HTTP-Caching-Strategien

Caching-Ablauf

Im Allgemeinen folgt ein Browser der folgenden Caching-Reihenfolge, wenn er eine Ressource anfordert:

1. Service-Worker-Cache: Der Service Worker prüft, ob sich die Ressource im Cache befindet, und entscheidet anhand der programmierten Caching-Strategien, ob die Ressource selbst zurückgegeben werden soll. Dies geschieht nicht automatisch. Sie müssen in Ihrem Service Worker einen Fetch-Ereignis-Handler erstellen und Netzwerkanfragen abfangen, damit die Anfragen nicht über das Netzwerk, sondern über den Cache des Service Workers gesendet werden.
2. HTTP-Cache (auch Browser-Cache genannt): Wenn sich die Ressource im HTTP-Cache befindet und noch nicht abgelaufen ist, verwendet der Browser automatisch die Ressource aus dem HTTP-Cache.
3. Serverseitig:Wenn im Service Worker-Cache oder 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ückgesendet werden.

Caching-Ebenen

Service Worker-Caching

Ein Service Worker fängt HTTP-Anfragen vom Netzwerk ab und bestimmt mithilfe einer Caching-Strategie, welche Ressourcen an den Browser zurückgegeben werden sollen. Der Service Worker-Cache und der HTTP-Cache dienen demselben allgemeinen Zweck, aber der Service Worker-Cache bietet mehr Caching-Funktionen, z. B. eine detaillierte Kontrolle darüber, was genau im Cache gespeichert wird und wie das Caching durchgeführt wird.

Service Worker-Cache steuern

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

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

import {registerRoute} from 'workbox-routing';

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

Caching-Strategien und Anwendungsfälle für Service Worker

In der folgenden Tabelle werden gängige Caching-Strategien für Service Worker und ihre Anwendungsfälle beschrieben.

Weitere Vorteile des Service Worker-Cachings

Neben der detaillierten Steuerung der Caching-Logik bietet das Caching von Service Workern auch folgende Vorteile:

• Mehr Arbeitsspeicher und Speicherplatz für den Ursprung: Der Browser weist HTTP-Cache-Ressourcen pro Ursprung zu. Wenn Sie also mehrere Subdomains haben, teilen sich diese denselben HTTP-Cache. Es gibt keine Garantie dafür, dass die Inhalte Ihrer Quelle/Domain lange im HTTP-Cache bleiben. Ein Nutzer kann beispielsweise den Cache leeren, indem er ihn manuell über die UI der Browsereinstellungen bereinigt oder eine Seite vollständig neu lädt. Mit einem Service Worker-Cache ist die Wahrscheinlichkeit viel höher, dass Ihre im Cache gespeicherten Inhalte dort verbleiben. Weitere Informationen finden Sie unter Persistenter Speicher.
• Höhere Flexibilität bei instabilen Netzwerken oder Offlinenutzung: Beim HTTP-Cache haben Sie nur die Wahl zwischen „Ja“ und „Nein“. Mit dem Service Worker-Caching können Sie kleinere Probleme viel einfacher beheben (mit der Strategie „Stale-While-Revalidate“), eine vollständige Offlinenutzung ermöglichen (mit der Strategie „Nur Cache“) oder sogar eine Zwischenlösung anbieten, z. B. benutzerdefinierte Benutzeroberflächen, bei denen Teile der Seite aus dem Service Worker-Cache stammen und andere Teile gegebenenfalls ausgeschlossen werden (mit der Strategie „Set catch handler“).

HTTP-Caching

Wenn ein Browser zum ersten Mal eine Webseite und zugehörige Ressourcen lädt, speichert er diese Ressourcen in seinem HTTP-Cache. Der HTTP-Cache wird in der Regel automatisch von Browsern aktiviert, es sei denn, er wurde vom Endnutzer ausdrücklich deaktiviert.

Bei HTTP-Caching wird der Server angewiesen, um zu bestimmen, wann und wie lange eine Ressource im Cache gespeichert werden soll.

Ablauf des HTTP-Caches mit HTTP-Antwortheadern steuern

Wenn ein Server auf eine Browseranfrage nach einer Ressource antwortet, gibt er mithilfe von HTTP-Antwortheadern an, wie lange die Ressource im Cache gespeichert werden soll. Weitere Informationen finden Sie unter Antwortheader: Webserver konfigurieren.

HTTP-Caching-Strategien und Anwendungsfälle

Das HTTP-Caching ist viel einfacher als das Service Worker-Caching, da beim HTTP-Caching nur die zeitbasierte (TTL) Logik für das Ablaufen von Ressourcen verwendet wird. Weitere Informationen zu HTTP-Caching-Strategien finden Sie unter Welche Antwortheader-Werte sollten Sie verwenden? und Zusammenfassung.

Logik für den Cache-Ablauf entwerfen

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

Der folgende Glitch zeigt, wie Service Worker-Caching und HTTP-Caching in verschiedenen Szenarien funktionieren:

Einheitliche Ablauflogik für alle Cacheebenen

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

Szenario: Langzeit-Caching (Cache, Rückfall 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 über das Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache. Daher wird die Ressource serverseitig abgerufen.

Nachteil: In diesem Szenario bietet das HTTP-Caching weniger Vorteile, da der Browser die Anfrage immer an die Serverseite 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 aus dem Netzwerk ab. Der Browser hat eine Kopie der Ressource in seinem HTTP-Cache und gibt diese Kopie an den Service Worker zurück.
• Wenn eine im Cache gespeicherte Ressource abgelaufen ist (länger als 1 Tag): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource aus dem Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache. Daher wird die Ressource serverseitig abgerufen.

Nachteil: Der Dienst-Worker erfordert zusätzliche Cache-Busting-Vorgänge, um den HTTP-Cache zu überschreiben und den Schritt „Neu bestätigen“ optimal zu nutzen.

Szenario: Kurzfristiges Caching (Netzwerk greift auf den Cache zurück)

• Wenn eine im Cache gespeicherte Ressource gültig ist (<= 10 Minuten): Der Service Worker ruft das Netzwerk ab, um die Ressource abzurufen. Der Browser hat eine Kopie der Ressource in seinem HTTP-Cache und gibt sie an den Service Worker zurück, ohne serverseitig zu gehen.
• Wenn eine im Cache gespeicherte Ressource abgelaufen ist (mehr als 10 Minuten): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource aus dem Netzwerk ab. Im Browser befindet sich keine Kopie der Ressource in seinem HTTP-Cache. Daher wird die Ressource serverseitig abgerufen.

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

Dienst-Worker in allen Szenarien

In allen Fällen kann der Service Worker-Cache auch dann gecachte Ressourcen zurückgeben, wenn das Netzwerk instabil ist. Andererseits ist der HTTP-Cache nicht zuverlässig, wenn das Netzwerk instabil ist oder ausgefallen ist.

Unterschiedliche Cache-Ablauflogik in der Service Worker-Cache- und HTTP-Ebene

Zur Veranschaulichung der Vor- und Nachteile betrachten wir noch einmal langfristige, mittel- und kurzfristige Szenarien.

Szenario: Langzeit-Caching (Cache, Rückfall auf Netzwerk)

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

Vor- und Nachteile:

• Vorteil: Nutzer erhalten eine sofortige Antwort, da der Service Worker zwischengespeicherte Ressourcen sofort zurückgibt.
• Vorteil: Der Service Worker kann genauer steuern, wann sein Cache verwendet und wann neue Versionen von Ressourcen angefordert werden sollen.
• Nachteil: Eine gut definierte Caching-Strategie für Service Worker ist erforderlich.

Szenario: Mittelfristiges Caching (Stale-while-revalidate)

• Wenn eine im Cache gespeicherte Ressource im Cache des Service-Workers 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 (länger als 30 Tage): Der Service Worker ruft die Ressource aus dem Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache, daher wird sie serverseitig abgerufen.

Vor- und Nachteile:

• Vorteil: Nutzer erhalten eine sofortige Antwort, da der Service Worker zwischengespeicherte Ressourcen sofort zurückgibt.
• Vorteil: Der Dienst-Worker kann dafür sorgen, dass für die nächste Anfrage für eine bestimmte URL eine neue Antwort vom Netzwerk verwendet wird, da die erneute Validierung „im Hintergrund“ erfolgt.
• Nachteil: Eine klar definierte Caching-Strategie für Service Worker ist erforderlich.

Szenario: Kurzfristiges Caching (Netzwerk greift auf Cache zurück)

• Wenn eine im Cache des Dienstarbeiters gespeicherte Ressource gültig ist (< 1 Tag): Der Dienstarbeiter ruft die Ressource im Netzwerk ab. Der Browser gibt die Ressource aus dem HTTP-Cache zurück, sofern sie sich dort befindet. Wenn das Netzwerk ausgefallen ist, gibt der Service Worker die Ressource aus dem Service Worker-Cache zurück.
• Wenn eine im Cache gespeicherte Ressource im Cache des Service-Workers abgelaufen ist (> 1 Tag): Der Service-Worker ruft das Netzwerk ab, um die Ressource abzurufen. 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 ist oder ausfällt, gibt der Service Worker sofort zwischengespeicherte Ressourcen zurück.
• Nachteil: Der Service Worker benötigt zusätzliches Cache-Busting, um den HTTP-Cache zu überschreiben und "Network first"-Anfragen zu stellen.

Fazit

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

• Die Cache-Logik von Service Workern muss nicht mit der Ablauflogik des HTTP-Cachings übereinstimmen. Verwenden Sie im Service Worker nach Möglichkeit eine längere Ablauflogik, um ihm mehr Kontrolle zu gewähren.
• Das HTTP-Caching spielt immer noch eine wichtige Rolle, ist aber nicht zuverlässig, wenn das Netzwerk instabil ist oder ausfällt.
• Überprüfen Sie Ihre Caching-Strategien für jede Ressource, um sicherzustellen, dass die Caching-Strategie des Service Workers einen Mehrwert bietet, ohne mit dem HTTP-Cache in Konflikt zu stehen.

Weitere Informationen

• Netzwerkzuverlässigkeit
• Unnötige Netzwerkanfragen mit dem HTTP-Cache verhindern
• HTTP-Cache-Codelab
• Die Auswirkungen von Service Workern auf die Leistung in der Praxis messen
• Cache-Control im Vergleich zu „Expires“
• Caching – einfach erklärt: Caches prüfen, leeren und deaktivieren