Laufzeit-Caching bezieht sich auf das schrittweise Hinzufügen von Antworten zu einem Cache. Das Laufzeit-Caching wirkt sich zwar nicht auf die Zuverlässigkeit der aktuellen Anfrage aus, kann aber dazu beitragen, zukünftige Anfragen für dieselbe URL zuverlässiger zu machen.
Der HTTP-Cache des Browsers ist ein Beispiel für das Laufzeit-Caching. Er wird erst nach einer Anfrage für eine bestimmte URL mit Daten gefüllt. Mit Service Workern können Sie jedoch Laufzeit-Caching implementieren, das über die Möglichkeiten des HTTP-Cache hinausgeht.
Strategische Nutzung
Im Gegensatz zum Precaching, bei dem immer versucht wird, eine Reihe vordefinierter Dateien aus einem Cache bereitzustellen, kann beim Laufzeit-Caching der Netzwerk- und Cachezugriff auf mehrere Arten kombiniert werden. Jede Kombination wird im Allgemeinen als Caching-Strategie bezeichnet. Zu den wichtigsten Caching-Strategien gehören:
- Network-First
- Cache-First
- Veraltet bei Neuvalidierung
Network-First
Bei diesem Ansatz versucht der Service Worker zuerst, eine Antwort vom Netzwerk abzurufen. Wenn die Netzwerkanfrage erfolgreich ist, Die Antwort wird an Ihre Webanwendung zurückgegeben und mithilfe der Cache Storage API eine Kopie der Antwort gespeichert. Dabei wird entweder ein neuer Eintrag erstellt oder ein vorheriger Eintrag für dieselbe URL aktualisiert.
Wenn die Netzwerkanfrage vollständig fehlschlägt oder es zu lange dauert, bis eine Antwort zurückgegeben wird, wird stattdessen die letzte Antwort aus dem Cache zurückgegeben.
Cache-First
Eine Cache-First-Strategie ist genau das Gegenteil von Network-First-Strategie. Wenn Ihr Service Worker eine Anfrage abfängt, prüft er bei dieser Methode zuerst mit der Cache Storage API, ob eine im Cache gespeicherte Antwort verfügbar ist. Ist dies der Fall, wird diese Antwort an die Webanwendung zurückgegeben.
Wenn jedoch ein Cache-Fehler auftritt, geht der Service Worker zum Netzwerk und versucht, dort eine Antwort abzurufen. Bei einer erfolgreichen Netzwerkanfrage wird sie an die Webanwendung zurückgegeben und in einem Cache eine Kopie gespeichert. Diese im Cache gespeicherte Kopie wird verwendet, um das Netzwerk zu umgehen, wenn das nächste Mal eine Anfrage für dieselben URLs gestellt wird.
Veraltet bei Neuvalidierung
„Veraltet“ bei der Neuvalidierung ist etwas wie eine Hybridform. Der Service-Worker sucht dann sofort nach einer im Cache gespeicherten Antwort und übergibt sie gegebenenfalls an die Webanwendung.
In der Zwischenzeit löst Ihr Service Worker auch eine Netzwerkanfrage aus, um eine "neue" Antwort zu erhalten, unabhängig davon, ob eine Cache-Übereinstimmung vorliegt. Diese Antwort wird verwendet, um alle zuvor im Cache gespeicherten Antworten zu aktualisieren. Wenn die erste Cache-Prüfung ein Fehler war, wird auch eine Kopie der Netzwerkantwort an die Webanwendung zurückgegeben.
Warum sollte ich Workbox verwenden?
Diese Caching-Strategien gehen auf Schemas zurück, die Sie normalerweise immer wieder in Ihrem eigenen Service Worker neu schreiben müssten. Anstatt darauf zurückzugreifen, bietet Workbox sie als Teil der Strategiebibliothek an, sodass Sie bei Ihrem Service Worker nachsehen können.
Workbox unterstützt auch die Versionsverwaltung, sodass Sie im Cache gespeicherte Einträge automatisch ablaufen oder Ihre Webanwendung benachrichtigen können, wenn Updates für einen zuvor im Cache gespeicherten Eintrag vorgenommen werden.
Welche Assets sollten im Cache gespeichert werden – mit welchen Strategien?
Das Laufzeit-Caching kann als Ergänzung zum Precaching betrachtet werden. Wenn alle Assets bereits vorab im Cache gespeichert werden, sind Sie fertig. Während der Laufzeit muss nichts im Cache gespeichert werden. Wahrscheinlich werden Sie jedoch bei einer relativ komplexen Webanwendung nicht alles vorab im Cache speichern.
Größere Mediendateien, API-Antworten, die von einem Drittanbieterhost wie einem CDN bereitgestellt werden, oder API-Antworten sind nur einige Beispiele für Arten von Assets, die nicht effektiv vorab im Cache gespeichert werden können. Verwenden Sie den Bereich „Netzwerk“ in den Entwicklertools, um Anfragen in diese Kategorie zu identifizieren, und überlegen Sie für jede davon, wie Aktualität und Zuverlässigkeit angemessen sind.
Mit der Option „Veraltete Zeit während der erneuten Validierung“ wird Zuverlässigkeit Vorrang vor Aktualität gegeben
Da bei einer Strategie vom Typ „Veraltet“ eine im Cache gespeicherte Antwort nahezu sofort zurückgegeben wird – nachdem der Cache über die erste Anfrage gefüllt wurde –, können Sie mit dieser Strategie eine zuverlässig schnelle Leistung erzielen. Dabei müssen Antwortdaten zurückgegeben werden, die im Vergleich zu den Daten, die aus dem Netzwerk abgerufen worden wären, möglicherweise veraltet sind. Diese Strategie eignet sich am besten für Assets wie Nutzerprofilbilder oder die ersten API-Antworten, mit denen eine Ansicht ausgefüllt wird, wenn bekannt ist, dass etwas sofort angezeigt werden muss, auch wenn es sich um einen älteren Wert handelt.
Aktualität gegenüber Zuverlässigkeit priorisieren
In gewisser Weise bedeutet eine netzwerkorientierte Strategie, sich im Kampf gegen das Netzwerk zu besiegen – sie hat Priorität, aber das bringt Unsicherheit in Bezug auf die Zuverlässigkeit mit sich. Bei bestimmten Asset-Typen ist eine aktuelle Antwort besser, als wenn veraltete Informationen zurückgegeben werden. Unter Umständen bevorzugen Sie die Aktualität beispielsweise, wenn Sie eine API-Anfrage für den Text eines Artikels senden, der häufig aktualisiert wird.
Wenn Sie eine netzwerkorientierte Strategie innerhalb eines Service Workers einsetzen, anstatt sich nur direkt auf das Netzwerk zu wenden, haben Sie den Vorteil, dass Sie auf etwas zurückgreifen können, auch wenn es sich um eine potenziell veraltete Antwort handelt. Sie werden zwar nicht zuverlässig sein, aber wenigstens werden Sie offline zuverlässig sein.
Cache-First für versionierte URLs verwenden
Bei einer Cache-First-Strategie wird ein Eintrag, der im Cache gespeichert ist, nie aktualisiert. Verwenden Sie sie daher nur für Assets, von denen Sie wissen, dass sie sich wahrscheinlich nicht ändern werden. Sie funktioniert am besten bei URLs, die Versionsinformationen enthalten, also bei URLs, die auch mit einem Cache-Control: max-age=31536000-Antwortheader bereitgestellt werden sollten.