Wenn Nutzer Ihre Website ein zweites Mal laden, wird ihr HTTP-Cache verwendet. Achten Sie also darauf, dass er ordnungsgemäß funktioniert.
Dieser Beitrag ist eine Ergänzung zum Video Love your cache (Lieben Sie Ihren Cache), das Teil der erweiterten Inhalte des Chrome Dev Summit 2020 ist. Sehen Sie sich das Video an:
Wenn Nutzer deine Website ein zweites Mal laden, verwendet der Browser Ressourcen im HTTP-Cache, um den Ladevorgang zu beschleunigen. Die Standards für das Caching im Web stammen jedoch aus dem Jahr 1999 und sind ziemlich weit gefasst. Es ist also nicht ganz einfach zu bestimmen, ob eine Datei wie CSS oder ein Bild noch einmal aus dem Netzwerk abgerufen oder aus dem Cache geladen werden soll.
In diesem Beitrag erkläre ich eine sinnvolle, moderne Standardeinstellung für das Caching, bei der überhaupt kein Caching erfolgt. Aber das ist nur die Standardeinstellung, die natürlich differenzierter ist, als sie nur zu "deaktivieren". Am besten gleich weiterlesen!
Ziele
Wenn eine Website zum zweiten Mal geladen wird, haben Sie zwei Ziele:
- Sorgen Sie dafür, dass Ihre Nutzer die aktuellste Version erhalten. Wenn Sie etwas geändert haben, sollte dies schnell übernommen werden.
- Erster Schritt und so wenig wie möglich aus dem Netzwerk abrufen
Im weitesten Sinne sollten Sie Ihren Kunden nur die kleinste Änderung senden, wenn sie Ihre Website noch einmal laden. Und die Website so zu strukturieren, dass Änderungen möglichst effizient verteilt werden, ist eine Herausforderung. Weitere Informationen dazu finden Sie unten und im Video.
Beim Caching gibt es aber noch weitere Optionen. Vielleicht möchten Sie, dass der HTTP-Cache des Browsers eines Nutzers Ihre Website lange speichert, damit für die Bereitstellung keine Netzwerkanfragen erforderlich sind. Oder Sie haben einen Service Worker erstellt, der eine Website vollständig offline bereitstellt, bevor er prüft, ob sie auf dem neuesten Stand ist. Das ist eine extreme Option, die gültig ist und für viele Offline-first-Webanwendungen verwendet wird. Das Web muss jedoch nicht nur aus dem Cache oder nur aus dem Netzwerk bestehen.
Hintergrund
Als Webentwickler sind wir alle mit dem Begriff „veralteter Cache“ vertraut. Wir kennen jedoch fast instinktiv die verfügbaren Tools, um dieses Problem zu lösen: Führen Sie eine "vollständige Aktualisierung" oder das Öffnen eines Inkognito-Fensters durch oder verwenden Sie eine Kombination der Entwicklertools Ihres Browsers, um die Daten einer Website zu löschen.
Regelmäßige Internetnutzer haben diesen Luxus nicht. Unser Hauptziel besteht also darin, sicherzustellen, dass unsere Nutzer auch mit ihrem zweiten Ladevorgang Spaß haben. Es ist aber auch wichtig, dass sie keine schlechten Zeit haben oder nicht weiterkommen. (Im Video erzähle ich, wie wir die Website web.dev/live fast zum Absturz gebracht haben.)
Ein Grund für einen „veralteten Cache“ ist hier zum Beispiel der Standard aus den 1999er-Jahren für das Caching. Sie basiert auf dem Last-Modified-Header:
Jede von Ihnen geladene Datei wird für weitere 10 % ihrer aktuellen Lebensdauer aufbewahrt, wie sie von Ihrem Browser gesehen wird. Wenn index.html beispielsweise vor einem Monat erstellt wurde, wird es noch etwa drei Tage lang von Ihrem Browser im Cache gespeichert.
Das war damals eine gut gemeinte Idee, aber angesichts der engen Integration der heutigen Websites kann dieses Standardverhalten dazu führen, dass ein Nutzer Dateien für verschiedene Releases Ihrer Website hat (z.B. das JS aus der Dienstagsversion und das CSS aus der Freitagsversion), weil diese Dateien nicht genau zur selben Zeit aktualisiert wurden.
Der gut beleuchtete Weg
Eine moderne Standardeinstellung für das Caching besteht darin, überhaupt kein Caching durchzuführen und CDNs zu verwenden, um Ihre Inhalte in der Nähe Ihrer Nutzer zu platzieren. Jedes Mal, wenn ein Nutzer Ihre Website lädt, wird geprüft, ob sie auf dem neuesten Stand ist. Diese Anfrage hat eine geringe Latenz, da sie von einem CDN bereitgestellt wird, das sich geografisch in der Nähe des jeweiligen Endnutzers befindet.
Sie können Ihren Webhost so konfigurieren, dass er auf Webanfragen mit diesem Header antwortet:
Cache-Control: max-age=0,must-revalidate,public
Das bedeutet, dass die Datei nur sehr kurz gültig ist und Sie sie im Netzwerk validieren müssen, bevor Sie sie wieder verwenden können. Andernfalls wird sie nur „vorgeschlagen“.
Dieser Validierungsprozess ist in Bezug auf die übertragenen Bytes relativ kostengünstig. Wenn sich eine große Bilddatei nicht geändert hat, erhält der Browser eine kleine 304-Antwort. Es entstehen jedoch Latenzanforderungen, da der Nutzer das Netzwerk noch aufrufen muss, um dies herauszufinden. Und das ist der größte Nachteil dieses Ansatzes. Sie eignet sich sehr gut für Nutzer mit schnellen Verbindungen in der ersten Welt und wenn das CDN Ihrer Wahl eine hervorragende Abdeckung hat. Dies gilt jedoch nicht für Nutzer mit langsameren Mobilfunkverbindungen oder schlechter Infrastruktur.
Unabhängig davon ist dies ein moderner Ansatz, der bei einem beliebten CDN, Netlify, standardmäßig verwendet wird, aber bei fast jedem CDN konfiguriert werden kann. Für Firebase Hosting können Sie diese Überschrift in den Hostingbereich Ihrer 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 empfehle diese Einstellung zwar weiterhin als sinnvolle Standardeinstellung, aber sie ist eben nur das: die Standardeinstellung. Im Folgenden erfahren Sie, wie Sie die Standardeinstellungen ändern können.
URLs mit Fingerabdrücken
Wenn Sie einen Hashwert des Dateiinhalts in den Namen von Assets, Bildern usw. aufnehmen, die auf Ihrer Website bereitgestellt werden, können Sie dafür sorgen, dass diese Dateien immer einen eindeutigen Inhalt haben. Dies 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 der Endnutzer sicher anweisen, sie für einen langen Zeitraum im Cache zu speichern, indem Sie sie mit diesem Header konfigurieren:
Cache-Control: max-age=31536000,immutable
Dieser Wert entspricht einem Jahr in Sekunden. Gemäß der Spezifikation entspricht dies praktisch „für immer“.
Generieren Sie diese Hashes jedoch nicht von Hand – das ist zu viel manuellen Aufwand! Sie können Tools wie Webpack oder Rollup verwenden, um Ihnen dabei zu helfen. Weitere Informationen finden Sie im Tooling Report.
Denken Sie daran, dass nicht nur JavaScript von Fingerabdruck-URLs profitieren kann. Auch Assets wie Symbole, CSS und andere unveränderliche Datendateien können so benannt werden. Sehen Sie sich das Video oben an, um mehr über das Code-Splitting zu erfahren. So können Sie bei Änderungen an Ihrer Website weniger Code bereitstellen.
Unabhängig davon, wie Sie das Caching auf Ihrer Website handhaben, sind diese Dateien mit Fingerabdrücken für jede Website, die Sie erstellen, äußerst wertvoll. Die meisten Websites ändern sich einfach nicht bei jeder Version.
Natürlich können wir unsere „nutzerfreundlichen“ Seiten nicht auf diese Weise umbenennen: Die Datei index.html in index.abcd12.html umbenennen – das ist nicht möglich. Sie können Nutzern nicht sagen, dass sie jedes Mal, wenn sie Ihre Website laden, eine neue URL aufrufen sollen. Diese "freundlichen" URLs können nicht auf diese Weise umbenannt und im Cache gespeichert werden, was mich an einen möglichen Mittelweg bringt.
Der Mittelweg
Beim Caching gibt es natürlich einen Mittelweg. Ich habe zwei extreme Optionen vorgestellt: Nie oder für immer im Cache speichern. Es gibt auch eine Reihe von Dateien, die Sie für eine gewisse Zeit im Cache speichern möchten, z. B. die oben genannten „nutzerfreundlichen“ URLs.
Wenn Sie diese „nutzerfreundlichen“ URLs und deren 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 vorübergehende Caching ihrer URLs auf Sie haben könnte. Sehen wir uns eine HTML-Seite an, die ein Bild wie dieses enthält:
<img src="/images/foo.jpeg" loading="lazy" />
Wenn Sie Ihre Website aktualisieren oder ändern, indem Sie dieses Lazy-Load-Bild löschen oder ändern, sehen Nutzer, die eine im Cache gespeicherte Version Ihrer HTML-Seite aufrufen, möglicherweise ein falsches oder fehlendes Bild, da sie beim erneuten Aufrufen Ihrer Website immer noch die ursprüngliche /images/foo.jpeg im Cache haben.
Wenn Sie vorsichtig sind, wirkt sich das möglicherweise nicht auf Sie aus. Generell ist es jedoch wichtig zu wissen, dass Ihre Website, wenn sie von Endnutzern im Cache gespeichert wird, nicht mehr nur auf Ihren Servern vorhanden ist. Es kann vielmehr in Teilen in den Caches der Browser Ihrer Endnutzer vorhanden sein.
In den meisten Anleitungen zum Caching wird diese Art der Einstellung erwähnt: Soll der Cache für eine Stunde, mehrere Stunden usw. verwendet werden? Um diese Art von Cache einzurichten, verwenden Sie einen Header wie diesen (der Cache für 3.600 Sekunden oder eine Stunde im Cache speichert):
Cache-Control: max-age=3600,immutable,public
Ein letzter Punkt: Wenn Sie aktuelle Inhalte erstellen, auf die Nutzer in der Regel nur einmal zugreifen, z. B. Nachrichtenartikel, sollten diese meiner Meinung nach niemals im Cache gespeichert werden. Verwenden Sie stattdessen die oben genannte sinnvolle Standardeinstellung. Ich denke, wir überschätzen oft den Wert des Cachings im Vergleich zum Wunsch der Nutzer, immer die neuesten und besten Inhalte zu sehen, z. B. eine wichtige Aktualisierung zu einer Nachrichtenmeldung oder einem aktuellen Ereignis.
Nicht-HTML-Optionen
Neben HTML gibt es noch weitere Optionen für Dateien, die sich in der Mitte befinden:
Suchen Sie generell nach Assets, die sich nicht auf andere auswirken.
- Beispiel: Vermeiden Sie CSS, da es Änderungen an der Darstellung Ihrer HTML-Datei bewirkt.
Große Bilder, die in aktuellen Artikeln verwendet werden
- Ihre Nutzer werden einen einzelnen Artikel wahrscheinlich nicht mehr als ein paar Mal aufrufen. Speichern Sie also keine Fotos oder Hero-Bilder für immer im Cache und verschwenden Sie keinen Speicherplatz.
Ein Asset, das etwas darstellt, das selbst eine Lebensdauer hat
- JSON-Daten über das Wetter werden möglicherweise nur stündlich veröffentlicht, sodass Sie das vorherige Ergebnis eine Stunde lang im Cache speichern können. Es ändert sich in Ihrem Fenster nicht.
- Builds eines Open-Source-Projekts sind möglicherweise ratenbegrenzt. Daher sollten Sie ein Bild mit dem Build-Status im Cache speichern, bis sich der Status möglicherweise ändert.
Zusammenfassung
Wenn Nutzer Ihre Website ein zweites Mal laden, haben Sie bereits ein gewisses Maß an Vertrauen gewonnen: Sie möchten wiederkommen und mehr von Ihrem Angebot sehen. An dieser Stelle geht es nicht immer nur darum, die Ladezeit zu verkürzen. Es gibt eine Reihe von Optionen, mit denen Sie dafür sorgen können, dass Ihr Browser nur die Arbeit erledigt, die für eine schnelle und aktuelle Nutzung erforderlich ist.
Caching ist im Web kein neues Konzept, aber vielleicht braucht es einen vernünftigen Standard. Erwägen Sie die Verwendung eines solchen Konzepts und aktivieren Sie bei Bedarf bessere Caching-Strategien. 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 Mit dem HTTP-Cache unnötige Netzwerkanfragen verhindern.