Die Vor- und Nachteile der Verwendung konsistenter oder unterschiedlicher Ablauflogik auf den Ebenen des Service Worker-Cache und der HTTP-Cache-Ebenen.
Service Worker und PWAs werden zu Standards für moderne Webanwendungen, doch das Ressourcen-Caching ist immer komplexer geworden. In diesem Artikel geht es um das Browser-Caching, einschließlich:
- Die Anwendungsfälle und Unterschiede zwischen Service Worker-Caching und HTTP-Caching
- Die Vor- und Nachteile verschiedener Service Worker-Strategien für das Ablaufen von Caching im Vergleich zu normalen HTTP-Caching-Strategien
Caching-Ablauf
Auf übergeordneter Ebene folgt ein Browser bei der Anforderung einer Ressource der folgenden Caching-Reihenfolge:
- 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.
- 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.
- Serverseitig:Wenn im Service Worker-Cache oder HTTP-Cache nichts gefunden wird, ruft der Browser das Netzwerk auf, um die Ressource anzufordern. Wenn die Ressource nicht in einem CDN im Cache gespeichert wird, muss zurück zum Ursprungsserver gehen.
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 dienen dem gleichen Zweck, aber der Service Worker-Cache bietet mehr Caching-Funktionen, z. B. die genaue Kontrolle darüber, was genau im Cache gespeichert wird, und wie.
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 zum Beispiel Ressourcen-URL-Pfade mit einer einzelnen Zeile Regex-Code registrieren
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
Caching-Strategien und Anwendungsfälle für Service Worker
In der nächsten Tabelle werden gängige Caching-Strategien für Service Worker und deren Nutzen erläutert.
| Strategien | Aktualität | Anwendungsbeispiele |
|---|---|---|
| Netzwerk | Die Inhalte müssen immer auf dem neuesten Stand sein. |
|
| Netzwerk Fallback auf den Cache | Wir empfehlen, den neuen Content bereitzustellen. Wenn das Netzwerk jedoch ausfällt oder instabil ist, Content mit wenig altem Content bereitgestellt werden darf. |
|
| Stale- during-revalidation | Es ist in Ordnung, Inhalte im Cache sofort bereitzustellen. Aktualisierte Cache-Inhalte sollten jedoch im in der Zukunft. |
|
| Zuerst den Cache speichern, auf das Netzwerk zurückgreifen | Der Inhalt ist nicht kritisch und kann aus dem Cache bereitgestellt werden, um die Leistung zu steigern, aber der Der Service Worker sollte gelegentlich nach Updates suchen. |
|
| Nur Cache | Der Inhalt ändert sich selten. |
|
Zusätzliche Vorteile des Service Worker-Caching
Neben der detaillierten Steuerung der Caching-Logik bietet das Service Worker-Caching Folgendes:
- Mehr Arbeitsspeicher und Speicherplatz für Ihren Ursprung:Der Browser weist den HTTP-Cache zu. Ressourcen pro Ursprung aufgeschlüsselt. 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. Für Beispiel: Ein Nutzer kann den Cache leeren, indem er manuell eine Bereinigung über die Benutzeroberfläche des Browsers durchführt, oder ein Hard-Update auf einer Seite auslöst. Mit einem Service Worker-Cache haben Sie eine viel höhere dass Ihre im Cache gespeicherten Inhalte im Cache gespeichert bleiben. Siehe Dauerhaft Speicherplatz.
- Mehr Flexibilität bei instabilen Netzwerken oder Offlinefunktionen:Mit dem HTTP-Cache haben nur eine binäre Auswahl: entweder wird die Ressource im Cache gespeichert oder nicht. Mit Service Worker-Caching können Sie kleine „Hindernisse“ (mit der Strategie "veraltet" bieten eine vollständige Offline-Erfahrung (mit der "Nur Cache"-Strategie) z. B. benutzerdefinierte UI-Elemente mit Teilen der Seite, die aus dem Service Worker-Cache einige Teile gegebenenfalls ausgeschlossen (mit der Strategie „Fack-Handler einrichten“).
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.
HTTP-Caching bedeutet, sich darauf zu verlassen, dass der Server bestimmt, wann eine Ressource im Cache gespeichert wird und wie long.
Ablauf des HTTP-Cache mit HTTP-Antwortheadern steuern
Wenn ein Server auf eine Browseranfrage nach einer Ressource antwortet, verwendet der Server HTTP-Antwortheader, einem Browser mitteilen, wie lange die Ressource im Cache gespeichert werden soll. Siehe Antwortheader: Web konfigurieren , um mehr zu erfahren.
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.
Cache-Ablauflogik 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.
Der folgende Glitch zeigt, wie Service Worker-Caching und HTTP-Caching verschiedene Szenarien:
Einheitliche Ablauflogik für alle Cache-Ebenen
Um die Vor- und Nachteile aufzuzeigen, sehen wir uns drei Szenarien an: langfristige, mittelfristige und kurzfristig.
| Szenarien | Langzeit-Caching | Mittelfristiges Caching | Kurzzeitiges Caching |
|---|---|---|---|
| Service Worker-Caching-Strategie | Cache, Fallback auf Netzwerk | Veraltete erneute Validierung | Netzwerk greift auf den Cache zurück |
| Service Worker-Cache-TTL | 30 Tage | 1 Tag | 10 Min. |
| HTTP-Cache-Maximalalter | 30 Tage | 1 Tag | 10 Min. |
Szenario: Langfristiges Caching (Cache, Fallback auf Netzwerk)
- Wenn eine im Cache gespeicherte Ressource gültig ist (<= 30 Tage): Der Service Worker gibt den im Cache gespeicherten ohne das Netzwerk zu verbinden.
- Wenn eine im Cache gespeicherte Ressource abgelaufen ist (> 30 Tage): Der Service Worker wechselt zum Netzwerk, und ruft die Ressource ab. Im Browser befindet sich keine Kopie der Ressource im HTTP-Cache. für die Ressource auf Serverseite geht.
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 den im Cache gespeicherten und wird dann im Netzwerk abgerufen. Im Browser befindet sich eine Kopie von der Ressource in ihrem HTTP-Cache, sodass sie diese Kopie an den Service Worker zurückgibt.
- Wenn eine im Cache gespeicherte Ressource abgelaufen ist (> 1 Tag): 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.
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 greift auf den Cache zurück)
- Wenn eine im Cache gespeicherte Ressource gültig ist (<= 10 Minuten): Der Service Worker wechselt zum Netzwerk um die Ressource abzurufen. Im Browser befindet sich eine Kopie der Ressource im HTTP-Cache, sodass ohne serverseitig an den Service Worker zu gelangen.
- 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.
Service Worker in allen Szenarien
In allen Szenarien kann der Service Worker-Cache im Cache gespeicherte Ressourcen zurückgeben, wenn das Netzwerk instabil sind. 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.
| Szenarien | Langzeit-Caching | Mittelfristiges Caching | Kurzzeitiges Caching |
|---|---|---|---|
| Service Worker-Caching-Strategie | Cache, Fallback auf Netzwerk | Veraltete erneute Validierung | Netzwerk greift auf den Cache zurück |
| Service Worker-Cache-TTL | 90 Tage | 30 Tage | 1 Tag |
| HTTP-Cache-Maximalalter | 30 Tage | 1 Tag | 10 Min. |
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 Cache gespeicherte Ressource im Service Worker-Cache abgelaufen ist (> 90 Tage): Der Dienst Der Worker ruft im Netzwerk die Ressource 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 (Instandsetzung während Neuvalidierung)
- 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 gespeicherte Ressource im Service Worker-Cache gültig ist (<= 1 Tag): Der Dienst in das Netzwerk für die Ressource. 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 im Cache gespeicherte Ressource im Service Worker-Cache abgelaufen ist (> 1 Tag): Der Dienst Der Worker ruft im Netzwerk die Ressource ab. Der Browser ruft die Ressourcen über den Netzwerk, da die im HTTP-Cache gespeicherte Version abgelaufen ist.
Vor- und Nachteile:
- Pro: Wenn das Netzwerk instabil oder ausgefallen ist, gibt der Service Worker im Cache gespeicherte Daten zurück Ressourcen sofort verfügbar sind.
- 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. Basierend auf den Ergebnissen in den vorherigen Abschnitten Vorschläge, die Sie beim Entwerfen Ihrer Cache-Strategien beachten 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 Service Worker, um dem Service Worker zu gewähren. mehr Kontrolle.
- HTTP-Caching spielt weiterhin eine wichtige Rolle, ist aber nicht zuverlässig, wenn das Netzwerk instabil oder nicht verfügbar.
- Sehen Sie sich Ihre Caching-Strategien für jede Ressource noch einmal an, um sicherzustellen, dass Ihr Service Worker-Caching -Strategie stellt ihren Wert bereit, ohne einen Konflikt mit dem HTTP-Cache zu verursachen.