Service Worker-Caching und HTTP-Caching

Die Vor- und Nachteile der Verwendung einer einheitlichen oder unterschiedlichen Ablauflogik in den Service Worker-Cache- und HTTP-Cache-Ebenen.

Jonathan Chen

Service Worker und PWAs werden zu Standards für moderne Webanwendungen, doch das Ressourcen-Caching ist immer komplexer geworden. In diesem Artikel werden die wichtigsten Aspekte des Browser-Cachings behandelt, darunter:

• Die Anwendungsfälle und Unterschiede zwischen Service Worker-Caching und HTTP-Caching
• Die Vor- und Nachteile verschiedener Ablaufstrategien für Service Worker-Caching im Vergleich zu regulären HTTP-Caching-Strategien.

Caching-Ablauf

Auf übergeordneter Ebene folgt ein Browser bei der Anforderung einer Ressource der folgenden Caching-Reihenfolge:

1. Service Worker-Cache: Der Service Worker prüft, ob sich die Ressource im Cache befindet und entscheidet anhand der programmierten Caching-Strategien, ob die Ressource selbst zurückgegeben werden soll. Hinweis dass dies nicht automatisch geschieht. Erstellen Sie einen Abruf-Event-Handler in Ihrem Service Worker ab und fangen Netzwerkanfragen ab, sodass diese vom Dienst verarbeitet werden. in den Cache des Workers und nicht in das Netzwerk ein.
2. HTTP-Cache (auch Browser-Cache genannt): Wenn die Ressource im HTTP-Cache Cache gespeichert werden und noch nicht abgelaufen ist, verwendet der Browser automatisch den Ressource aus dem HTTP-Cache.
3. Serverseitig: Wenn im Service Worker-Cache oder im HTTP-Cache nichts gefunden wird, sendet der Browser eine Anfrage an das Netzwerk, um die Ressource abzurufen. Wenn die Ressource nicht in einem CDN im Cache gespeichert ist, muss die Anfrage bis zum Ursprungsserver zurückgesendet werden.

Ebenen im Cache speichern

Service Worker-Caching

Ein Service Worker fängt Netzwerk-HTTP-Anfragen ab und verwendet Caching-Strategie um zu bestimmen, welche Ressourcen an den Browser zurückgegeben werden sollen. Der Service Worker-Cache und der HTTP-Cache dienen demselben allgemeinen Zweck. Der Service Worker-Cache bietet jedoch mehr Caching-Funktionen, z. B. eine detaillierte Kontrolle darüber, was genau im Cache gespeichert wird und wie das Caching erfolgt.

Service Worker-Cache steuern

Ein Service Worker fängt HTTP-Anfragen mit event Listener (normalerweise das Ereignis fetch). Dieses Code-Snippet die Logik einer Cache-First Caching-Strategie.

Die Verwendung von Workbox wird dringend empfohlen, um das Rad neu zu erfinden. So können Sie beispielsweise Ressourcen-URL-Pfade mit einer einzigen Zeile regulären Ausdruckscodes registrieren.

import {registerRoute} from 'workbox-routing';

registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);

Caching-Strategien und Anwendungsfälle für Service Worker

In der folgenden Tabelle werden gängige Caching-Strategien für Service Worker und ihre Anwendungsfälle beschrieben.

Weitere Vorteile des Service Worker-Cachings

Neben der detaillierten Steuerung der Caching-Logik bietet das Service Worker-Caching Folgendes:

• Mehr Arbeitsspeicher und Speicherplatz für den Ursprung: Der Browser weist HTTP-Cache-Ressourcen pro Ursprung zu. In anderen Wörter verwenden: Wenn Sie mehrere Subdomains haben, nutzen diese alle denselben HTTP-Cache. Es gibt keine garantieren, dass der Inhalt Ihres Ursprungs/Ihrer Domain lange Zeit im HTTP-Cache verbleibt. Ein Nutzer kann den Cache beispielsweise manuell über die Einstellungen eines Browsers leeren oder eine vollständige Neulade-Aktion auf einer Seite auslösen. Mit einem Service Worker-Cache haben Sie eine viel höhere dass Ihre im Cache gespeicherten Inhalte im Cache gespeichert bleiben. Siehe Dauerhaft Speicherplatz.
• Höhere Flexibilität bei instabilen Netzwerken oder Offlinenutzung: Beim HTTP-Cache haben Sie nur die Wahl zwischen „Ja“ und „Nein“. Mit dem Service Worker-Caching können Sie kleinere Probleme viel einfacher beheben (mit der Strategie „Stale-While-Revalidate“), eine vollständige Offlinenutzung ermöglichen (mit der Strategie „Nur Cache“) oder sogar eine Zwischenlösung anbieten, z. B. benutzerdefinierte Benutzeroberflächen, bei denen Teile der Seite aus dem Service Worker-Cache stammen und andere Teile gegebenenfalls ausgeschlossen werden (mit der Strategie „Set catch handler“).

HTTP-Caching

Wenn ein Browser zum ersten Mal eine Webseite und zugehörige Ressourcen lädt, speichert er diese Ressourcen in seinem HTTP-Cache Normalerweise wird der HTTP-Cache von Browsern automatisch aktiviert, vom Endnutzer deaktiviert wurde.

Bei der Verwendung des HTTP-Cachings wird der Server angewiesen, zu bestimmen, wann und wie lange eine Ressource im Cache gespeichert werden soll.

Ablauf des HTTP-Cache mit HTTP-Antwortheadern steuern

Wenn ein Server auf eine Browseranfrage nach einer Ressource antwortet, gibt er mithilfe von HTTP-Antwortheadern an, wie lange die Ressource im Cache gespeichert werden soll. Weitere Informationen finden Sie unter Antwortheader: Webserver konfigurieren.

HTTP-Caching-Strategien und -Anwendungsfälle

HTTP-Caching ist viel einfacher als Service Worker-Caching, da HTTP-Caching zeitbasierte Ressourcenablauflogik (TTL). Weitere Informationen finden Sie unter Welche Werte für den Antwortheader sollten Sie verwenden? und Zusammenfassung, um mehr über HTTP-Caching-Strategien zu erfahren.

Logik für den Cache-Ablauf entwerfen

In diesem Abschnitt werden die Vor- und Nachteile der Verwendung einer einheitlichen Ablauflogik im gesamten Service Worker erläutert Cache- und HTTP-Cache-Ebenen sowie die Vor- und Nachteile einer separaten Ablauflogik in diesen Ebenen.

Im folgenden Glitch wird veranschaulicht, wie das Caching von Service Workern und das HTTP-Caching in verschiedenen Szenarien funktionieren:

Einheitliche Ablauflogik für alle Cacheebenen

Um die Vor- und Nachteile aufzuzeigen, sehen wir uns drei Szenarien an: langfristige, mittelfristige und kurzfristig.

Szenario: Langfristiges Caching (Cache, Fallback auf Netzwerk)

• Wenn eine im Cache gespeicherte Ressource gültig ist (< 30 Tage): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück, ohne das Netzwerk aufzurufen.
• Wenn eine im Cache gespeicherte Ressource abgelaufen ist (> 30 Tage): Der Service Worker ruft die Ressource über das Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache. Daher wird die Ressource serverseitig abgerufen.

Nachteil: In diesem Szenario bietet HTTP-Caching weniger Wert, da der Browser immer Übergeben Sie die Anfrage an die Serverseite, wenn der Cache im Service Worker abläuft.

Szenario: Mittelfristiges Caching (veraltete erneute Überprüfung)

• Wenn eine im Cache gespeicherte Ressource gültig ist (< 1 Tag): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource aus dem Netzwerk ab. Der Browser hat eine Kopie der Ressource in seinem HTTP-Cache und gibt diese Kopie an den Service Worker zurück.
• Wenn eine im Cache gespeicherte Ressource abgelaufen ist (länger als 1 Tag): Der Service Worker gibt die im Cache gespeicherte Ressource sofort zurück und ruft die Ressource aus dem Netzwerk ab. Der Browser hat keine Kopie der Ressource in seinem HTTP-Cache. Daher wird die Ressource serverseitig abgerufen.

Con: Der Service Worker benötigt zusätzliches Cache-Busting, um den HTTP-Cache in um die „Neuvalidierung“ optimal zu nutzen, Schritt.

Szenario: Kurzfristiges Caching (Netzwerk fällt auf Cache zurück)

• Wenn eine im Cache gespeicherte Ressource gültig ist (<= 10 Minuten): Der Service Worker wechselt zum Netzwerk um die Ressource abzurufen. Der Browser hat eine Kopie der Ressource in seinem HTTP-Cache und gibt sie an den Service Worker zurück, ohne serverseitig zu gehen.
• Wenn eine im Cache gespeicherte Ressource abgelaufen ist (> 10 Minuten): Der Service Worker gibt den im Cache gespeicherten und wird dann im Netzwerk abgerufen. Der Browser hat keine Kopie der Ressource in ihren HTTP-Cache, sodass sie serverseitig zum Abrufen der Ressource wird.

Nachteil: Ähnlich wie beim mittelfristigen Caching-Szenario benötigt der Service Worker zusätzliche Cache-Busting-Logik verwendet, um den HTTP-Cache zu überschreiben, um die neueste Ressource aus der serverseitig.

Dienst-Worker in allen Szenarien

In allen Fällen kann der Service Worker-Cache auch dann gecachte Ressourcen zurückgeben, wenn das Netzwerk instabil ist. Andererseits ist der HTTP-Cache nicht zuverlässig, wenn das Netzwerk instabil oder ausgefallen ist.

Unterschiedliche Logik für den Cache-Ablauf im Service Worker-Cache und auf HTTP-Ebenen

Um die Vor- und Nachteile aufzuzeigen, betrachten wir noch einmal langfristige, mittel- und kurzfristige sowie Szenarien durchführen.

Szenario: Langfristiges Caching (Cache, Fallback auf Netzwerk)

• Wenn eine im Cache gespeicherte Ressource im Service Worker-Cache gültig ist (<= 90 Tage): Der Dienst Worker gibt die im Cache gespeicherte Ressource sofort zurück.
• Wenn eine im Service Worker-Cache gespeicherte Ressource abgelaufen ist (länger als 90 Tage): Der Service Worker ruft die Ressource über das Netzwerk ab. Der Browser verfügt nicht über eine Kopie der Ressource in ihrem HTTP-Cache gespeichert, sodass sie serverseitig geschaltet wird.

Vor- und Nachteile:

• Pro: Der Service Worker gibt im Cache gespeicherte Ressourcen zurück und erhalten sofort eine Antwort. sofort.
• Pro: Der Service Worker kann genauer steuern, wann sein Cache verwendet wird und wann um neue Versionen von Ressourcen anzufordern.
• Nachteil: Eine klar definierte Caching-Strategie für Service Worker ist erforderlich.

Szenario: Mittelfristiges Caching (Stale-while-revalidate)

• Wenn eine im Cache gespeicherte Ressource im Service Worker-Cache gültig ist (<= 30 Tage): Der Dienst Worker gibt die im Cache gespeicherte Ressource sofort zurück.
• Wenn eine im Cache gespeicherte Ressource im Service Worker-Cache abgelaufen ist (> 30 Tage): Der Dienst in das Netzwerk für die Ressource. Der Browser hat keine Kopie der Ressource in und wird vom HTTP-Cache auf Serverseite übertragen.

Vor- und Nachteile:

• Pro: Der Service Worker gibt im Cache gespeicherte Ressourcen zurück und erhalten sofort eine Antwort. sofort.
• Pro: Der Service Worker kann sicherstellen, dass bei der nächsten Anfrage für eine bestimmte URL ein durch die erneute Validierung, die „im Hintergrund“ erfolgt.
• Nachteil: Eine klar definierte Caching-Strategie für Service Worker ist erforderlich.

Szenario: Kurzfristiges Caching (Netzwerk greift auf den Cache zurück)

• Wenn eine im Cache des Dienstarbeiters gespeicherte Ressource gültig ist (< 1 Tag): Der Dienstarbeiter ruft die Ressource im Netzwerk ab. Der Browser gibt die Ressource vom HTTP- falls vorhanden. Wenn das Netzwerk ausgefallen ist, gibt der Service Worker die Ressource vom Service Worker-Cache
• Wenn eine zwischengespeicherte Ressource im Service Worker-Cache abgelaufen ist (länger als 1 Tag): Der Service Worker ruft die Ressource aus dem Netzwerk ab. Der Browser ruft die Ressourcen über das Netzwerk ab, da die im HTTP-Cache gespeicherte Version abgelaufen ist.

Vor- und Nachteile:

• Vorteil: Wenn das Netzwerk instabil ist oder ausfällt, gibt der Service Worker sofort zwischengespeicherte Ressourcen zurück.
• Con: Der Service Worker benötigt zusätzliches Cache-Busting, um den HTTP-Cache zu überschreiben und Auf „Zuerst Netzwerk“ setzen -Anfragen.

Fazit

Angesichts der Komplexität der Kombination von Caching-Szenarien ist es nicht möglich, eine Regel zu entwerfen, die alle Fälle abdeckt. Auf der Grundlage der Ergebnisse in den vorherigen Abschnitten gibt es jedoch einige Vorschläge, die Sie beim Entwerfen Ihrer Cache-Strategien berücksichtigen sollten:

• Die Service Worker-Caching-Logik muss nicht mit dem HTTP-Caching-Ablauf übereinstimmen Logik. Verwenden Sie nach Möglichkeit eine längere Ablauflogik im Dienstworker, um ihm mehr Kontrolle zu gewähren.
• Das HTTP-Caching spielt immer noch eine wichtige Rolle, ist aber nicht zuverlässig, wenn das Netzwerk instabil ist oder ausfällt.
• Überprüfen Sie Ihre Caching-Strategien für jede Ressource, um sicherzustellen, dass die Caching-Strategie des Service Workers einen Mehrwert bietet, ohne mit dem HTTP-Cache in Konflikt zu stehen.

Weitere Informationen

• Netzwerkzuverlässigkeit
• Unnötige Netzwerkanfragen mit dem HTTP-Cache verhindern
• HTTP-Cache-Codelab
• Die Auswirkungen von Service Workers auf die Leistung in der Praxis messen
• Cachesteuerung vs. Läuft ab
• Cache entmystifiziert: Caches prüfen, löschen und deaktivieren