Wenn das Browser Caching einfach mal versagt

Von Zeit zu Zeit nutze ich GTMe­trix oder das von Google ange­bo­tene Page­Speed Insights zur Leis­tungs­über­prü­fung der von mir betreuten Webpro­jekte und um even­tu­elle Opti­mie­rungs­be­darfe zu ermit­teln. Zuletzt nahm ich mir hierfür meine eigene Webseite vor und bekam hierbei von beiden Tools den Hinweis, ich möge doch für meine verwen­deten Schrift­arten eine effi­zi­en­tere Cache-Richt­linie bereit­stellen.

Grund­sätz­lich ist gegen diesen Ratschlag eigent­lich nichts einzu­wenden: Zum einen handelt es sich bei den Schriftart-Dateien um verhält­nis­mäßig große Dateien, selbst wenn diese – wie in meinem Fall – im modernen WOFF2-Format abge­legt sind. Und zum anderen sind es Dateien, die nur selten einer Verän­de­rung unter­worfen, das heißt statisch sind. Also eigent­lich ideale Kandi­date für ein (sehr) langes Browser Caching.

Jedoch attes­tierten mir sowohl GTMe­trix als auch Page­Speed Insights für die betrof­fenen Ressourcen eine nur recht kurze Lebens­zeit (Time to live, TTL): Für gerade mal bis zu 30 Tage nach dem erst­ma­ligen Aufruf war der Verbleib der Schrift­arten im Cache des Brow­sers vorge­sehen. Hier war der Hund begraben – denn eigent­lich war doch was ganz anderes einge­stellt.

Das Browser Caching sollte eigent­lich länger dauern

Gesteuert wird das Browser Caching im Wesent­li­chen über die Server-Konfi­gu­ra­ti­ons­datei .htac­cess, konkret in dem Modul­ab­schnitt mod_​expires: Hierin finden sich die von GTMe­trix bzw. Page­Speed Insights zitierten „Cache-Richt­li­nien“ – eine Aufrei­hung von Datei­typen und korre­spon­die­renden TTL-Zeiten. Nach­ste­hend ein Auszug aus dem Modul­ab­schnitt meiner .htacces-Datei:

<IfModule mod_expires.c>
	ExpiresActive on
	ExpiresDefault                              "access plus 1 month"
	# Webfonts
	ExpiresByType font/ttf                      "access plus 4 months"
	ExpiresByType font/otf                      "access plus 4 months"
	ExpiresByType font/woff                     "access plus 4 months"
	ExpiresByType font/woff2                    "access plus 4 months"
</IfModule>

Die Angaben wurden zuvor von WP Rocket – dass von mir verwen­dete Caching-Plugin für Word­Press – gesetzt. Hierbei ist deut­lich zu erkennen, dass für Schrift­arten im WOFF2-Datei­format tatsäch­lich eine Gültig­keits­dauer von vier Monaten nach Zugriff bestimmt wird. Wie kommt es also zu dieser Diskre­panz?

Was ist passiert?

Nach Durch­sicht des Trou­ble­shoo­ting Guides von WP Rocket und der darin empfoh­lenen Prüfung, ob das Modul mod_​expires auf dem Webserver über­haupt geladen und akti­viert wurde (Antwort: Ja, wird es), folgt eine Prüfung des in der Expi­res­By­Type-Direk­tive verwen­deten MIME-Typs (Ergebnis: korrekt). Warum also werden die Schrift­arten dann mit einer Browser Caching-Zeit von nur 30 Tagen ausge­lie­fert?

Die Antwort ergibt sich, wenn man sich mod_​expires als eine Kette von Wenn-Dann-Befehlen vorstellt, also etwa wie folgt:

„Wenn Dateityp=A, dann nimm Zeit Z₁; wenn Dateityp=C, dann nimm Zeit Z₂ und wenn Dateityp=unbekannt, dann nimm Zeit Z₃.“

In meinem Fall wurde offen­sicht­lich der WOFF2-Dateityp nicht als solcher erkannt, weshalb die entspre­chende Expi­res­By­Type-Direk­tive auch ins Leere lief und statt­dessen die Stan­dard-TTL von einem Monat verwendet wurde (siehe hierzu Expi­res­De­fault).

Eine außer­ge­wöhn­lich simple Lösung

Mit dieser Erkenntnis liegt die Lösung im Grunde auf der Hand: Wir müssen dem Webserver den korrekten Dateityp beibringen. Hierzu hilft uns zum Glück ein weiteres Server-Modul inner­halb der .htac­cess, mod_​mime. Hier können wir mittels AddType-Direk­tive neue, bislang unbe­kannte Datei­typen hinzu­fügen:

<IfModule mod_mime.c>
	AddType font/woff2          woff2
</IfModule>

Diesen Code-Schnipsel habe ich ganz am Anfang der .htac­cess-Datei plat­ziert. Dabei habe ich ganz bewusst darauf verzichtet, nicht einfach den von WP Rocket selbst defi­nierten mod_­mime-Block zu modi­fi­zieren. Denn hier ist zu befürchten, dass dieser Bereich bei einer zukünf­tigen Aktua­li­sie­rung des Plugins wieder umge­schrieben wird.

Und voilà: Nach der erfolg­rei­chen Aktua­li­sie­rung der .htac­cess und erneuter Durch­füh­rung der Leis­tungs­tests haben sowohl GTMe­trix als auch Page­Speed Insights grünes Licht gegeben und das Browser Caching als gut befunden! Als Bonus hat sich durch diese Maßnahme auch der von Google errech­nete Punk­tes­core (wenn­gleich nur in einem geringen Umfang, aber Klein­vieh macht ja bekann­ter­maßen auch Mist) verbes­sert.

Zum guten Schluss

Im Nach­gang habe ich die Problem­stel­lung und die dazu­ge­hö­rige Lösung für das Browser Caching an die Macher von WP Rocket weiter­ge­reicht, in der Hoff­nung, dass dies zum Anlass genommen wird, entweder den Trou­ble­shoo­ting Guide um entspre­chende Hinweise zu ergänzen oder – wenn möglich – die beschrie­bene AddType-Regel stan­dard­mäßig hinzu­zu­fügen.

Es ist im Übrigen nicht auszu­schließen, dass die gleiche Proble­matik auch bei anderen Plugins, die zur Stei­ge­rung der Webseiten-Perfor­manz auf Tech­niken wie das Browser Caching setzen, zum Vorschein kommen kann. Sollte ich mich noch einmal mit dem Thema Browser Caching befassen oder entspre­chende Hinweise bekommen, werde ich es an dieser Stelle publi­zieren.

Am Ende noch eine Warnung: Ände­rungen an der .htac­cess bitte nur dann durch­führen, wenn ihr euch wirk­lich eurer Sache sicher seid. Denn wie dieses Beispiel zum Browser Caching zeigt, können hier einfache Dinge eine ganz große Wirkung entfalten!

Beitrag zuletzt bear­beitet am 2. April 2023, 17:44.