Service Worker und die Cache Storage API

Jeff Posnick

Sie haben Probleme mit der Netzwerkzuverlässigkeit. Der HTTP-Cache des Browsers ist Ihre erste Verteidigungslinie. Wie Sie jedoch wissen, ist er nur dann wirklich effektiv, wenn versionierte URLs geladen werden, die Sie bereits zuvor besucht haben. Der HTTP-Cache allein reicht nicht aus.

Glücklicherweise gibt es zwei neuere Tools, mit denen Sie das Blatt wenden können: Dienstworker und die Cache Storage API. Da sie so oft zusammen verwendet werden, lohnt es sich, sich mit beiden gleichzeitig vertraut zu machen.

Dienstprogramme

Ein Service Worker ist in den Browser eingebunden und wird über zusätzlichen JavaScript-Code gesteuert, den Sie erstellen müssen. Sie stellen diese Datei zusammen mit den anderen Dateien bereit, aus denen Ihre eigentliche Webanwendung besteht.

Ein Dienstworker hat einige spezielle Funktionen. Unter anderem wartet er geduldig darauf, dass Ihre Webanwendung eine ausgehende Anfrage sendet, und greift dann ein, indem er sie abfängt. Was der Service Worker mit dieser abgefangenen Anfrage macht, liegt in Ihrer Entscheidung.

Bei einigen Anfragen ist es am besten, die Anfrage einfach an das Netzwerk weiterzuleiten, so wie es auch der Fall wäre, wenn es keinen Dienst-Worker gäbe.

Bei anderen Anfragen können Sie jedoch etwas flexibleres 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 ist das andere Puzzleteil erforderlich: die Cache Storage API.

Die Cache Storage API

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

Moment… es gibt noch einen Cache, an den wir denken müssen?

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 normale Reaktionen.

Wir empfehlen Ihnen, die Cache-Control-Header auf Ihrem Webserver zu konfigurieren, auch wenn Sie wissen, dass Sie die Cache Storage API verwenden. In der Regel reicht es aus, Cache-Control: no-cache für nicht versionierte URLs und/oder Cache-Control: max-age=31536000 für URLs mit Versionsinformationen wie Hashes festzulegen.

Beim Befüllen des Cache Storage API-Cache prüft der Browser standardmäßig im HTTP-Cache nach vorhandenen Einträgen und verwendet diese, falls gefunden. Wenn Sie dem Cache der Cache Storage API versionierte URLs hinzufügen, vermeidet der Browser eine zusätzliche Netzwerkanfrage. Die Kehrseite ist, dass Sie die Situation verschlimmern können, wenn Sie fehlerhaft konfigurierte Cache-Control-Header verwenden, z. B. eine lange Cache-Lebensdauer für eine nicht versionierte URL angeben und die Cache Storage API mit veraltetem Inhalt füllen. Das HTTP-Cache-Verhalten muss optimiert werden, damit die Cache Storage API effektiv genutzt werden kann.

Was mit dieser neuen API jetzt möglich ist? Sehr viel. Einige gängige Anwendungsfälle, die mit dem HTTP-Cache schwierig oder unmöglich wären:

• Verwenden Sie für im Cache gespeicherte Inhalte den Ansatz „Im Hintergrund aktualisieren“, auch als „Stale-While-Revalidate“ bezeichnet.
• 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, und ermöglichen Sie Nutzern, Inhalte zu aktualisieren (z. B. über eine Schaltfläche), wenn Daten tatsächlich aktualisiert wurden.

Weitere Informationen finden Sie im Kurzleitfaden zur Cache API.

API-Details

Beim Design der API sind einige Dinge zu beachten:

• Request-Objekte werden als eindeutige Schlüssel beim Lesen und Schreiben in diesen Caches verwendet. Zur Vereinfachung 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 dann automatisch für Sie.
• Response-Objekte werden als Werte in diesen Caches verwendet.
• Der Cache-Control-Header einer bestimmten Response wird beim Caching von Daten effektiv ignoriert. Es gibt keine automatischen, integrierten Ablauf- oder Aktualitätsprüfungen. Sobald Sie einen Artikel im Cache gespeichert haben, bleibt er dort, bis er durch Ihren Code explizit entfernt wird. Es gibt Bibliotheken, die die Cache-Wartung für Sie 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.

Kurzer Ausflug: Versprechen und Async/Await

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

Diesen Code noch nicht bereitstellen

Sie bilden eine wichtige Grundlage und können unverändert verwendet werden. Sowohl Dienstarbeiter als auch die Cache Storage API sind jedoch Bausteine auf niedrigerer Ebene mit einer Reihe von Grenzfällen und Fallstricken. Es gibt einige Tools auf höherer Ebene, die die schwierigen Teile dieser APIs vereinfachen können und alles bieten, was Sie zum Erstellen eines produktionsfertigen Dienstarbeiters benötigen. Im nächsten Leitfaden geht es um ein solches Tool: Workbox.