Nutzer, die deine Website ein zweites Mal laden, verwenden ihren HTTP-Cache. Prüfe daher, ob alles einwandfrei funktioniert.
Dieser Beitrag ist eine Ergänzung zum Video Love your Cache, das Teil des Erweiterten Inhalts auf dem Chrome Dev Summit 2020 ist. Sehen Sie sich auch dieses Video an:
Wenn Nutzer Ihre Website ein zweites Mal laden, verwendet ihr Browser Ressourcen im HTTP-Cache, um diesen Vorgang zu beschleunigen. Die Standards für das Caching im Web gehen jedoch seit 1999 zurück, und sie sind ziemlich breit gefasst. Ob eine Datei, z. B. CSS oder ein Bild, wieder aus dem Netzwerk abgerufen oder aus dem Cache geladen wird, ist eine ziemlich genaue Wissenschaft.
In diesem Beitrag geht es um einen vernünftigen, modernen Standard für das Caching – einen, der gar kein Caching durchführt. Aber das ist nur die Standardeinstellung, die natürlich differenzierter ist als nur „Deaktivieren“. Am besten gleich weiterlesen!
Ziele
Beim zweiten Laden einer Website haben Sie zwei Ziele:
- Stellen Sie sicher, dass Ihre Nutzer die aktuellste verfügbare Version erhalten. Wenn Sie etwas geändert haben, sollten dies schnell umgesetzt werden.
- Punkt 1 ausführen und dabei so wenig wie möglich aus dem Netzwerk abrufen
Im Großen und Ganzen ist es sinnvoll, nur die kleinste Änderung an Ihre Clients zu senden, wenn diese Ihre Website neu laden. Es ist nicht einfach, Ihre Website so zu strukturieren, dass Änderungen möglichst effizient verteilt sind (mehr dazu unten und im Video).
Es gibt jedoch auch andere Optionen, wenn Sie das Caching in Betracht ziehen. Vielleicht haben Sie beschlossen, den HTTP-Cache eines Nutzers über einen längeren Zeitraum den Zugriff auf Ihre Website zu überlassen, sodass keine Netzwerkanfragen erforderlich sind, um sie zu liefern. Oder Sie haben einen Service Worker erstellt, der eine Website vollständig offline bereitstellt, bevor geprüft wird, ob sie auf dem neuesten Stand ist. Das ist eine extreme Option, die für viele Anwendungen wie Offline-Apps verwendet wird. Das Internet muss jedoch keine extremen Cache-spezifischen oder netzwerkbedingten Extrem-Szenarien sein.
Hintergrund
Als Webentwickler sind wir alle an das Konzept eines "veralteten Cache" gewöhnt. Wir kennen jedoch fast instinktiv die verfügbaren Tools, um dieses Problem zu lösen: Sie können eine vollständige Aktualisierung durchführen, ein Inkognitofenster öffnen oder eine Kombination der Entwicklertools des Browsers verwenden, um die Daten einer Website zu löschen.
Normale Nutzer im Internet haben diesen Luxus nicht. Wir möchten vor allem dafür sorgen, dass unsere Nutzer beim zweiten Laden eine gute Zeit haben. Es ist aber auch wichtig, darauf zu achten, dass sie keine schlechte Zeit haben oder stecken bleiben. (In diesem Video erfährst du, wie wir die web.dev/live-Website fast hängen geblieben sind.)
Ein Grund für einen "veralteten Cache" ist eigentlich der Caching-Standardwert von 1999. Sie basiert auf dem Header Last-Modified:
Jede geladene Datei wird für zusätzliche 10% ihrer aktuellen Lebensdauer gespeichert, wie sie vom Browser erfasst wird. Wenn index.html beispielsweise vor einem Monat erstellt wurde, wird sie von Ihrem Browser noch etwa drei Tage lang im Cache gespeichert.
Das war schon damals eine gute Idee, aber da die Websites von heute eng miteinander verzahnt sind, kann es aufgrund dieses Standardverhaltens passieren, dass ein Nutzer Dateien für verschiedene Releases Ihrer Website erstellt hat (z.B. das JavaScript vom Dienstag-Release und das CSS vom Freitag), weil diese Dateien nicht genau zur gleichen Zeit aktualisiert wurden.
Der gut beleuchtete Pfad
Ein moderner Standard für das Caching besteht darin, überhaupt kein Caching durchzuführen und Inhalte mithilfe von CDNs in die Nähe der Nutzer zu bringen. Jedes Mal, wenn ein Nutzer Ihre Website lädt, ruft er das Netzwerk auf, um zu prüfen, ob es auf dem neuesten Stand ist. Diese Anfrage hat eine niedrige Latenz, da sie von einem CDN in der Nähe des Endnutzers bereitgestellt wird.
Sie können Ihren Webhost so konfigurieren, dass er auf Webanfragen mit diesem Header antwortet:
Cache-Control: max-age=0,must-revalidate,public
Sie besagt im Grunde, dass die Datei für keine Zeit gültig ist und Sie sie aus dem Netzwerk validieren müssen, bevor Sie sie wieder verwenden können. Andernfalls wird sie nur „vorgeschlagen“.
Diese Validierung ist in Bezug auf die übertragenen Byte relativ kostengünstig. Wenn sich eine große Bilddatei nicht geändert hat, erhält Ihr Browser eine kleine 304-Antwort. Es kostet jedoch Latenz, da der Nutzer noch zum Netzwerk gehen muss, um dies herauszufinden. Und das ist der größte Nachteil dieses Ansatzes. In der ersten Welt ist dies sehr gut für Leute mit schnellen Verbindungen geeignet, bei denen das CDN ihrer Wahl eine gute Abdeckung bietet. Für Nutzer, die langsamere Mobilfunkverbindungen oder eine schlechte Infrastruktur haben, ist sie jedoch nicht geeignet.
Unabhängig davon ist dies ein moderner Ansatz, der auf dem beliebten CDN, Netlify standardmäßig ist, aber auf nahezu jedem CDN konfiguriert werden kann. Für Firebase Hosting können Sie diesen Header im Hosting-Abschnitt der firebase.json-Datei einfügen:
"headers": [
// Be sure to put this last, to not override other headers
{
"source": "**",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=0,must-revalidate,public"
}
}
]
Ich schlage das zwar immer noch als vernünftigen Standard vor, aber es ist nur das – die Standardeinstellung! Lesen Sie weiter, um zu erfahren, wie Sie die Standardeinstellungen aktualisieren.
URLs mit Fingerabdruck
Wenn Sie einen Hash des Dateiinhalts in den Namen der auf Ihrer Website bereitgestellten Assets, Bilder usw. einfügen, sorgen Sie dafür, dass diese Dateien immer eindeutige Inhalte haben – das führt beispielsweise zu Dateien mit dem Namen sitecode.af12de.js. Wenn Ihr Server auf Anfragen für diese Dateien antwortet, können Sie die Browser Ihres Endnutzers bedenkenlos anweisen, sie für längere Zeit im Cache zu speichern, indem Sie sie mit diesem Header konfigurieren:
Cache-Control: max-age=31536000,immutable
Dieser Wert ist ein Jahr in Sekunden. Laut Spezifikation bedeutet dies quasi „für immer“.
Wichtig ist, dass diese Hashes nicht von Hand generiert werden – das ist zu viel Arbeit! Dabei können Sie Tools wie Webpack, Rollup usw. verwenden. Weitere Informationen finden Sie unter Tooling-Berichte.
Denken Sie daran, dass nicht nur JavaScript von Fingerprinting-URLs profitieren kann. Auch Assets wie Symbole, CSS und andere unveränderliche Datendateien können so benannt werden. Sehen Sie sich auch das obige Video an, um mehr über die Codeaufteilung zu erfahren, mit der Sie bei jeder Änderung Ihrer Website weniger Code senden müssen.
Unabhängig davon, wie Ihre Website das Caching angeht, sind diese Art von Fingerabdruckdateien für jede Website, die Sie erstellen, unglaublich wertvoll. Die meisten Websites ändern sich einfach nicht bei jedem Release.
Wir können unsere „freundlichen“, für Nutzer sichtbaren Seiten natürlich nicht auf diese Weise umbenennen: Umbenennen der Datei index.html in index.abcd12.html ist das nicht möglich. Du kannst Nutzer nicht dazu auffordern, jedes Mal eine neue URL aufzurufen, wenn sie deine Website laden. Diese „freundlichen“ URLs können nicht auf diese Weise umbenannt und im Cache gespeichert werden, was mich zu einem möglichen Mittelweg führt.
Mittelweg
Beim Caching gibt es offensichtlich noch Raum für einen Mittelweg. Ich habe hier zwei extreme Optionen vorgestellt: „Cache“ nie und „Cache“ für immer. Außerdem gibt es eine Reihe von Dateien, die Sie eventuell für eine Weile im Cache speichern möchten, z. B. die oben erwähnten "freundlichen" URLs.
Wenn Sie diese nutzerfreundlichen URLs und ihren HTML-Code im Cache speichern möchten, sollten Sie berücksichtigen, welche Abhängigkeiten sie enthalten, wie sie im Cache gespeichert werden können und welche Auswirkungen das zeitweise Caching ihrer URLs auf Sie haben könnte. Sehen wir uns eine HTML-Seite mit einem Bild wie diesem an:
<img src="/images/foo.jpeg" loading="lazy" />
Wenn Sie Ihre Website aktualisieren oder ändern, indem Sie dieses Lazy-Loading-Bild löschen oder ändern, erhalten Nutzer, die eine im Cache gespeicherte Version Ihrer HTML-Datei aufrufen, unter Umständen ein falsches oder fehlendes Bild, da die ursprüngliche /images/foo.jpeg-Datei beim nächsten Besuch Ihrer Website noch im Cache gespeichert war.
Wenn du vorsichtig bist, hat das möglicherweise keine Auswirkungen auf dich. Generell sollten Sie jedoch bedenken, dass Ihre Website – wenn sie von Ihren Endnutzern im Cache gespeichert wird – nicht mehr nur auf Ihren Servern vorhanden ist. Er kann vielmehr Teile in den Caches der Browser Ihres Endnutzers vorhanden sein.
Im Allgemeinen beziehen sich die meisten Leitfäden zum Caching auf diese Art von Einstellung: Sollen die Daten eine Stunde, mehrere Stunden usw. im Cache gespeichert werden? Um diese Art von Cache einzurichten, verwenden Sie einen Header wie den folgenden (der für 3.600 Sekunden oder eine Stunde im Cache gespeichert wird):
Cache-Control: max-age=3600,immutable,public
Ein letzter Punkt: Wenn Sie aktuelle Inhalte erstellen, auf die Nutzer in der Regel nur einmal zugreifen können – z. B. Nachrichtenartikel –, sollten diese niemals im Cache gespeichert werden. Sie sollten unseren vernünftigen Standardwert verwenden. Ich denke, wir überschätzen oft den Wert des Caching über dem Wunsch eines Nutzers, immer die neuesten und besten Inhalte zu sehen, z. B. ein kritisches Update zu einer Nachrichtenmeldung oder einem aktuellen Ereignis.
Nicht-HTML-Optionen
Neben HTML gibt es noch weitere Optionen für Dateien, die sich in der Zwischenablage befinden:
Suchen Sie im Allgemeinen nach Assets, die keinen Einfluss auf andere haben.
- Vermeiden Sie beispielsweise CSS, da dies zu Änderungen beim Rendering des HTML-Codes führt.
Große Bilder, die in aktuellen Artikeln verwendet werden
- Ihre Nutzer werden einen Artikel nur ein paar Mal lesen. Speichern Sie also Fotos oder Hero-Images nicht für immer im Cache
Ein Asset, das etwas repräsentiert, das selbst eine Laufzeit hat
- JSON-Daten zum Wetter werden möglicherweise nur stündlich veröffentlicht. Sie können das vorherige Ergebnis also eine Stunde lang im Cache speichern. Es ändert sich im Fenster nicht.
- Builds eines Open-Source-Projekts können ratenbegrenzt sein. Speichern Sie daher ein Build-Status-Image im Cache, bis es möglich ist, dass sich der Status ändert.
Zusammenfassung
Wenn Nutzer Ihre Website ein zweites Mal laden, haben Sie bereits überzeugt, dass sie wiederkommen und mehr von Ihrem Angebot nutzen möchten. An dieser Stelle geht es nicht immer nur darum, die Ladezeit zu verkürzen. Außerdem stehen Ihnen eine ganze Reihe von Optionen zur Verfügung, um sicherzustellen, dass Ihr Browser nur die Arbeit erledigt, die er benötigt, um sowohl eine schnelle als auch eine aktuelle Version zu bieten.
Caching ist im Web kein neues Konzept, erfordert aber möglicherweise einen vernünftigen Standard. Sie sollten einen verwenden und sich bei Bedarf verstärkt auf bessere Caching-Strategien einigen. Vielen Dank, dass Sie sich die Zeit zum Lesen dieser E-Mail genommen haben.
Weitere Informationen
Eine allgemeine Anleitung zum HTTP-Cache finden Sie unter Unnötige Netzwerkanfragen mit dem HTTP-Cache verhindern.