Die Vor- und Nachteile einer einheitlichen oder unterschiedlichen Ablauflogik für den Service Worker-Cache und die HTTP-Cache-Ebenen
Während Service Worker und PWAs zu Standards moderner Webanwendungen werden, ist das Ressourcen-Caching komplexer als je zuvor. In diesem Artikel werden die wichtigsten Aspekte des Browser-Cachings behandelt:
- Anwendungsfälle und Unterschiede zwischen Service Worker-Caching und HTTP-Caching
- Die Vor- und Nachteile der verschiedenen Ablaufstrategien für das Caching von Service Workern im Vergleich zu herkömmlichen HTTP-Caching-Strategien
Übersicht über den Caching-Ablauf
Auf übergeordneter Ebene folgt ein Browser bei der Anforderung einer Ressource der folgenden Caching-Reihenfolge:
- 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 wird. Dies geschieht nicht automatisch. Sie müssen in Ihrem Service Worker einen Abruf-Event-Handler erstellen und Netzwerkanfragen so abfangen, dass die Anfragen aus dem Cache des Service-Workers und nicht aus dem Netzwerk bereitgestellt werden.
- HTTP-Cache (auch Browser-Cache genannt): Wenn sich die Ressource im HTTP-Cache befindet und noch nicht abgelaufen ist, verwendet der Browser die Ressource automatisch aus dem HTTP-Cache.
- 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ückgeschickt werden.
Caching-Schichten
Service Worker-Caching
Ein Service Worker fängt HTTP-Anfragen vom Typ „Netzwerk“ ab und ermittelt 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 er bietet mehr Caching-Funktionen, z. B. eine genaue 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 (in der Regel das Ereignis fetch). 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. Beispielsweise können Sie Ressourcen-URL-Pfade mit einer einzigen Zeile Regex-Code registrieren.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Service Worker-Caching-Strategien und -Anwendungsfälle
In der nächsten Tabelle werden gängige Caching-Strategien für Service Worker erläutert und es wird erläutert, wann die jeweilige Strategie nützlich ist.
| Strategien | Gründe für die Aktualität | Anwendungsfälle |
|---|---|---|
| Nur Netzwerk | Die Inhalte müssen immer auf dem neuesten Stand sein. |
|
| Netzwerk-Fallback auf den Cache | Wir empfehlen, immer die aktuellen Inhalte bereitzustellen. Wenn das Netzwerk jedoch ausfällt oder instabil ist, können etwas alte Inhalte bereitgestellt werden. |
|
| Stale-while-revalidator | Inhalte im Cache können sofort bereitgestellt werden, aber aktualisierte im Cache gespeicherte Inhalte sollten zu einem späteren Zeitpunkt verwendet werden. |
|
| Zuerst im Cache speichern, auf Netzwerk zurücksetzen | Der Inhalt ist nicht kritisch 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-Cachings
Neben der fein abgestimmten 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. Mit anderen Worten: Wenn Sie mehrere Subdomains haben, nutzen alle denselben HTTP-Cache. Es gibt keine Garantie, dass der Inhalt Ihres Ursprungs/Ihrer Domain längere Zeit im HTTP-Cache verbleibt. Beispielsweise kann ein Nutzer den Cache leeren, indem er die Daten manuell über die Benutzeroberfläche eines Browsers bereinigt oder eine Seite vollständig neu lädt. Mit einem Service Worker-Cache ist die Wahrscheinlichkeit höher, dass Ihre im Cache gespeicherten Inhalte im Cache gespeichert bleiben. Weitere Informationen finden Sie unter Nichtflüchtiger Speicher.
- Mehr Flexibilität bei unzuverlässigen Netzwerken oder Offlinefunktionen:Mit dem HTTP-Cache haben Sie nur die Wahl zwischen zwei Binärprogrammen: Entweder wird die Ressource im Cache gespeichert oder nicht. Mit dem Service Worker-Caching können Sie kleine "Probleme" viel einfacher abschwächen (mit der Strategie "Veraltet" und mit der Strategie "Nur Cache") oder auch Elemente dazwischen bieten, z. B. benutzerdefinierte UIs, bei denen Teile der Seite aus dem Service Worker-Cache stammen und einige Teile ausgeschlossen werden (mit der Strategie "Catchall-Handler festlegen").
HTTP-Caching
Wenn ein Browser zum ersten Mal eine Webseite und zugehörige Ressourcen lädt, werden diese Ressourcen im HTTP-Cache gespeichert. Der HTTP-Cache wird normalerweise automatisch von Browsern aktiviert, sofern er nicht explizit vom Endnutzer deaktiviert wurde.
Beim HTTP-Caching wird der Server selbst bestimmen, wann und wie lange eine Ressource im Cache gespeichert werden soll.
Ablauf des HTTP-Cache mit HTTP-Antwortheadern steuern
Wenn ein Server auf eine Browseranfrage für eine Ressource antwortet, teilt er dem Browser mithilfe von HTTP-Antwortheadern mit, wie lange die Ressource im Cache gespeichert werden 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 HTTP-Caching sich nur mit zeitbasierter (TTL)-Ressourcenablauflogik befasst. Weitere Informationen zu HTTP-Caching-Strategien finden Sie unter Welche Antwortheaderwerte sollten Sie verwenden? und Zusammenfassung.
Cache-Ablauflogik entwerfen
In diesem Abschnitt werden die Vor- und Nachteile der Verwendung einer konsistenten Ablauflogik auf den Ebenen des Service Worker-Cache und des HTTP-Cache sowie die Vor- und Nachteile einer separaten Ablauflogik auf diesen Ebenen erläutert.
Der folgende Glitch zeigt, wie das Service-Worker-Caching und das HTTP-Caching in verschiedenen Szenarien in Aktion funktionieren:
Einheitliche Ablauflogik für alle Cache-Ebenen
Um die Vor- und Nachteile aufzuzeigen, sehen wir uns drei Szenarien an: langfristige, mittelfristige und kurzfristige.
| Szenarien | Langzeit-Caching | Mittelfristiges Caching | Kurzfristiges Caching |
|---|---|---|---|
| Service Worker-Caching-Strategie | Cache, Fallback auf Netzwerk | Veraltet bei Neuvalidierung | Netzwerk-Fallback auf Cache |
| Service Worker-Cache-TTL | 30 Tage | 1 Tag | 10 Min. |
| HTTP-Cache-Höchstalter | 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 an das Netzwerk zu gehen.
- Wenn eine im Cache gespeicherte Ressource abgelaufen ist (mehr als 30 Tage): Der Service Worker ruft die Ressource über das Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache und ruft die Ressource serverseitig ab.
Nachteil: In diesem Szenario liefert das HTTP-Caching weniger Wert, da der Browser die Anfrage immer an die Serverseite weiterleitet, wenn der Cache im Service Worker abläuft.
Szenario: Mittelfristiges Caching (Stale-while-revalid)
- 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 daher an den Service Worker zurück.
- Wenn eine im Cache gespeicherte Ressource abgelaufen ist (mehr als 1 Tag), gibt der Service Worker die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource über das Netzwerk ab. Der Browser hat keine Kopie der Ressource im HTTP-Cache und ruft die Ressource daher serverseitig ab.
Nachteil: Der Service Worker benötigt zusätzliches Cache-Busting, um den HTTP-Cache zu überschreiben, um den Schritt "Neu validieren" 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 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 die Seite serverseitig zu verwenden.
- Wenn eine im Cache gespeicherte Ressource abgelaufen ist (> 10 Minuten), gibt der Service Worker 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 und ruft die Ressource daher serverseitig ab.
Con: Ähnlich wie beim mittelfristigen Caching-Szenario benötigt 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
Wenn das Netzwerk instabil ist, kann der Service-Worker-Cache in allen Fällen im Cache gespeicherte Ressourcen zurückgeben. Andererseits ist der HTTP-Cache nicht zuverlässig, wenn das Netzwerk instabil oder ausgefallen ist.
Unterschiedliche Cache-Ablauflogik im Service Worker-Cache und auf HTTP-Ebenen
Um die Vor- und Nachteile aufzuzeigen, sehen wir uns wieder langfristige, mittelfristige und kurzfristige Szenarien an.
| Szenarien | Langzeit-Caching | Mittelfristiges Caching | Kurzfristiges Caching |
|---|---|---|---|
| Service Worker-Caching-Strategie | Cache, Fallback auf Netzwerk | Veraltet bei Neuvalidierung | Netzwerk-Fallback auf Cache |
| Service Worker-Cache-TTL | 90 Tage | 30 Tage | 1 Tag |
| HTTP-Cache-Höchstalter | 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 (mehr als 90 Tage): Der Service-Worker ruft die Ressource über das Netzwerk ab. Der Browser hat keine Kopie der Ressource im HTTP-Cache und arbeitet daher serverseitig.
Vor- und Nachteile:
- Pro: Nutzer erhalten sofort eine Antwort, wenn der Service Worker im Cache gespeicherte Ressourcen sofort zurückgibt.
- Pro: Der Service Worker kann genauer steuern, wann sein Cache verwendet und wann neue Ressourcenversionen angefordert werden sollen.
- Nachteil: Eine genau definierte Service-Worker-Caching-Strategie ist erforderlich.
Szenario: Zwischenfristiges Caching (Stale-while-revalid)
- 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 (mehr als 30 Tage): Der Service-Worker sucht im Netzwerk nach der Ressource. Der Browser hat keine Kopie der Ressource im HTTP-Cache und wird serverseitig ausgeführt.
Vor- und Nachteile:
- Pro: Nutzer erhalten sofort eine Antwort, wenn der Service Worker im Cache gespeicherte Ressourcen sofort zurückgibt.
- Pro: Dank der erneuten Validierung, die „im Hintergrund“ erfolgt, kann der Service Worker dafür sorgen, dass die nächste Anfrage für eine bestimmte URL eine neue Antwort aus dem Netzwerk verwendet.
- Nachteil: Eine genau definierte Service-Worker-Caching-Strategie ist erforderlich.
Szenario: Kurzfristiges Caching (Netzwerk greift auf den Cache zurück)
- Wenn eine im Cache gespeicherte Ressource im Service-Worker-Cache gültig ist (<= 1 Tag): Der Service-Worker sucht im Netzwerk nach der Ressource. Der Browser gibt die Ressource aus dem HTTP-Cache zurück, falls sie 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), ruft der Service-Worker 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:
- Pro: Wenn das Netzwerk instabil oder ausgefallen ist, gibt der Service Worker im Cache gespeicherte Ressourcen sofort zurück.
- Nachteil: Der Service Worker benötigt zusätzliches Cache-Busting, um den HTTP-Cache zu überschreiben und Anfragen des Typs „Netzwerk zuerst“ zu senden.
Fazit
Angesichts der Komplexität der Kombination von Caching-Szenarien ist es nicht möglich, eine Regel zu entwickeln, 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 für das HTTP-Caching übereinstimmen. Verwenden Sie nach Möglichkeit eine Logik für eine längere Ablaufzeit im Service Worker, um dem Service Worker mehr Kontrolle zu geben.
- HTTP-Caching spielt immer noch eine wichtige Rolle, ist jedoch 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 Nutzen liefert, ohne mit dem HTTP-Cache in Konflikt zu stehen.