Caching läuft...

Der Cache-Speicher ist ein leistungsstarkes Tool. Apps sind dadurch weniger von den Netzwerkbedingungen abhängig. Mit einer guten Nutzung von Caches können Sie Ihre Webanwendung offline verfügbar machen und Ihre Assets so schnell wie möglich und in jeder Netzwerkbedingung bereitstellen. Wie unter Assets und Daten erwähnt, können Sie die beste Strategie für das Caching der erforderlichen Assets festlegen. Zum Verwalten des Cache interagiert Ihr Service Worker mit der Cache Storage API.

Die Cache Storage API ist in verschiedenen Kontexten verfügbar:

• Der Fensterkontext (der Hauptthread Ihrer PWA).
• Der Service Worker.
• Alle anderen von Ihnen verwendeten Worker.

Ein Vorteil der Verwaltung Ihres Caches mit Service Workern besteht darin, dass sein Lebenszyklus nicht an das Fenster gebunden ist. Das bedeutet, dass Sie den Hauptthread nicht blockieren. Beachten Sie, dass die Cache Storage API in den meisten Kontexten nur über eine TLS-Verbindung verwendet werden kann.

Was wird im Cache gespeichert?

Die erste Frage zum Caching ist, was im Cache gespeichert werden soll. Es gibt keine allgemeingültige Antwort auf diese Frage. Sie können aber mit allen Ressourcen beginnen, die Sie mindestens benötigen, um die Benutzeroberfläche zu rendern.

Diese Ressourcen sollten Folgendes enthalten:

• Der HTML-Code der Hauptseite (die start_url Ihrer Anwendung).
• CSS-Stylesheets, die für die Hauptbenutzeroberfläche erforderlich sind
• Bilder, die auf der Benutzeroberfläche verwendet werden.
• JavaScript-Dateien, die zum Rendern der Benutzeroberfläche erforderlich sind.
• Daten wie eine JSON-Datei sind erforderlich, um eine grundlegende Erfahrung zu rendern.
• Web-Schriftarten
• In einer mehrseitigen Anwendung andere HTML-Dokumente, die Sie schnell oder offline bereitstellen möchten

Offlinefähig

Eine der Voraussetzungen für progressive Web-Apps ist, dass sie auch offline nutzbar sein müssen. Nicht jede PWA braucht aber ein vollständiges Offlineerlebnis, z. B. Cloud-Gaming-Lösungen oder Apps für Krypto-Assets. Daher ist es in Ordnung, eine einfache Benutzeroberfläche anzubieten, auf der die Nutzer durch diese Situationen geführt werden.

Die PWA sollte nicht die Fehlermeldung eines Browsers darstellen, die besagt, dass die Web-Rendering-Engine die Seite nicht laden konnte. Verwenden Sie stattdessen Ihren Service Worker, um Ihre eigenen Mitteilungen anzuzeigen und so allgemeine und verwirrende Browserfehler zu vermeiden.

Es gibt viele verschiedene Caching-Strategien, die Sie je nach den Anforderungen Ihrer PWA anwenden können. Deshalb ist es wichtig, die Cache-Nutzung so zu gestalten, dass sie schnell und zuverlässig funktioniert. Wenn beispielsweise alle Ihre App-Assets schnell heruntergeladen werden, nicht viel Speicherplatz verbrauchen und nicht bei jeder Anfrage aktualisiert werden müssen, wäre das Caching all Ihrer Assets eine gute Strategie. Wenn Sie andererseits Ressourcen haben, die die neueste Version sein müssen, sollten Sie diese Assets möglicherweise überhaupt nicht im Cache speichern.

API verwenden

Verwenden Sie die Cache Storage API, um eine Reihe von Caches innerhalb Ihres Ursprungs zu definieren, die jeweils mit einem von Ihnen definierten Stringnamen identifiziert werden. Sie können über das Objekt caches auf die API zugreifen. Die Methode open ermöglicht das Erstellen oder Öffnen eines bereits erstellten Caches. Die Methode „open“ gibt ein Promise für das Cache-Objekt zurück.

caches.open("pwa-assets")
.then(cache => {
  // you can download and store, delete or update resources with cache arguments
});

Assets herunterladen und speichern

Wenn Sie den Browser bitten möchten, die Assets herunterzuladen und zu speichern, verwenden Sie die Methode add oder addAll. Die Methode add stellt eine Anfrage und speichert eine HTTP-Antwort sowie addAll eine Gruppe von HTTP-Antworten als Transaktion basierend auf einem Array von Anfragen oder URLs.

caches.open("pwa-assets")
.then(cache => {
  cache.add("styles.css"); // it stores only one resource
  cache.addAll(["styles.css", "app.js"]); // it stores two resources
});

Die Cache-Speicherschnittstelle speichert die gesamte Antwort einschließlich aller Header und des Textkörpers. Sie können ihn daher später mit einer HTTP-Anfrage oder einer URL als Schlüssel abrufen. Weitere Informationen dazu finden Sie im Kapitel zur Auslieferung.

Wann muss der Cache gespeichert werden?

In Ihrer PWA entscheiden Sie, wann Dateien im Cache gespeichert werden sollen. Ein Ansatz besteht darin, so viele Assets wie möglich zu speichern, wenn der Service Worker installiert wird. Dies ist jedoch normalerweise nicht die beste Idee. Das Caching unnötiger Ressourcen verschwendet Bandbreite und Speicherplatz und könnte dazu führen, dass Ihre Anwendung unbeabsichtigte veraltete Ressourcen bereitstellt.

Sie müssen nicht alle Assets auf einmal im Cache speichern. Sie können Assets während des Lebenszyklus Ihrer PWA mehrmals im Cache speichern, z. B.:

• Bei Installation des Service Workers
• Nach dem Laden der ersten Seite
• Wenn der Nutzer zu einem Abschnitt oder einer Route navigiert.
• Wenn das Netzwerk inaktiv ist.

Sie können das Caching neuer Dateien im Hauptthread oder im Service Worker-Kontext anfordern.

Assets in einem Service Worker zwischenspeichern

Eines der häufigsten Szenarien besteht darin, bei der Installation des Service Workers eine Mindestanzahl von Assets im Cache zu speichern. Dazu können Sie die Cache-Speicherschnittstelle im Ereignis install im Service Worker verwenden.

Da der Service Worker-Thread jederzeit angehalten werden kann, kannst du den Browser auffordern, auf die Fertigstellung des addAll-Promise zu warten. So hast du die Möglichkeit, alle Assets zu speichern und die App-Konsistenz zu wahren. Das folgende Beispiel zeigt, wie Sie dies mit der Methode waitUntil des im Service Worker-Event-Listeners empfangenen Ereignisarguments tun.

const urlsToCache = ["/", "app.js", "styles.css", "logo.svg"];
self.addEventListener("install", event => {
   event.waitUntil(
      caches.open("pwa-assets")
      .then(cache => {
         return cache.addAll(urlsToCache);
      });
   );
});

Die waitUntil()-Methode empfängt ein Promise und fordert den Browser auf, zu warten, bis die Aufgabe im Promise aufgelöst wurde (ausgeführt oder fehlgeschlagen), bevor der Service Worker-Prozess beendet wird. Möglicherweise müssen Sie Promise verketten und die add()- oder addAll()-Aufrufe zurückgeben, damit ein einzelnes Ergebnis an die Methode waitUntil() weitergeleitet wird.

Du kannst Promis auch mit der Syntax „async/await“ verarbeiten. In diesem Fall musst du eine asynchrone Funktion erstellen, die await aufrufen kann und danach ein Promise an waitUntil() zurückgibt, wie im folgenden Beispiel:

const urlsToCache = ["/", "app.js", "styles.css", "logo.svg"];
self.addEventListener("install", (event) => {
   let cacheUrls = async () => {
      const cache = await caches.open("pwa-assets");
      return cache.addAll(urlsToCache);
   };
   event.waitUntil(cacheUrls());
});

Domainübergreifende Anfragen und undurchsichtige Antworten

Über Ihre PWA können Assets Ihrer Quelle und domainübergreifend, z. B. Inhalte von Drittanbieter-CDNs, heruntergeladen und im Cache gespeichert werden. Bei einer domainübergreifenden Anwendung ist die Cache-Interaktion den Anfragen am selben Ursprung sehr ähnlich. Die Anfrage wird ausgeführt und eine Kopie der Antwort wird in Ihrem Cache gespeichert. Wie andere im Cache gespeicherte Assets kann es nur am Ursprung Ihrer App verwendet werden.

Das Asset wird als opaque Antwort gespeichert. Das bedeutet, dass Ihr Code den Inhalt oder die Header dieser Antwort nicht sehen oder ändern kann. Undurchsichtige Antworten geben außerdem nicht ihre tatsächliche Größe in der Storage API an, was sich auf die Kontingente auswirkt. Einige Browser stellen große Größen wie 7 MB bereit, unabhängig davon, ob die Datei nur 1 KB groß ist.

Assets aktualisieren und löschen

Sie können Assets mit cache.put(request, response) aktualisieren und Assets mit delete(request) löschen.

Weitere Informationen finden Sie in der Dokumentation zu Cache-Objekten.

Fehler im Cache-Speicher beheben

Viele Browser bieten eine Möglichkeit zum Debuggen des Inhalts des Cache-Speichers auf dem Tab „Anwendung“ der Entwicklertools. Dort können Sie den Inhalt jedes Caches im aktuellen Ursprung sehen. Weitere Informationen zu diesen Tools finden Sie im Kapitel Tools und Fehlerbehebung.

Ressourcen

• Cache-Speicher auf MDN
• Die Cache API: Kurzanleitung
• Die Offline-Kochbücher