Wenn das Browser Caching einfach mal versagt

Von Zeit zu Zeit nutze ich GTMetrix oder das von Google angebotene PageSpeed Insights zur Leistungs­über­prüfung der von mir betreuten Webpro­jekte und um eventuelle Optimie­rungs­be­darfe zu ermitteln. 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 effizi­entere Cache-Richt­linie bereit­stellen.

Grund­sätzlich ist gegen diesen Ratschlag eigentlich 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 abgelegt sind. Und zum anderen sind es Dateien, die nur selten einer Verän­derung unter­worfen, das heißt statisch sind. Also eigentlich ideale Kandidate für ein (sehr) langes Browser Caching.

Jedoch attes­tierten mir sowohl GTMetrix als auch PageSpeed Insights für die betrof­fenen Ressourcen eine nur recht kurze Lebenszeit (Time to live, TTL): Für gerade mal bis zu 30 Tage nach dem erstma­ligen Aufruf war der Verbleib der Schrift­arten im Cache des Browsers vorge­sehen. Hier war der Hund begraben – denn eigentlich war doch was ganz anderes einge­stellt.

Das Browser Caching sollte eigentlich länger dauern

Gesteuert wird das Browser Caching im Wesent­lichen über die Server-Konfi­gu­ra­ti­ons­datei .htaccess, konkret in dem Modul­ab­schnitt mod_​expires: Hierin finden sich die von GTMetrix bzw. PageSpeed Insights zitierten „Cache-Richt­linien“ – eine Aufreihung von Datei­typen und korre­spon­die­renden TTL-Zeiten. Nachstehend 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 verwendete Caching-Plugin für WordPress – gesetzt. Hierbei ist deutlich zu erkennen, dass für Schrift­arten im WOFF2-Datei­format tatsächlich eine Gültig­keits­dauer von vier Monaten nach Zugriff bestimmt wird. Wie kommt es also zu dieser Diskrepanz?

Was ist passiert?

Nach Durch­sicht des Trouble­shooting Guides von WP Rocket und der darin empfoh­lenen Prüfung, ob das Modul mod_​expires auf dem Webserver überhaupt geladen und aktiviert wurde (Antwort: Ja, wird es), folgt eine Prüfung des in der Expires­ByType-Direktive verwen­deten MIME-Typs (Ergebnis: korrekt). Warum also werden die Schrift­arten dann mit einer Browser Caching-Zeit von nur 30 Tagen ausge­liefert?

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­sichtlich der WOFF2-Dateityp nicht als solcher erkannt, weshalb die entspre­chende Expires­ByType-Direktive auch ins Leere lief und statt­dessen die Standard-TTL von einem Monat verwendet wurde (siehe hierzu Expires­De­fault).

Eine außer­ge­wöhnlich 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 innerhalb der .htaccess, mod_​mime. Hier können wir mittels AddType-Direktive neue, bislang unbekannte Datei­typen hinzu­fügen:

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

Diesen Code-Schnipsel habe ich ganz am Anfang der .htaccess-Datei platziert. Dabei habe ich ganz bewusst darauf verzichtet, nicht einfach den von WP Rocket selbst definierten mod_mime-Block zu modifi­zieren. Denn hier ist zu befürchten, dass dieser Bereich bei einer zukünf­tigen Aktua­li­sierung des Plugins wieder umgeschrieben wird.

Und voilà: Nach der erfolg­reichen Aktua­li­sierung der .htaccess und erneuter Durch­führung der Leistungs­tests haben sowohl GTMetrix als auch PageSpeed Insights grünes Licht gegeben und das Browser Caching als gut befunden! Als Bonus hat sich durch diese Maßnahme auch der von Google errechnete Punktescore (wenngleich nur in einem geringen Umfang, aber Kleinvieh macht ja bekann­ter­maßen auch Mist) verbessert.

Zum guten Schluss

Im Nachgang habe ich die Problem­stellung und die dazuge­hörige Lösung für das Browser Caching an die Macher von WP Rocket weiter­ge­reicht, in der Hoffnung, dass dies zum Anlass genommen wird, entweder den Trouble­shooting Guide um entspre­chende Hinweise zu ergänzen oder – wenn möglich – die beschriebene AddType-Regel standard­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 Steigerung der Webseiten-Performanz auf Techniken 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: Änderungen an der .htaccess bitte nur dann durch­führen, wenn ihr euch wirklich 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 bearbeitet am 2. April 2023, 17:44.