Finde deinen Cache ❤️

Wenn Nutzer Ihre Website ein zweites Mal laden, wird ihr HTTP-Cache verwendet. Achten Sie also darauf, dass er ordnungsgemäß funktioniert.

Sam Thorogood

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 Ihre Website ein zweites Mal laden, verwendet ihr Browser Ressourcen aus seinem HTTP-Cache, um das Laden 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. Das ist aber nur die Standardeinstellung. Natürlich ist es etwas komplizierter, als die Funktion einfach nur zu deaktivieren. Am besten gleich weiterlesen!

Ziele

Wenn eine Website zum zweiten Mal geladen wird, haben Sie zwei Ziele:

1. Sorgen Sie dafür, dass Ihre Nutzer die aktuellste Version erhalten. Wenn Sie etwas geändert haben, sollte dies schnell übernommen werden.
2. Führen Sie Schritt 1 aus und laden Sie dabei so wenig wie möglich aus dem Netzwerk

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. Aber wir wissen fast instinktiv, welche Tools zur Verfügung stehen, um dieses Problem zu lösen: Wir können die Seite „hart“ aktualisieren, ein Inkognitofenster öffnen oder eine Kombination aus den Entwicklertools des Browsers verwenden, um die Daten einer Website zu löschen.

Normale Nutzer im Internet haben diesen Luxus nicht. Wir möchten, dass unsere Nutzer die zweite Ladezeit möglichst positiv erleben. Es ist aber auch wichtig, dass sie nicht frustriert sind oder nicht weiterkommen. (Im Video erzähle ich, wie wir die Website web.dev/live fast zum Absturz gebracht haben.)

Ein häufiger Grund für einen „veralteten Cache“ ist die Standardeinstellung für das Caching aus dem Jahr 1999. 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 unterschiedliche 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 die Nähe der Nutzer zu bringen. 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 bestätigen 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 Hauptnachteil dieses Ansatzes. Das kann für Nutzer mit schnellen Verbindungen in der westlichen Welt und dort, wo Ihr bevorzugtes CDN eine gute Abdeckung hat, sehr gut funktionieren, aber nicht für Nutzer mit langsameren mobilen Verbindungen oder einer schlechten 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 diesen Header in den Abschnitt „hosting“ 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“.

Wichtig: Generieren Sie diese Hash-Werte nicht manuell. Das ist zu viel manuelle Arbeit. 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 veröffentlichen.

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 „nutzerfreundlichen“ URLs können auf diese Weise nicht umbenannt und im Cache gespeichert werden. Das bringt mich zu einer möglichen Kompromisslösung.

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 sich überlegen, 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 mit einem solchen Bild an:

<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. Vielmehr kann sie in Teilstücken in den Caches der Browser Ihrer Endnutzer vorhanden sein.

In den meisten Anleitungen zum Caching wird diese Art von Einstellung erwähnt: Soll der Cache für eine Stunde, mehrere Stunden usw. verwendet werden? Verwenden Sie zum Einrichten dieser Art von Cache einen Header wie diesen, der die Daten für 3.600 Sekunden (eine Stunde) im Cache speichert:

Cache-Control: max-age=3600,immutable,public

Noch 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 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 zum Wetter werden möglicherweise nur stündlich veröffentlicht. Sie können das vorherige Ergebnis also eine Stunde lang im Cache speichern, da es sich in diesem Zeitraum nicht ändern wird.
  • Builds eines Open-Source-Projekts sind möglicherweise ratenbegrenzt. Daher sollten Sie ein Bild des Build-Status im Cache speichern, bis der Status sich 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 kein neues Konzept im Web, aber vielleicht braucht es eine sinnvolle Standardeinstellung. Sie sollten sie verwenden und bei Bedarf unbedingt bessere Caching-Strategien aktivieren. Vielen Dank, dass Sie sich die Zeit zum Lesen dieser E-Mail genommen haben.

Weitere Informationen

Einen allgemeinen Leitfaden zum HTTP-Cache finden Sie unter Unnötige Netzwerkanfragen mit dem HTTP-Cache verhindern.