Service Worker und die Cache Storage API

Jeff Posnick

Sie müssen die Netzwerkzuverlässigkeit beeinträchtigen. Der HTTP-Cache des Browsers ist Ihre erste Verteidigungslinie, aber wie Sie gelernt haben, ist er nur dann effektiv, wenn Sie versionierte URLs laden, die Sie zuvor aufgerufen haben. Der HTTP-Cache alleine reicht nicht aus.

Glücklicherweise sind zwei neuere Tools verfügbar, um das Blatt zu Ihren Gunsten zu wenden: Service Worker und die Cache Storage API. Da sie so oft zusammen verwendet werden, lohnt es sich, sie gleichzeitig kennenzulernen.

Service Worker

Ein Service Worker ist in den Browser integriert und wird durch zusätzlichen JavaScript-Code gesteuert, für dessen Erstellung Sie verantwortlich sind. Sie stellen diese zusammen mit den anderen Dateien bereit, aus denen Ihre Webanwendung besteht.

Ein Service Worker hat einige besondere Fähigkeiten. Unter anderem wartet es geduldig, bis Ihre Webanwendung eine ausgehende Anfrage sendet, und fängt dann die Anfrage ab. Was der Service Worker mit dieser abgefangenen Anfrage macht, können Sie selbst entscheiden.

Bei einigen Anfragen könnte die beste Vorgehensweise darin bestehen, die Anfrage im Netzwerk weiterzuführen, genau wie wenn es keinen Service Worker gäbe.

Bei anderen Anfragen können Sie jedoch einen flexibleren Ansatz als den HTTP-Cache des Browsers nutzen und eine zuverlässig schnelle Antwort zurückgeben, ohne sich um das Netzwerk kümmern zu müssen. Dazu müssen Sie das andere Puzzleteil nutzen: die Cache Storage API.

Die Cache Storage API

Die Cache Storage API eröffnet ganz neue Möglichkeiten, da Entwickler die vollständige Kontrolle über den Inhalt des Cache haben. Anstatt sich auf eine Kombination aus HTTP-Headern und der integrierten heuristics des Browsers zu verlassen, bietet die Cache Storage API einen codebasierten Caching-Ansatz. Die Cache Storage API ist besonders nützlich, wenn sie über den JavaScript-Code Ihres Service Workers aufgerufen wird.

Moment mal... es gibt einen anderen Cache, den Sie bedenken sollten?

Sie stellen sich wahrscheinlich Fragen wie „Muss ich meine HTTP-Header noch konfigurieren?“ und „Was kann ich mit diesem neuen Cache tun, was mit dem HTTP-Cache nicht möglich war?“ Keine Sorge – das sind ganz natürliche Reaktionen.

Es wird weiterhin empfohlen, die Cache-Control-Header auf Ihrem Webserver zu konfigurieren, auch wenn Sie wissen, dass Sie die Cache Storage API verwenden. In der Regel können Sie damit Cache-Control: no-cache für nicht versionierte URLs und/oder Cache-Control: max-age=31536000 für URLs festlegen, die Versionsinformationen wie Hashes enthalten.

Wenn der Cache Storage API-Cache gefüllt wird, sucht der Browser standardmäßig nach vorhandenen Einträgen im HTTP-Cache und verwendet diese, falls sie gefunden werden. Wenn Sie versionierte URLs dem Cache Storage API-Cache hinzufügen, vermeidet der Browser eine zusätzliche Netzwerkanfrage. Wenn Sie falsch konfigurierte Cache-Control-Header verwenden, wie z. B. die Angabe einer langlebigen Cache-Lebensdauer für eine nicht versionierte URL, können Sie den Vorgang verschlimmern, wenn Sie der Cache Storage API den veralteten Inhalt hinzufügen. Eine Sortierung des HTTP-Cache-Verhaltens ist eine Voraussetzung für die effektive Verwendung der Cache Storage API.

Was jetzt mit dieser neuen API möglich ist, lautet die Antwort: viel. Hier einige häufige Anwendungsfälle, die allein mit dem HTTP-Cache schwierig oder unmöglich wären:

• Nutzen Sie den Ansatz „Im Hintergrund aktualisieren“ für im Cache gespeicherte Inhalte, der als „Veraltet“ während der erneuten Validierung bezeichnet wird.
• Legen Sie eine Obergrenze für die maximale Anzahl von Assets fest, die im Cache gespeichert werden sollen, und implementieren Sie eine benutzerdefinierte Ablaufrichtlinie, um Elemente zu entfernen, sobald dieses Limit erreicht ist.
• Vergleichen Sie zuvor im Cache gespeicherte und aktuelle Netzwerkantworten, um festzustellen, ob sich etwas geändert hat. Ermöglichen Sie dem Nutzer dann, Inhalte (z. B. über eine Schaltfläche) zu aktualisieren, wenn Daten tatsächlich aktualisiert wurden.

Weitere Informationen finden Sie unter Cache API: Eine Kurzanleitung.

Tipps für APIs

Beim Design der API sind einige Dinge zu beachten:

• Request-Objekte werden beim Lesen und Schreiben in diesen Caches als eindeutige Schlüssel verwendet. Der Einfachheit halber können Sie anstelle eines tatsächlichen Request-Objekts einen URL-String wie 'https://example.com/index.html' als Schlüssel übergeben. Die API übernimmt das automatisch für Sie.
• In diesen Caches werden als Werte Response-Objekte verwendet.
• Der Cache-Control-Header einer bestimmten Response wird beim Speichern von Daten im Cache ignoriert. Es gibt keine automatischen, integrierten Ablauf- oder Aktualitätsprüfungen. Sobald Sie ein Element im Cache gespeichert haben, bleibt es so lange erhalten, bis es durch den Code explizit entfernt wird. (Es gibt Bibliotheken, die die Cache-Wartung in Ihrem Namen vereinfachen. Sie werden später in dieser Reihe behandelt.)
• Im Gegensatz zu älteren synchronen APIs wie LocalStorage sind alle Cache Storage API-Vorgänge asynchron.

Ein kurzer Umweg: Versprecht und asynchron

Service Worker und die Cache Storage API verwenden asynchrone Programmierkonzepte. Insbesondere stützen sie sich stark auf Versprechen, das zukünftige Ergebnis asynchroner Vorgänge darzustellen. Bevor Sie loslegen, sollten Sie sich mit Versprechen und der zugehörigen async/await-Syntax vertraut machen.

Stellen Sie diesen Code noch nicht bereit...

Sie stellen zwar eine wichtige Grundlage dar und können unverändert verwendet werden, aber sowohl Service-Worker als auch die Cache Storage API sind praktisch untergeordnete Bausteine mit einer Reihe von Grenzfällen und „Klappen“. Es gibt einige übergeordnete Tools, mit denen sich die schwierigen Teile dieser APIs abwickeln lassen und die alles bieten, was Sie zum Erstellen eines produktionsreifen Service Workers benötigen. Ein solches Tool wird in der nächsten Anleitung beschrieben: Workbox.