Die stale-while-revalidate HTTP Cache-Control-Direktive ermöglicht es Browsern, zwischengespeicherte Inhalte sofort bereitzustellen, während sie im Hintergrund asynchron revalidiert werden. Diese Funktion ist eine primäre Methode zur Verbesserung der Website-Leistung, indem die Wartezeit der Benutzer beim Herunterladen frischer Inhalte vom Server verkürzt wird. Durch das Setzen dieses Headers weisen Sie den Browser an, eine bestehende, zwischengespeicherte Version einer Seite oder eines Assets anzuzeigen, wenn sie sich noch im Stale-Fenster befindet, während der Browser gleichzeitig den Server auf eine neuere Version überprüft.
Warum sollten Sie stale-while-revalidate verwenden?
Die Web-Performance hängt stark von der Minimierung der Latenz für wiederkehrende Besucher ab. In einem typischen Account besucht ein Nutzer eine Landingpage möglicherweise mehrmals täglich. Wenn Ihre Cache-Header zu streng sind, fragt der Browser ständig den Server nach einer Bestätigung, was das Erlebnis verlangsamt. Die Verwendung von stale-while-revalidate gleicht das Bedürfnis nach frischen Daten effektiv mit der Geschwindigkeit des lokalen Cachings aus. Sie hält die Benutzeroberfläche reaktionsschnell, indem sie die Notwendigkeit vermeidet, während der ersten Rendering-Phase eines Assets auf eine Netzwerkantwort zu warten.
Diese Direktive ist besonders nützlich für Assets, die keine millisekundenpräzise Genauigkeit erfordern. Betrachten Sie zum Beispiel eine Produktpreisseite oder einen Blog-Feed, der sich mehrmals am Tag aktualisiert. Durch die Verwendung dieser Direktive erlauben Sie dem Browser, den zwischengespeicherten Inhalt sofort anzuzeigen. Wenn dieser Inhalt älter als Ihr angegebenes max-age ist, sich aber innerhalb des stale-while-revalidate-Fensters befindet, ruft der Browser das Update im Hintergrund ab. Der Nutzer sieht die Seite sofort und beim nächsten Besuch die neuen Daten.
Wie lautet die Syntax für die Direktive?
Die Direktive wird über den Cache-Control HTTP-Header implementiert. Sie definieren ein max-age, um dem Browser mitzuteilen, wie lange der Inhalt als frisch gilt, und hängen dann den stale-while-revalidate-Parameter an. Eine gängige Konfiguration sieht zum Beispiel so aus: Cache-Control: max-age=60, stale-while-revalidate=3600. Diese Konfiguration teilt dem Browser mit, dass das Asset für 60 Sekunden frisch ist. Wenn eine Anfrage nach 60 Sekunden, aber vor 3600 Sekunden erfolgt, liefert der Browser den veralteten Inhalt aus und leitet einen Hintergrundabruf ein.
- max-age: Legt die Dauer fest, für die der Inhalt als frisch gilt.
- stale-while-revalidate: Legt das Zeitfenster nach Ablauf des max-age fest, in dem der Browser veraltete Inhalte verwenden kann, während er ein Update abruft.
- Privat vs. Öffentlich: Diese Header können mit privaten oder öffentlichen Direktiven kombiniert werden, um zu steuern, wo der Inhalt gespeichert wird, z. B. im Browser-Cache im Vergleich zu einem gemeinsam genutzten CDN-Cache.
So konfigurieren Sie Ihren Server für diesen Header
Um dies auf Ihrem Server zu implementieren, müssen Sie die an den Client gesendeten Antwort-Header modifizieren. Wenn Sie Nginx verwenden, würden Sie Ihre Konfigurationsdatei innerhalb des location-Blocks für Ihre statischen Assets oder API-Endpunkte anpassen. Eine Beispielzeile wäre: add_header Cache-Control ‘public, max-age=86400, stale-while-revalidate=86400’;. Dieser Ansatz stellt sicher, dass Ihr Server die Caching-Strategie klar an jeden Browser kommuniziert, der Ihre Ressourcen anfordert, was zu einem konsistenteren Erlebnis für Ihre Endbenutzer führt.
Für Entwickler, die Apache verwenden, können Sie das mod_headers-Modul nutzen, um dasselbe Ergebnis zu erzielen. Sie würden eine Zeile zu Ihrer .htaccess-Datei hinzufügen wie: Header set Cache-Control ‘max-age=604800, stale-while-revalidate=86400’. Sobald diese Änderungen bereitgestellt sind, empfiehlt es sich, die Antwort-Header in den Entwicklertools des Browsers zu überprüfen. Öffnen Sie den Netzwerk-Tab, aktualisieren Sie die Seite und wählen Sie die Ressource aus, um zu bestätigen, dass der Cache-Control-Wert Ihrer beabsichtigten Konfiguration entspricht.
Vergleich von Caching-Strategien
| Strategie | Sofortige Geschwindigkeit | Frische |
|---|---|---|
| Standard-Cache | Hoch | Gering |
| No-Cache | Gering | Hoch |
| Stale-While-Revalidate | Hoch | Hoch |
Wie Alien Road stale-while-revalidate anwendet
Bei Alien Road überprüfen wir häufig die Leistungsmetriken von Kunden, wenn wir Web-Schnittstellen erstellen oder optimieren. Bei einem typischen Projekt untersuchen wir zunächst die aktuellen Serverantwortzeiten und die Art der bereitgestellten Inhalte. Wenn wir feststellen, dass eine Website auf statische Assets oder häufig abgerufene Daten angewiesen ist, die sich langsam ändern, empfehlen wir die Implementierung dieser Direktive. Wir stellen sicher, dass die Implementierung nicht mit Sicherheitsanforderungen kollidiert, insbesondere bei Seiten mit sensiblen Benutzerdaten.
Unser Prozess umfasst die Überprüfung der bestehenden Header-Konfigurationen und das Testen der Ladezeiten in verschiedenen Browsern. Anschließend passen wir die max-age- und stale-while-revalidate-Intervalle basierend auf der spezifischen Aktualisierungshäufigkeit des Inhalts an. Beispielsweise erfordert eine Nachrichtenseite möglicherweise kürzere Intervalle, während eine Unternehmensportfolioseite von längeren profitieren könnte. Wir dokumentieren diese Einstellungen, damit das Kundenteam versteht, warum bestimmte Assets zwischengespeichert erscheinen und wie Hintergrundaktualisierungen die Gesamterfahrung der Benutzer beeinflussen.
Welche Assets eignen sich am besten für diesen Ansatz?
Nicht jedes Asset auf Ihrer Website ist ein Kandidat für stale-while-revalidate. Sie sollten Assets priorisieren, die für die unmittelbare Sicherheit nicht kritisch sind oder bei denen eine leichte Verzögerung der Inhaltsaktualisierung akzeptabel ist. Bilder, CSS-Dateien, JavaScript-Bundles und semi-statische API-Antworten sind ideale Kandidaten. Durch die Verwendung dieser Direktive für diese Dateien reduzieren Sie die Last auf Ihrem Ursprungsserver und stellen sicher, dass Besucher die schnellstmöglichen Rendering-Zeiten erhalten.
- CSS- und JavaScript-Dateien: Diese ändern sich selten so drastisch, dass sofortige Aktualisierungen erforderlich sind.
- Produktbilder: Das Speichern dieser mit einem langen Revalidierungsfenster spart erhebliche Bandbreite.
- JSON-Daten-Feeds: Unsensible Daten, die sich periodisch aktualisieren, funktionieren gut mit Hintergrundrevalidierung.
Häufige Fallstricke, die es zu vermeiden gilt
Ein häufiger Fehler ist die Einstellung eines zu langen Revalidierungsfensters für Inhalte, die eine hohe Präzision erfordern. Wenn ein Benutzer erwartet, einen Live-Aktienkurs oder eine kritische Warnung zu sehen, kann die Bereitstellung veralteter Inhalte kontraproduktiv sein. Bewerten Sie immer die geschäftlichen Auswirkungen der Bereitstellung von Informationen, die Minuten oder Stunden alt sind. Vermeiden Sie außerdem, dies auf Authentifizierungs-Token oder CSRF-Token anzuwenden, da diese immer frisch sein müssen, um Sicherheitslücken bei Formularübermittlungen oder Kontoaktionen zu verhindern.
Wo Sie diese Woche beginnen sollten
Beginnen Sie damit, die fünf am häufigsten aufgerufenen statischen Ressourcen auf Ihrer Website zu identifizieren. Verwenden Sie Ihre Browser-Entwicklertools, um den aktuellen Cache-Control-Header für jede einzelne zu überprüfen. Wenn Sie ein max-age ohne eine stale-while-revalidate-Komponente sehen, berechnen Sie ein geeignetes Revalidierungsfenster basierend darauf, wie oft sich diese spezifische Datei ändert. Wenden Sie die Änderung zuerst in einer Staging-Umgebung auf Ihre Serverkonfiguration an, um zu überprüfen, ob das Browserverhalten Ihren Erwartungen entspricht, bevor Sie es auf Ihrer Live-Produktionswebsite bereitstellen.
Häufig gestellte Fragen
Funktioniert dies in allen Browsern?
Die meisten modernen Browser unterstützen die stale-while-revalidate-Direktive. Da sie Teil der Standard-Cache-Control-Spezifikation ist, ignorieren Browser, die den Parameter nicht erkennen, ihn einfach und folgen den Standard-max-age-Anweisungen. Dies macht sie zu einer sicheren progressiven Verbesserung, die Sie zu Ihrer bestehenden Caching-Strategie hinzufügen können, ohne das Erlebnis für ältere Browser zu beeinträchtigen, die den Hintergrundrevalidierungsprozess möglicherweise nicht unterstützen.
Kann ich dies mit einem CDN verwenden?
Ja, viele moderne Content Delivery Networks unterstützen stale-while-revalidate. Wenn ein CDN diesen Header von Ihrem Ursprungsserver empfängt, kann es den Inhalt zwischenspeichern und den Hintergrundrevalidierungsprozess selbst abwickeln. Dies ist äußerst effektiv zur Reduzierung des Ursprungsverkehrs. Überprüfen Sie die Dokumentation Ihres CDN-Anbieters, um zu bestätigen, ob dieser diese Direktive unterstützt und ob bestimmte Konfigurationsschritte erforderlich sind, um sie auf der Edge-Schicht zu aktivieren.
Was passiert, wenn das Hintergrund-Update fehlschlägt?
Wenn die Hintergrundrevalidierungsanfrage fehlschlägt, verwendet der Browser in der Regel weiterhin die veraltete Version des Inhalts, die er bereits in seinem Cache hat. Die Benutzererfahrung bleibt unterbrochen, da der Browser dem Besucher keinen Fehler anzeigt. Wenn der Benutzer die Ressource das nächste Mal anfordert, versucht der Browser möglicherweise erneut, den Revalidierungsprozess durchzuführen, abhängig von der internen Logik des Browsers und dem Status des Caches.
Ist dies besser als die ETag-Validierung?
Diese beiden Methoden dienen unterschiedlichen Zwecken. Die ETag-Validierung erfordert einen Hin- und Rück zum Server, um zu prüfen, ob sich der Inhalt geändert hat, was immer noch eine gewisse Latenz mit sich bringt. Die stale-while-revalidate-Direktive eliminiert diese Latenz vollständig, indem sie den zwischengespeicherten Inhalt sofort anzeigt. Sie können sie zusammen verwenden, um sicherzustellen, dass der Browser selbst bei der Revalidierung des Caches die vollständige Nutzlast nur dann herunterlädt, wenn sich der Inhalt tatsächlich geändert hat, was noch mehr Bandbreite spart.
Weiterlesen: Webdesign und -entwicklung · Webdesign