Nutzer, die Ihre Website ein zweites Mal laden, verwenden ihren HTTP-Cache. Stellen Sie daher sicher, gut funktioniert.
Dieser Beitrag ist eine Ergänzung zum Video Love your cache, Teil der erweiterten Inhalte vom Chrome Dev Summit 2020. Sehen Sie sich auf jeden Fall dieses Video an:
Wenn Nutzer deine Website ein zweites Mal laden, verwendet ihr Browser die darin enthaltenen Ressourcen um die Ladezeit zu verkürzen. Die Standards für das Caching auf Das Web reicht bis ins Jahr 1999 zurück. Sie sind ziemlich weit gefasst und bestimmen, ob eine Datei, z. B. CSS oder ein Bild, erneut aus dem Netzwerk abgerufen wird im Vergleich zum aus dem Cache geladenen, ist eine ungenaue Wissenschaft.
In diesem Beitrag stelle ich Ihnen einen sinnvollen, modernen Standard für das Caching vor – eine, die überhaupt kein Caching. Aber das ist nur die Standardeinstellung, differenzierter zu gestalten, als nur „Ausschalten“. 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 sollte sich dies schnell widerspiegeln,
- Erster Schritt und so wenig wie möglich aus dem Netzwerk abrufen
Im Allgemeinen möchten Sie nur die kleinste Änderung an Ihre Kunden senden. wenn sie Ihre Website erneut laden. Strukturieren Sie Ihre Website so, ist eine effiziente Verteilung von Änderungen eine Herausforderung (mehr dazu weiter unten und in des Videos).
Allerdings gibt es noch weitere Möglichkeiten, wenn Sie Caching verwenden möchten, Sie sich entschieden haben, den HTTP-Cache eines Nutzers im Browser eines Nutzers lange auf Ihrer Website zu speichern sodass keine Netzwerkanfragen mehr nötig sind. Oder Sie haben hat einen Service Worker konstruiert, der eine Website vollständig offline bereitstellt, bevor ob sie auf dem neuesten Stand sind. Dies ist eine Extrem-Option, die gültig – und viele App-ähnliche Weberlebnisse bieten, die offline genutzt werden. Das muss in einem extremen Cache, aber sogar nur im Netzwerk.
Hintergrund
Als Webentwickler sind wir alle daran gewöhnt, einen „veralteten Cache“ zu haben. Aber wir wissen – fast instinktiv – die verfügbaren Tools, um dieses Problem zu lösen: Aktualisieren" bzw. ein Inkognitofenster öffnen oder eine Kombination der Browsereinstellungen um die Daten einer Website zu löschen.
Regelmäßige Internetnutzer haben diesen Luxus nicht. Während wir dass unsere Nutzer auch beim zweiten Mal Spaß haben. geladen werden, ist es auch wichtig, darauf zu achten, dass es keine schlechten Zeiten oder nicht weiterkommen. (In diesem Video erläutere ich, beinahe zum Ende der Website web.dev/live)
Ein Grund für einen überflüssigen Cache ist eigentlich
der Standard für das Caching seit 1999. Es basiert auf dem Last-Modified-Header:
Jede geladene Datei wird für weitere 10% ihrer aktuellen Lebensdauer beibehalten,
vom Browser erkannt wird. Wenn beispielsweise index.html vor einem Monat erstellt wurde,
wird er für etwa drei weitere Tage im Cache gespeichert.
Das war damals eine gute Idee, aber angesichts der der heutigen Websites integriert ist, kann dieses Standardverhalten in einen Zustand versetzt werden, in dem ein Nutzer Dateien für verschiedene (z.B. das JS vom Release vom Dienstag und das CSS vom Freitags-Release weil diese Dateien nicht zur gleichen Zeit aktualisiert wurden.
Gut beleuchtete Wege
Ein moderner Standard für das Caching besteht darin, überhaupt kein Caching zu verwenden. CDNs für mehr Nutzerfreundlichkeit für Ihre Nutzer. Jedes Mal, wenn ein Nutzer Ihre Website lädt, ob sie auf dem neuesten Stand sind. Diese Anfrage hat eine niedrige Latenz, die von einem CDN bereitgestellt werden, das sich geografisch in der Nähe der Endnutzer befindet.
Sie können Ihren Webhost so konfigurieren, dass er auf Webanfragen mit folgendem Header antwortet:
Cache-Control: max-age=0,must-revalidate,public
Sie lautet im Grunde: die Datei für keine Zeit gültig ist, und Sie müssen aus dem Netzwerk entfernen, bevor Sie sie erneut verwenden können. Andernfalls ist es nur „vorgeschlagen“).
Dieser Validierungsprozess ist in Bezug auf die übertragenen Byte relativ günstig, wenn ein große Bilddatei nicht geändert hat, erhält Ihr Browser eine kleine 304-Fehlermeldung aber es kostet Latenz, da ein Nutzer noch ins Netzwerk gehen muss, aus. Und das ist der größte Nachteil dieses Ansatzes. Es kann sehr gut funktionieren, für Nutzer mit schnellen Verbindungen in der ersten Welt und mit dem CDN Ihrer Wahl gute Abdeckung, aber nicht für Nutzer mit langsameren oder schlechte Infrastruktur.
Unabhängig davon ist dies ein moderner Ansatz, Standardeinstellung im beliebten CDN ist Netlify, kann aber in fast jedem CDN konfiguriert werden. Für Firebase Hosting können Sie diese Überschrift im Bereich „Hosting“ der Datei firebase.json:
"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 dies 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 können.
URLs mit Fingerabdruck
Indem ein Hash des Dateiinhalts z. B. in die Namen von Assets oder Bildern eingebunden wird,
auf Ihrer Website ausgeliefert werden, können Sie dafür sorgen, dass diese Dateien
Inhalt: dies führt beispielsweise zu Dateien mit dem Namen sitecode.af12de.js. Wann?
wenn Ihr Server auf Anfragen nach diesen Dateien reagiert, können Sie Ihren Server
Endnutzer lange im Cache gespeichert werden. Dazu konfigurieren sie diese
Überschrift:
Cache-Control: max-age=31536000,immutable
Dieser Wert ist ein Jahr in Sekunden. Laut Spezifikation ist dies gleich „für immer“.
Generieren Sie diese Hashes jedoch nicht von Hand – das ist zu viel manuellen Aufwand! Ich Tools wie Webpack, Rollup usw. können Ihnen dabei helfen. Achten Sie darauf, Weitere Informationen zu Toolberichten
Denken Sie daran, dass nicht nur JavaScript von Fingerprinting-URLs profitieren kann. Assets wie Symbole, CSS und andere unveränderliche Datendateien (Sehen Sie sich auch das Video oben an, um mehr über Code Aufteilung, sodass Sie bei jeder Änderung Ihrer Website weniger Code senden müssen.)
Unabhängig davon, wie Ihre Website an das Caching herangeht, werden diese sind für jede Website unglaublich wertvoll. Die meisten Websites nicht bei jedem Release.
Natürlich können wir unsere "nutzerfreundlichen" Seiten nicht wie folgt umbenennen:
Ihre index.html-Datei auf index.abcd12.html umzustellen. Das ist nicht machbar,
Nutzer müssen bei jedem Laden Ihrer Website eine neue URL aufrufen. Diese "freundlichen" URLs
nicht auf diese Weise umbenannt und im Cache gespeichert werden.
auf dem Boden.
Der Mittelweg
Beim Caching gibt es natürlich Raum für einen Mittelweg. Ich habe stellten zwei extreme Optionen vor: nie oder immer im Cache speichern. Und dann gibt es eine Reihe von Dateien sein, die Sie vielleicht eine Zeit lang im Cache speichern möchten, z. B. "freundlich" die oben erwähnten URLs.
Wenn Sie diese "nutzerfreundlichen" und deren HTML-Code enthält, lohnt es sich, Überlegen Sie, welche Abhängigkeiten sie enthalten, wie sie im Cache gespeichert werden und wie die URLs vorübergehend im Cache gespeichert werden. Sehen wir uns eine HTML-Seite an, enthält ein Bild wie dieses:
<img src="/images/foo.jpeg" loading="lazy" />
Wenn Sie Ihre Website durch Löschen oder Ändern dieses Lazy-Loading-Vorgangs aktualisieren oder ändern
angezeigt wird, erhalten Nutzer, die eine im Cache gespeicherte Version Ihres HTML-Codes anzeigen, möglicherweise ein falsches oder
fehlendes Bild vorhanden ist, da das ursprüngliche /images/foo.jpeg-Element noch im Cache gespeichert wurde,
wenn sie Ihre Website erneut besuchen.
Wenn Sie vorsichtig sind, hat dies möglicherweise keine Auswirkungen auf Sie. Aber allgemein ist es wichtig, dass Ihre Website – wenn sie von Ihren Endnutzern im Cache gespeichert wird – nicht mehr auf auf euren Servern. Es kann vielmehr in Teilen in den Caches der Browser.
Im Allgemeinen wird in den meisten Leitfäden zum Caching über diese Art von Einstellung: Möchten Sie eine Stunde, mehrere Stunden usw. im Cache speichern? Um dies festzulegen verwendet einen Header wie diesen (der für 3600 Sekunden oder Stunde):
Cache-Control: max-age=3600,immutable,public
Ein letzter Punkt: Wenn ihr aktuelle Inhalte erstellt, die in der Regel wie Nachrichtenartikeln nur einmal aufgerufen werden. Meiner Meinung nach sollten diese und Sie sollten den oben genannten sinnvollen Standardwert verwenden. Ich denke, wir oft überschätzen Sie den Wert des Cachings gegenüber dem Wunsch der Nutzenden, immer die aktuellsten und interessantesten Content wie kritische Neuerungen zu einem Nachrichtenthema oder aktuelle .
Nicht-HTML-Optionen
Neben HTML gibt es noch weitere Optionen für Dateien, die in der Mitte umfassen:
Achten Sie im Allgemeinen auf Assets, die keine Auswirkungen auf andere haben.
- Vermeiden Sie beispielsweise CSS, da dies zu Änderungen am HTML-Code gerendert
Große Bilder, die als Teil aktueller Artikel verwendet werden
- Ihre Nutzer werden wahrscheinlich keinen einzelnen Artikel mehr lesen, Speichern Sie Fotos oder Hero-Images also nicht ewig im Cache. Abfalllagerung
Ein Asset, das etwas repräsentiert, das selbst eine Lebensdauer hat
- JSON-Daten über das Wetter werden möglicherweise nur stündlich veröffentlicht, können Sie das vorherige Ergebnis eine Stunde lang im Cache speichern. Es ändert sich in Ihrem Fenster nicht.
- Für die Builds eines Open-Source-Projekts gelten möglicherweise Ratenbegrenzungen. Speichern Sie Build-Status-Image, bis sich der Status möglicherweise ändert.
Zusammenfassung
Wenn Nutzer Ihre Website ein zweites Mal laden, haben Sie bereits Selbstvertrauen – sie möchten wiederkommen, um mehr von dem zu bekommen, was Sie anbieten. In dieser Es geht nicht immer nur darum, die Ladezeit zu verkürzen. Ihnen eine Reihe von Optionen zur Verfügung, mit denen Sie sicherstellen können, dass Ihr Browser nur die Arbeit übernimmt, muss es sowohl schnell als auch aktuell sein.
Caching ist im Web kein neues Konzept, aber vielleicht braucht es ein vernünftiges Standardeinstellung: Verwenden Sie eine davon und aktivieren Sie deutlich bessere Caching-Strategien. wenn Sie sie brauchen. Vielen Dank, dass Sie sich die Zeit zum Lesen dieser E-Mail genommen haben.
Weitere Informationen
Eine allgemeine Anleitung zum HTTP-Cache findest du unter Verhindern Sie mit dem HTTP-Cache unnötige Netzwerkanfragen.