Wenn das Browser Caching einfach versagt
Von Zeit zu Zeit nutze ich GTMetrix oder das von Google angebotene PageSpeed Insights zur Leistungsüberprüfung der von mir betreuten Webprojekte und um eventuelle Optimierungsbedarfe 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 verwendeten Schriftarten eine effizientere Cache-Richtlinie bereitstellen.
Grundsätzlich ist gegen diesen Ratschlag eigentlich nichts einzuwenden: Zum einen handelt es sich bei den Schriftart-Dateien um verhältnismäß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änderung unterworfen, das heißt statisch sind. Also eigentlich ideale Kandidate für ein (sehr) langes Browser Caching.
Jedoch attestierten mir sowohl GTMetrix als auch PageSpeed Insights für die betroffenen Ressourcen eine nur recht kurze Lebenszeit (Time to live, TTL): Für gerade mal bis zu 30 Tage nach dem erstmaligen Aufruf war der Verbleib der Schriftarten im Cache des Browsers vorgesehen. Hier war der Hund begraben – denn eigentlich war doch was ganz anderes eingestellt.
Das Browser Caching sollte eigentlich länger dauern
Gesteuert wird die Cache-Auslieferung über die Server-Konfigurationsdatei .htaccess, konkret in dem Modulabschnitt mod_expires: Hierin finden sich die von GTMetrix bzw. PageSpeed Insights zitierten „Cache-Richtlinien“ – eine Aufreihung von Dateitypen und korrespondierenden TTL-Zeiten. Nachstehend ein Auszug aus dem Modulabschnitt 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, einem Caching-Plugin für WordPress, gesetzt. Hierbei ist deutlich zu erkennen, dass für Schriftarten im WOFF2-Dateiformat tatsächlich eine Gültigkeitsdauer von vier Monaten nach Zugriff bestimmt wird. Wie kommt es also zu dieser Diskrepanz?
Was ist passiert?
Nach Durchsicht des Troubleshooting Guides von WP Rocket und der darin empfohlenen 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 ExpiresByType-Direktive verwendeten MIME-Typs (Ergebnis: korrekt). Warum also werden die Schriftarten nur mit einer Browser Caching-Zeit von 30 Tagen ausgeliefert?
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 Z1; wenn Dateityp=C, dann nimm Zeit Z2 und wenn Dateityp=unbekannt, dann nimm Zeit Z3.“
In meinem Fall wurde offensichtlich der WOFF2-Dateityp nicht als solcher erkannt, weshalb die entsprechende ExpiresByType-Direktive auch ins Leere lief und stattdessen die Standard-TTL von einem Monat verwendet wurde (siehe hierzu ExpiresDefault).
Eine außergewö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 Dateitypen hinzufü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 modifizieren. Denn hier ist zu befürchten, dass dieser Bereich bei einer zukünftigen Aktualisierung des Plugins wieder umgeschrieben wird.
Und voilà: Nach der erfolgreichen Aktualisierung der .htaccess und erneuter Durchführung der Leistungstests 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 bekanntermaßen ja auch Mist) verbessert.
Zum guten Schluss
Im Nachgang habe ich die Problemstellung und die dazugehörige Lösung an die Macher von WP Rocket weitergereicht, in der Hoffnung, dass dies zum Anlass genommen wird, entweder den Troubleshooting Guide um entsprechende Hinweise zu ergänzen oder – wenn möglich – die beschriebene AddType-Regel standardmäßig hinzuzufügen.
Es ist im Übrigen nicht auszuschließen, dass die gleiche Problematik auch bei anderen Caching Plugins zum Vorschein kommt. Sollte ich mich noch einmal damit befassen, werde ich es an dieser Stelle publizieren.
Am Ende noch eine Warnung: Änderungen an der .htaccess bitte nur dann durchfü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!
