Die Vor- und Nachteile der Verwendung einer einheitlichen oder unterschiedlichen Ablauflogik für den Service Worker-Cache und den HTTP-Cache.
Service Worker und PWAs werden zwar zu Standards moderner Webanwendungen, das Ressourcen-Caching ist jedoch komplexer denn je. In diesem Artikel wird das Browser-Caching im Allgemeinen behandelt, einschließlich:
- Anwendungsfälle und Unterschiede zwischen Service Worker-Caching und HTTP-Caching
- Die Vor- und Nachteile verschiedener Ablaufstrategien für das Caching von Service Workern im Vergleich zu regulären HTTP-Caching-Strategien.
Übersicht über den Caching-Ablauf
Wenn ein Browser eine Ressource anfordert, folgt er im Wesentlichen der folgenden Caching-Reihenfolge:
- 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ückgibt. Beachten Sie, dass dies nicht automatisch geschieht. Sie müssen einen Fetch-Ereignis-Handler in Ihrem Service Worker erstellen und Netzwerkanfragen abfangen, damit die Anfragen aus dem Cache des Service Workers und nicht aus dem Netzwerk bedient werden.
- HTTP-Cache (auch als Browser-Cache bezeichnet): Wenn die Ressource im HTTP-Cache gefunden wird und noch nicht abgelaufen ist, verwendet der Browser automatisch die Ressource aus dem HTTP-Cache.
- Serverseitig: Wenn im Service Worker-Cache oder im HTTP-Cache nichts gefunden wird, fordert der Browser die Ressource über das Netzwerk an. Wenn die Ressource nicht in einem CDN im Cache gespeichert ist, muss die Anfrage bis zum Ursprungsserver zurückgehen.
Caching-Ebenen
Caching durch Service Worker
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, 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 erfolgt.
Service Worker-Cache steuern
Ein Service Worker fängt HTTP-Anfragen mit Event-Listenern ab (normalerweise das fetch-Ereignis). Dieses Code-Snippet veranschaulicht die Logik einer Cache-First-Caching-Strategie.
Es wird dringend empfohlen, Workbox zu verwenden, um das Rad nicht neu zu erfinden. 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);
Caching-Strategien und Anwendungsfälle für Service Worker
In der folgenden Tabelle sind gängige Caching-Strategien für Service Worker aufgeführt und es wird beschrieben, wann die einzelnen Strategien nützlich sind.
| Strategien | Begründung für die Aktualität | Anwendungsbeispiele |
|---|---|---|
| Nur Netzwerk | Die Inhalte müssen immer auf dem neuesten Stand sein. |
|
| Netzwerk greift auf Cache zurück | Es ist besser, die neuen Inhalte bereitzustellen. Wenn das Netzwerk jedoch ausfällt oder instabil ist, ist es akzeptabel, leicht veraltete Inhalte bereitzustellen. |
|
| Stale-while-revalidate | Es ist in Ordnung, zwischengespeicherte Inhalte sofort bereitzustellen, aber in Zukunft sollten aktualisierte zwischengespeicherte Inhalte verwendet werden. |
|
| Zuerst Cache, dann Netzwerk | Der Inhalt ist unkritisch und kann zur Leistungssteigerung aus dem Cache bereitgestellt werden. Der Service Worker sollte jedoch gelegentlich nach Updates suchen. |
|
| Nur Cache | Der Inhalt ändert sich selten. |
|
Zusätzliche Vorteile des Service Worker-Caching
Neben der detaillierten Steuerung der Caching-Logik bietet das Caching von Service Workern 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, nutzen diese alle denselben HTTP-Cache. Es gibt keine Garantie dafür, dass der Inhalt Ihres Ursprungs/Ihrer Domain lange im HTTP-Cache verbleibt. Ein Nutzer kann den Cache beispielsweise manuell über die Einstellungen des Browsers leeren oder eine Seite neu laden. Mit einem Service Worker-Cache ist die Wahrscheinlichkeit, dass Ihre im Cache gespeicherten Inhalte im Cache bleiben, viel höher. Weitere Informationen finden Sie unter Nichtflüchtiger Speicher.
- Höhere Flexibilität bei instabilen Netzwerken oder Offline-Nutzung: Beim HTTP-Cache gibt es nur zwei Möglichkeiten: Entweder wird die Ressource im Cache gespeichert oder nicht. Mit dem Service Worker-Caching können Sie kleine „Schluckaufs“ viel einfacher beheben (mit der „stale-while-revalidate“-Strategie), eine vollständige Offline-Erfahrung anbieten (mit der „Cache only“-Strategie) oder sogar etwas dazwischen, wie benutzerdefinierte Benutzeroberflächen, bei denen Teile der Seite aus dem Service Worker-Cache stammen und einige Teile ausgeschlossen sind (mit der „Set catch handler“-Strategie), wo dies angebracht ist.
HTTP-Caching
Wenn ein Browser eine Webseite und zugehörige Ressourcen zum ersten Mal lädt, speichert er diese Ressourcen in seinem HTTP-Cache. Der HTTP-Cache wird von Browsern in der Regel automatisch aktiviert, sofern er nicht explizit vom Endnutzer deaktiviert wurde.
Beim HTTP-Caching wird der Server verwendet, um zu bestimmen, wann und wie lange eine Ressource im Cache gespeichert werden soll.
HTTP-Cache-Ablauf mit HTTP-Antwortheadern steuern
Wenn ein Server auf eine Browseranfrage für eine 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 sich nur mit der zeitbasierten (TTL) Logik für den Ablauf von Ressourcen befasst. Weitere Informationen zu HTTP-Caching-Strategien finden Sie unter Welche Antwortheaderwerte sollten Sie verwenden? und Unnötige Netzwerkanfragen mit dem HTTP-Cache verhindern (Zusammenfassung).
Logik für den Cache-Ablauf entwerfen
In diesem Abschnitt werden die Vor- und Nachteile der Verwendung einer einheitlichen Ablauflogik für den Service Worker-Cache und den HTTP-Cache sowie die Vor- und Nachteile einer separaten Ablauflogik für diese Ebenen erläutert.
Konsistente Ablauflogik für alle Cache-Ebenen
Um die Vor- und Nachteile zu veranschaulichen, sehen wir uns drei Szenarien an: langfristig, mittelfristig und kurzfristig.
| Szenarien | Langfristiges Caching | Mittelfristiges Caching | Kurzfristiges Caching |
|---|---|---|---|
| Caching-Strategie für Service Worker | Cache, Fallback auf Netzwerk | Stale-while-revalidate | Netzwerk greift auf Cache zurück |
| TTL des Service Worker-Cache | 30 Tage | 1 Tag | 10 Min. |
| HTTP-Cache-max-age | 30 Tage | 1 Tag | 10 Min. |
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 kontaktieren.
- 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, also sucht er serverseitig nach der Ressource.
Nachteil: In diesem Szenario bietet 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 über das 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 (> 1 Tag): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource über das Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache, also ruft er die Ressource serverseitig ab.
Nachteil: Der Service Worker erfordert zusätzliches Cache-Busting, um den HTTP-Cache zu überschreiben und den Schritt „revalidate“ optimal zu nutzen.
Szenario: Kurzfristiges Caching (Netzwerk greift auf Cache zurück)
- Wenn eine im Cache gespeicherte Ressource gültig ist (≤ 10 Minuten): Der Service Worker ruft die Ressource über das 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 gehen.
- 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 über das Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache, also ruft er die Ressource serverseitig ab.
Nachteil: Ähnlich wie beim Szenario mit mittelfristigem 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 jedoch nicht zuverlässig, wenn das Netzwerk instabil oder ausgefallen ist.
Unterschiedliche Cache-Ablauflogik auf der Service Worker-Cache- und HTTP-Ebene
Um die Vor- und Nachteile zu veranschaulichen, betrachten wir wieder langfristige, mittelfristige und kurzfristige Szenarien.
| Szenarien | Langfristiges Caching | Mittelfristiges Caching | Kurzfristiges Caching |
|---|---|---|---|
| Caching-Strategie für Service Worker | Cache, Fallback auf Netzwerk | Stale-while-revalidate | Netzwerk greift auf Cache zurück |
| TTL des Service Worker-Cache | 90 Tage | 30 Tage | 1 Tag |
| HTTP-Cache-max-age | 30 Tage | 1 Tag | 10 Min. |
Szenario: Langfristiges Caching (Cache, Fallback auf Netzwerk)
- Wenn eine im Cache gespeicherte Ressource im Service Worker-Cache gültig ist (<= 90 Tage): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück.
- Wenn eine im Cache gespeicherte Ressource im Service Worker-Cache abgelaufen ist (> 90 Tage): Der Service Worker ruft die Ressource über das Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache, also wird sie 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 genauere Kontrolle darüber, wann er seinen Cache verwenden und wann er neue Versionen von Ressourcen anfordern soll.
- Nachteil: Es ist eine klar definierte Caching-Strategie für Service Worker erforderlich.
Szenario: Mittelfristiges Caching (stale-while-revalidate)
- Wenn eine im Cache gespeicherte Ressource im Service Worker-Cache gültig ist (<= 30 Tage): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück.
- Wenn eine im Cache gespeicherte Ressource im Service Worker-Cache 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, also wird sie 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 die nächste Anfrage für eine bestimmte URL eine aktuelle Antwort aus dem Netzwerk verwendet, da die erneute Validierung „im Hintergrund“ erfolgt.
- Nachteil: Es ist eine klar definierte Caching-Strategie für Service Worker erforderlich.
Szenario: Kurzfristiges Caching (Netzwerk greift auf Cache zurück)
- Wenn eine im Cache gespeicherte Ressource im Service Worker-Cache gültig ist (<= 1 Tag): Der Service Worker ruft die Ressource über das Netzwerk ab. Der Browser gibt die Ressource aus dem HTTP-Cache zurück, falls 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 Cache gespeicherte Ressource im Service Worker-Cache abgelaufen ist (> 1 Tag): Der Service Worker ruft die Ressource über das 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 sofort im Cache gespeicherte Ressourcen 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 du beim Entwerfen deiner Cache-Strategien berücksichtigen solltest:
- Die Caching-Logik des Service Workers muss nicht mit der HTTP-Caching-Ablauflogik übereinstimmen. Verwenden Sie nach Möglichkeit eine längere Ablauflogik im Service Worker, um dem Service Worker mehr Kontrolle zu geben.
- HTTP-Caching spielt immer noch 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 die Caching-Strategie Ihres Service Workers einen Mehrwert bietet, ohne mit dem HTTP-Cache in Konflikt zu geraten.