Der Cache-Speicher ist ein leistungsstarkes Tool. So sind Ihre Apps weniger von den Netzwerkbedingungen abhängig. Wenn Sie Caches richtig nutzen, können Sie Ihre Webanwendung offline verfügbar machen und Ihre Assets bei jeder Netzwerkverbindung so schnell wie möglich bereitstellen. Wie bereits im Abschnitt Assets und Daten erwähnt, können Sie die beste Strategie für das Caching der erforderlichen Assets festlegen. Zum Verwalten des Caches interagiert Ihr Service Worker mit der Cache Storage API.
Die Cache Storage API ist in verschiedenen Kontexten verfügbar:
- Der Fensterkontext (Hauptthread Ihrer PWA)
- Der Service Worker.
- Alle anderen von Ihnen verwendeten Arbeitskräfte.
Ein Vorteil der Verwaltung des Caches mithilfe von Dienst-Workern besteht darin, dass sein Lebenszyklus nicht an das Fenster gebunden ist. Das bedeutet, dass der Hauptthread nicht blockiert wird. Beachten Sie, dass für die Verwendung der Cache Storage API die meisten dieser Kontexte über eine TLS-Verbindung laufen müssen.
Was im Cache gespeichert werden soll
Die erste Frage, die Ihnen zum Caching in den Sinn kommt, ist wahrscheinlich: Was soll im Cache gespeichert werden? Es gibt keine eindeutige Antwort auf diese Frage. Sie können jedoch mit allen Mindestressourcen beginnen, die Sie zum Rendern der Benutzeroberfläche benötigen.
Diese Ressourcen sollten Folgendes enthalten:
- Der HTML-Code der Startseite (start_url Ihrer App).
- CSS-Stylesheets, die für die Hauptoberfläche erforderlich sind.
- In der Benutzeroberfläche verwendete Bilder
- JavaScript-Dateien, die zum Rendern der Benutzeroberfläche erforderlich sind.
- Daten, z. B. eine JSON-Datei, die für die grundlegende Darstellung erforderlich sind.
- Webschriften
- In einer mehrseitigen Anwendung andere HTML-Dokumente, die Sie schnell oder offline bereitstellen möchten.
Offlinefähig
Die Offlinefunktion ist zwar eine der Anforderungen für eine progressive Web-App, aber nicht jede PWA muss vollständig offline funktionieren, z. B. Cloud-Gaming-Lösungen oder Apps für Krypto-Assets. Daher ist es in Ordnung, eine einfache Benutzeroberfläche anzubieten, die Nutzer durch diese Situationen führt.
Ihre PWA sollte keine Browserfehlermeldung anzeigen, dass die Seite vom Web-Rendering-Engine nicht geladen werden konnte. Verwenden Sie stattdessen Ihren Service Worker, um Ihre eigenen Mitteilungen anzuzeigen, und vermeiden Sie so einen generischen und verwirrenden Browserfehler.
Je nach den Anforderungen Ihrer PWA stehen Ihnen viele verschiedene Caching-Strategien zur Verfügung. Daher ist es wichtig, die Cache-Nutzung so zu gestalten, dass eine schnelle und zuverlässige Nutzung möglich ist. Wenn sich beispielsweise alle App-Assets schnell herunterladen lassen, nicht viel Speicherplatz belegen und nicht bei jeder Anfrage aktualisiert werden müssen, ist das Caching aller Assets eine gute Strategie. Wenn Sie hingegen Ressourcen haben, die immer die neueste Version sein müssen, sollten Sie diese Assets nicht im Cache speichern.
API verwenden
Mit der Cache Storage API kannst du eine Reihe von Caches in deinem Ursprung definieren, die jeweils mit einem von dir definierten Stringnamen gekennzeichnet sind. Wenn du über das caches
-Objekt auf die API zugreifst, kannst du mit der open
-Methode einen Cache erstellen oder einen bereits erstellten öffnen. Die Methode „open“ gibt ein Versprechen 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 zum Herunterladen und Speichern der Assets auffordern möchten, verwenden Sie die Methoden add
oder addAll
. Die Methode add
stellt eine Anfrage und speichert eine HTTP-Antwort. addAll
speichert 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-Speicher-Benutzeroberfläche speichert die gesamte Antwort, einschließlich aller Header und des Textkörpers. Sie können sie später mit einer HTTP-Anfrage oder einer URL als Schlüssel abrufen. Wie das geht, erfährst du im Kapitel zum Bereitstellen.
Wann sollte ich Inhalte im Cache speichern?
In Ihrer PWA entscheiden Sie, wann Dateien im Cache gespeichert werden. Es ist zwar möglich, so viele Assets wie möglich zu speichern, wenn der Service Worker installiert wird, aber das ist in der Regel nicht die beste Idee. Das Caching unnötiger Ressourcen verschwendet Bandbreite und Speicherplatz und kann dazu führen, dass Ihre App unbeabsichtigt veraltete Ressourcen ausliefert.
Sie müssen nicht alle Assets gleichzeitig im Cache speichern. Sie können Assets während des Lebenszyklus Ihrer PWA mehrmals im Cache speichern, z. B.:
- Bei der Installation des Dienstarbeiters
- Nach dem ersten Seitenaufbau.
- Wenn der Nutzer einen Abschnitt oder eine Route aufruft.
- Wenn das Netzwerk inaktiv ist.
Sie können das Caching neuer Dateien im Haupt- oder im Service Worker-Kontext anfordern.
Assets in einem Service Worker im Cache speichern
Eines der häufigsten Szenarien ist das Caching einer Mindestanzahl von Assets, wenn der Dienstworker installiert wird. Dazu können Sie die Cache-Speicher-Schnittstelle im install
-Ereignis im Service Worker verwenden.
Da der Service Worker-Thread jederzeit beendet werden kann, können Sie den Browser auffordern, auf das Ende des addAll
-Versprechens zu warten, um die Wahrscheinlichkeit zu erhöhen, dass alle Assets gespeichert und die App konsistent bleibt. Im folgenden Beispiel wird gezeigt, wie das mithilfe der Methode waitUntil
des Ereignisarguments funktioniert, das im Dienstanbieter-Ereignislistener empfangen wird.
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 Methode waitUntil()
empfängt ein Versprechen und bittet den Browser, zu warten, bis die Aufgabe im Versprechen abgeschlossen (erfüllt oder fehlgeschlagen) ist, bevor der Service Worker-Prozess beendet wird. Möglicherweise müssen Sie Versprechen verketten und die add()
- oder addAll()
-Aufrufe zurückgeben, damit ein einzelnes Ergebnis an die waitUntil()
-Methode übergeben wird.
Sie können Versprechen auch mit der Async/Await-Syntax verarbeiten. In diesem Fall müssen Sie eine asynchrone Funktion erstellen, die await
aufrufen und nach dem Aufruf ein Versprechen an waitUntil()
zurückgeben kann, 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
Ihre PWA kann Assets von Ihrem Ursprung und plattformübergreifend herunterladen und im Cache speichern, z. B. Inhalte von CDNs von Drittanbietern. Bei einer plattformübergreifenden App ähnelt die Cache-Interaktion sehr stark Anfragen vom selben Ursprung. Die Anfrage wird ausgeführt und eine Kopie der Antwort wird im Cache gespeichert. Wie bei anderen im Cache gespeicherten Assets kann es nur im Ursprung Ihrer App verwendet werden.
Das Asset wird als nicht transparente Antwort gespeichert. Das bedeutet, dass der Inhalt oder die Header dieser Antwort nicht über Ihren Code angezeigt oder geändert werden können. Außerdem wird bei nicht transparenten Antworten ihre tatsächliche Größe in der Speicher-API nicht angegeben, was sich auf die Kontingente auswirkt. Einige Browser geben große Größen an, z. B. 7 MB, unabhängig davon, ob die Datei nur 1 KB groß ist.
Assets aktualisieren und löschen
Du kannst Assets mit cache.put(request, response)
aktualisieren und mit delete(request)
löschen.
Weitere Informationen finden Sie in der Dokumentation zu Cache-Objekten.
Cache-Speicher debuggen
Viele Browser bieten die Möglichkeit, den Inhalt des Cache-Speichers auf dem Tab „Anwendung“ der DevTools zu debuggen. Dort sehen Sie den Inhalt jedes Caches im aktuellen Ursprung. Weitere Informationen zu diesen Tools finden Sie im Kapitel „Tools und Debugging“.