Cooles Caching

"Your Cache Headers Could Probably be More Aggressive" findet Alex MacArthur und beschreibt in seinem Artikel sehr gut verständlich und auf den Punkt, wie man damit aus seiner Sicht am besten umgeht:

• Ein Default-Setting, dass für möglichst viele verschiedene Nutzerinnen passt, ist sinnvoll: Cache-Control header = public, max-age=0, must-revalidate zusammen mit einem Etag

• Es gibt jedoch Ressourcen, bei denen sich extrem selten etwas ändert, weswegen man sie durchaus großzügig cachen kann sollte: Cache-Control header = public, max-age=31560000, immutable

• Falls sich doch was tut, gibt es Wege, die neueste Version umgehend an den Browser zu bringen, egal was im Caching steht: Fingerprinting for the win!

Wie? Was? Wenn Dir das ein wenig zu schnell ging, hier nochmal etwas ausführlicher:

Durchgreifender Default

Mit public, max-age=0, must-revalidate teilen wir mit, dass die Ressource zwar gecached werden kann. Direkt beim nächsten Aufruf wird jedoch anhand des Etags geprüft, ob es eine neue Version gibt. Falls ja, wird diese dann auch heruntergeladen. Wenn es keine neue Version gibt, bekommen wir einen Status Code 304 Not Modified zurück und der Browser nimmt die Version, die er bereits im Cache hat. Das ist, so Alex, als Default-Setting smart und sinnvoll.

Es gibt Dinge, die sich nie (oder nur sehr selten) ändern: CSS, Fonts, Bilder, JavaSscript. Wenn diese dann mit extrem hoher Wahrscheinlichkeit einen Status Code 304 Not Modified liefern, ist es eigentlich unnötig, diesen Dialog jedes Mal zu durchlaufen. Vorhang auf für public, max-age=31560000, immutable. Nun kann die betreffende Ressource gecached werden und ist quasi ein Jahr haltbar. Dabei bekommt der Browser sogar die ganz klare Vorgabe, unter keinen Umständen nachzufragen, ob es eine neuere Version gibt.

"immutable - the browser is explicitly instructed to NOT reach out to origin/CDN just to check if something newer is available (no more revalidation requests)

Wenn man die Seite also einmal aufgerufen und die Assets geladen hat, kommen sie ab dann immer direkt aus dem Cache. Erst nach Ablauf eines Jahres schaut der Browser wieder, ob es eine neuere Version gibt.

Fingerprinting für Frische

Zum Glück muss man sich keine Sorgen machen, wenn sich doch mal etwas ändert, obwohl man einer Ressource als Caching-Zeitraum ein Jahr mitgegeben hat. Fingerprinting (mancherorts auch "Cache Busting") heißt der Trick. Denn wenn ein neues Asset unter einer neuen URL liegt, dann holt sich der Browser das auf jeden Fall einmal her. Egal, wie lange die vorherige Version der betreffenden Ressource noch gültig gewesen wäre.

Dabei sollte man unbedingt auch den Umkehrschluss ziehen: Ressourcen, deren URL sich in der Regel nicht ändern, sollten vermutlich nicht ewig gecached werden, insbesondere wenn häufigere Änderungen üblich oder zu erwarten sind. Zum Beispiel das HTML der Startseite. Denn diese URL bleibt dauerhaft bestehen und hat sozusagen eine größere "Haltbarkeit" als beispielsweise die leicht veränderbaren URLs von CSS- oder JS-Dateien. In dem Fall also nicht auf Fingerprinting setzen und eher vorsichtig sein beim Caching!

Alex hält in seinem Artikel dann noch ein paar praktische Tipps bereit, wie Du das konkret umsetzen kannst.

Mir hat der Beitrag gut gefallen. Denn Caching ist ein super Hebel, um an den Ladezeit zu schrauben. Trotzdem sieht man da immer wieder große Fragezeichen vor den Augen, wenn es darum geht, was man denn jetzt am besten wie cached. Sicherlich gibt es Fälle, in denen es kompliziert ist. Aber grundsätzlich kommt man mit dem vorgestellten Ansatz schon ganz weit. Also kannst Du am besten gleich mal nachschauen, wie das denn aktuell auf Deiner Webseite gelöst ist...