Service Worker und die Cache Storage API

Jeff Posnick

Sie kämpfen um die Zuverlässigkeit Ihres Netzwerks. Der HTTP-Cache des Browsers ist die erste Verteidigungslinie, aber wie Sie gelernt haben, ist er nur beim Laden von versionierten URLs, die Sie zuvor besucht haben, wirklich effektiv. Der HTTP-Cache allein reicht nicht aus.

Glücklicherweise gibt es zwei neuere Tools, mit denen Sie das Blatt zu Ihren Gunsten wenden können: Service Worker und die Cache Storage API. Da sie so oft zusammen verwendet werden, lohnt es sich, beide gleichzeitig zu lernen.

Service Worker

Ein Service Worker ist in den Browser integriert und wird durch ein wenig 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 Service Worker hat einige besondere Fähigkeiten. Unter anderem wartet er geduldig darauf, dass Ihre Webanwendung eine ausgehende Anfrage stellt, und fängt diese dann ab. Was der Service Worker mit dieser abgefangenen Anfrage macht, liegt bei Ihnen.

Bei einigen Anfragen ist es am besten, die Anfrage einfach an das Netzwerk weiterzuleiten, so wie es auch ohne Service Worker der Fall wäre.

Für andere Anfragen können Sie jedoch etwas Flexibleres als den HTTP-Cache des Browsers nutzen und eine zuverlässig schnelle Antwort zurückgeben, ohne sich Gedanken über das Netzwerk machen zu müssen. Dazu müssen Sie das andere Teil des Puzzles verwenden: die Cache Storage API.

Die Cache Storage API

Browser Support

  • Chrome: 43.
  • Edge: 16.
  • Firefox: 41.
  • Safari: 11.1.

Source

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 Heuristik 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… gibt es jetzt noch einen Cache, den ich berücksichtigen muss?

Sie fragen sich wahrscheinlich: „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 natürliche Reaktionen.

Es wird dennoch 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 Cache-Control: no-cache für URLs ohne Versionsangabe und/oder Cache-Control: max-age=31536000 für URLs mit Versionsangabe, z. B. Hashes, festlegen.

Beim Befüllen des Cache Storage API-Cache prüft der Browser standardmäßig, ob im HTTP-Cache bereits Einträge vorhanden sind, und verwendet diese, falls vorhanden. Wenn Sie dem Cache der Cache Storage API versionierte URLs hinzufügen, vermeidet der Browser eine zusätzliche Netzwerkanfrage. Wenn Sie jedoch falsch konfigurierte Cache-Control-Header verwenden, z. B. eine lange Cache-Lebensdauer für eine nicht versionierte URL, kann es passieren, dass Sie die Situation verschlimmern, indem Sie diese veralteten Inhalte der Cache Storage API hinzufügen. Die richtige Konfiguration des HTTP-Cache-Verhaltens ist eine Voraussetzung für die effektive Nutzung der Cache Storage API.

Mit dieser neuen API ist jetzt vieles möglich. Hier sind einige gängige Anwendungsfälle, die nur mit dem HTTP-Cache schwierig oder unmöglich wären:

  • Verwenden Sie einen Ansatz zur „Aktualisierung im Hintergrund“ für im Cache gespeicherte Inhalte, der als „stale-while-revalidate“ 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 neue Netzwerkantworten, um zu sehen, ob sich etwas geändert hat, und ermöglichen Sie dem Nutzer, Inhalte zu aktualisieren (z. B. mit einer Schaltfläche), wenn Daten tatsächlich aktualisiert wurden.

Weitere Informationen finden Sie im Leitfaden zur Cache API.

API-Grundlagen

Beachten Sie beim Design der API Folgendes:

  • Request-Objekte werden als eindeutige Schlüssel beim Lesen und Schreiben in diese Caches verwendet. Sie können als Schlüssel auch einen URL-String wie 'https://example.com/index.html' anstelle eines tatsächlichen Request-Objekts übergeben. Die API verarbeitet diesen dann automatisch.
  • Response-Objekte werden als Werte in diesen Caches verwendet.
  • Der Header Cache-Control für eine bestimmte Response wird beim Caching von Daten ignoriert. Es gibt keine automatischen, integrierten Ablauf- oder Aktualitätsprüfungen. Sobald Sie ein Element im Cache speichern, bleibt es dort, bis es explizit durch Ihren Code entfernt wird. (Es gibt Bibliotheken, die die Cache-Verwaltung für Sie vereinfachen. Diese 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 Exkurs: Promises und async/await

Service Worker und die Cache Storage API verwenden Konzepte der asynchronen Programmierung. Insbesondere werden Promises verwendet, um das zukünftige Ergebnis asynchroner Vorgänge darzustellen. Bevor Sie loslegen, sollten Sie sich mit Promises und der zugehörigen Syntax async/await vertraut machen.

Stellen Sie den Code noch nicht bereit.

Sie bieten zwar eine wichtige Grundlage und können unverändert verwendet werden, aber sowohl Service Worker als auch die Cache Storage API sind im Grunde Bausteine auf niedrigerer Ebene mit einer Reihe von Grenzfällen und „Fallstricken“. Es gibt einige übergeordnete Tools, die die schwierigen Teile dieser APIs vereinfachen und alles bieten, was Sie zum Erstellen eines produktionsreifen Service Workers benötigen. Im nächsten Leitfaden wird ein solches Tool behandelt: Workbox.