Ein zusätzliches Tool, mit dem Sie beim Bereitstellen Ihrer Webanwendung Aktualität und Aktualität in Einklang bringen können.
Was wurde versendet?
stale-while-revalidate
hilft Entwicklern, einen Ausgleich zwischen Aktualität (sofortiges Laden von im Cache gespeicherten Inhalten) und Frische (Sorgen dafür, dass Aktualisierungen der im Cache gespeicherten Inhalte in Zukunft verwendet werden) zu finden. Wenn Sie einen Webdienst oder eine Bibliothek eines Drittanbieters verwalten, der bzw. die regelmäßig aktualisiert wird, oder Ihre selbst erhobenen Assets in der Regel eine kurze Lebensdauer haben, ist stale-while-revalidate
eine nützliche Ergänzung zu Ihren vorhandenen Caching-Richtlinien.
In Chrome 75 und Firefox 68 wird unterstützt, stale-while-revalidate
zusammen mit max-age
im Cache-Control
-Antwortheader festzulegen.
Browser, die stale-while-revalidate
nicht unterstützen, ignorieren diesen Konfigurationswert stillschweigend und verwenden max-age
, wie ich gleich erläutern werde.
Was bedeutet das?
Lassen Sie uns stale-while-revalidate
in zwei Teile unterteilen: die Annahme, dass eine im Cache gespeicherte Antwort möglicherweise veraltet ist, und den Prozess der erneuten Validierung.
Erstens: Woher weiß der Browser, ob eine im Cache gespeicherte Antwort „veraltet“ ist? Ein Cache-Control
-Antwortheader, der stale-while-revalidate
enthält, sollte auch max-age
enthalten. Die Anzahl der Sekunden, die über max-age
angegeben wird, bestimmt die Gültigkeitsdauer. Alle im Cache gespeicherten Antworten, die jünger als max-age
sind, gelten als aktuell. Ältere im Cache gespeicherte Antworten gelten als veraltet.
Wenn die lokal im Cache gespeicherte Antwort noch aktuell ist, kann sie unverändert verwendet werden, um die Anfrage eines Browsers zu erfüllen. Aus Sicht von stale-while-revalidate
muss in diesem Szenario nichts unternommen werden.
Wenn die im Cache gespeicherte Antwort jedoch veraltet ist, wird eine weitere altersbasierte Prüfung durchgeführt: Liegt das Alter der im Cache gespeicherten Antwort innerhalb des zusätzlichen Zeitfensters, das durch die Einstellung stale-while-revalidate
festgelegt ist?
Wenn das Alter einer veralteten Antwort in diesen Zeitraum fällt, wird sie verwendet, um die Anfrage des Browsers zu erfüllen. Gleichzeitig wird eine Anfrage zur „Neuvalidierung“ an das Netzwerk gesendet, die die Verwendung der im Cache gespeicherten Antwort nicht verzögert. Die zurückgegebene Antwort kann dieselben Informationen wie die zuvor im Cache gespeicherte Antwort enthalten oder sich von ihr unterscheiden. In beiden Fällen wird die Netzwerkantwort lokal gespeichert und ersetzt alles, was zuvor im Cache war. Außerdem wird der Timer für die „Aktualität“ zurückgesetzt, der bei zukünftigen max-age
-Vergleichen verwendet wird.
Wenn die veraltete Antwort im Cache jedoch so alt ist, dass sie nicht mehr in den Zeitraum von stale-while-revalidate
fällt, wird die Anfrage des Browsers nicht erfüllt. Stattdessen ruft der Browser eine Antwort aus dem Netzwerk ab und verwendet diese sowohl für die Erfüllung der ursprünglichen Anfrage als auch für die Befüllung des lokalen Caches mit einer neuen Antwort.
Reales Beispiel
Unten sehen Sie ein einfaches Beispiel für eine HTTP-API, die die aktuelle Uhrzeit zurückgibt, genauer gesagt die aktuelle Anzahl der Minuten nach der vollen Stunde.
In diesem Szenario verwendet der Webserver diesen Cache-Control
-Header in seiner HTTP-Antwort:
Cache-Control: max-age=1, stale-while-revalidate=59
Wenn eine Anfrage zur Uhrzeit innerhalb der nächsten Sekunde wiederholt wird, ist der zuvor im Cache gespeicherte Wert noch aktuell und wird ohne erneute Validierung verwendet.
Wenn eine Anfrage zwischen 1 und 60 Sekunden später wiederholt wird, ist der zwischengespeicherte Wert veraltet, wird aber verwendet, um die API-Anfrage zu erfüllen. Gleichzeitig wird „im Hintergrund“ eine erneute Validierungsanfrage gesendet, um den Cache mit einem neuen Wert für die zukünftige Verwendung zu füllen.
Wenn eine Anfrage nach mehr als 60 Sekunden wiederholt wird, wird die veraltete Antwort nicht verwendet. Sowohl die Ausführung der Browseranfrage als auch die Neuvalidierung des Caches hängen davon ab, ob eine Antwort vom Netzwerk zurückgegeben wird.
Hier eine Aufschlüsselung dieser drei verschiedenen Status sowie das Zeitfenster, in dem sie für unser Beispiel gelten:
Was sind die häufigsten Anwendungsfälle?
Das obige Beispiel für einen API-Dienst, der die Minuten nach der vollen Stunde liefert, ist zwar konstruiert, veranschaulicht aber den erwarteten Anwendungsfall: Dienste, die Informationen bereitstellen, die aktualisiert werden müssen, bei denen aber ein gewisser Grad an Aktualität akzeptabel ist.
Weniger konstruierte Beispiele wären eine API für die aktuellen Wetterbedingungen oder die Top-Nachrichten der letzten Stunde.
Generell eignet sich jede Antwort, die in einem bekannten Intervall aktualisiert wird, wahrscheinlich mehrmals angefordert wird und innerhalb dieses Intervalls statisch ist, für das kurzfristige Caching über max-age
. Wenn Sie stale-while-revalidate
zusätzlich zu max-age
verwenden, erhöht sich die Wahrscheinlichkeit, dass zukünftige Anfragen mit aktuelleren Inhalten aus dem Cache erfüllt werden können, ohne dass eine Netzwerkantwort blockiert wird.
Wie interagiert es mit Service Workers?
Wenn Sie schon einmal von stale-while-revalidate
gehört haben, dann wahrscheinlich im Zusammenhang mit Rezepten, die in einem Dienst-Worker verwendet werden.
Die Verwendung von „stale-while-revalidate“ über einen Cache-Control
-Header weist einige Ähnlichkeiten mit der Verwendung in einem Service Worker auf. Viele derselben Überlegungen hinsichtlich der Abwägung zwischen Aktualität und maximaler Lebensdauer gelten auch hier. Es gibt jedoch einige Aspekte, die Sie berücksichtigen sollten, wenn Sie sich entscheiden, ob Sie einen service worker-basierten Ansatz implementieren oder sich einfach auf die Cache-Control
-Headerkonfiguration verlassen möchten.
Verwenden Sie einen Dienstworker-Ansatz, wenn…
- Sie verwenden bereits einen Service Worker in Ihrer Webanwendung.
- Sie benötigen eine detaillierte Kontrolle über den Inhalt Ihrer Caches und möchten beispielsweise eine Ablaufrichtlinie für die am wenigsten verwendeten Elemente implementieren. Das Cache-Ablaufsmodul von Workbox kann dabei helfen.
- Sie möchten benachrichtigt werden, wenn sich eine veraltete Antwort im Hintergrund während des Schritts zur erneuten Validierung ändert. Das Broadcast Cache Update-Modul von Workbox kann dabei helfen.
- Dieses
stale-while-revalidate
-Verhalten ist in allen modernen Browsern erforderlich.
Verwenden Sie einen Cache-Control-Ansatz, wenn…
- Sie möchten nicht den Aufwand für die Bereitstellung und Wartung eines Service Workers für Ihre Webanwendung haben.
- Sie möchten, dass die automatische Cache-Verwaltung des Browsers verhindert, dass Ihre lokalen Caches zu groß werden.
- Sie sind mit einem Ansatz einverstanden, der derzeit nicht in allen modernen Browsern unterstützt wird (Stand Juli 2019; die Unterstützung kann sich in Zukunft erweitern).
Wenn Sie einen Service Worker verwenden und stale-while-revalidate
für einige Antworten über einen Cache-Control
-Header aktiviert haben, hat der Service Worker in der Regel die erste Chance, auf eine Anfrage zu antworten. Wenn der Service Worker entscheidet, nicht zu antworten, oder beim Generieren einer Antwort eine Netzwerkanfrage mit fetch()
sendet, wird das über den Cache-Control
-Header konfigurierte Verhalten angewendet.
Weitere Informationen
stale-while-revalidate
-Antwort in der Fetch API-Spezifikation.- RFC 5861, die die ursprüngliche
stale-while-revalidate
-Spezifikation abdeckt. - Der HTTP-Cache: Ihre erste Verteidigungslinie, aus dem Leitfaden „Netzwerkzuverlässigkeit“ auf dieser Website.
Hero-Image von Samuel Zeller