Home Menü

Leverage Browser Caching – Expires Header konfigurieren

Bei der Optimierung der Website-Performance spielt das Leverage Browser Caching, welches durch die Konfiguration eines Expires Header erreicht werden kann, eine große Rolle. Lesen Sie in diesem Artikel, wie Sie das Leverage Browser Caching auch auf Ihrer Webseite bzw. WordPress-Seite aktivieren und so die Seitenladezeit für Ihre Stammleser deutlich reduzieren.

Dieser Artikel ist Teil der Guideline High-Performance Websites mit WordPress.

Voraussetzung

Damit Sie die im Folgenden beschriebene Anleitung auch durchführen können, müssen Sie zuerst sicherstellen, dass auf Ihrem Webserver das Apache Modul mod_expires installiert ist. Diese Information finden Sie entweder direkt im Kontrollcenter Ihres Providers oder bei einem Shared-Hosting-Tarif durch einen Anruf beim Support heraus. Zudem benötigen Sie Zugriff auf die .htaccess-Datei Ihrer Webseite.

Leverage Browser Caching und Expires Header

Browser nutzen einen Cache um die Anzahl von HTTP Requests zu verringern, damit die aufgerufene Website schneller geladen wird. Haben Sie beispielsweise eine bestimmte Webseite bereits zu einem früheren Zeitpunkt aufgerufen, dann liegen vielleicht noch Teile dieser Webseite, wie Bilder oder CSS-Dateien, im Cache Ihres Browsers. Durch die Nutzung eines Expires Header in diesen Dateien wird dem Browser nun mitgeteilt, ob er die aktuelle Kopie im Cache des Browsers noch nutzen kann oder ob die Datei neu – mittels HTTP Request – vom Webserver angefordert werden muss.

Im Detail sieht das wie folgt aus:

  1. Der Browser sendet beim Aufruf einer Webseite, beispielsweise von www.blog-it-solutions.de, einen HTTP GET Request an den Webserver um einzelne Dateien (wie beispielsweise eine CSS-Datei) anzufordern.
  2. Dieser HTTP GET Request wird vom Webserver mit einem HTTP Response beantwortet, welcher wie Folgt aussehen könnte:
    HTTP/1.1 200 OK
    Date: Fri, 13 Dec 2013 23:47:20 GMT
    Server: Apache
    Content-Type: text/css; charset=utf-8
    Last-Modified: Fri, 13 Dec 2013 23:29:41 GMT
    <strong>Expires: Fri, 20 Dec 2013 23:29:41 GMT</strong>
    <strong>Cache-Control: max-age=604800</strong>
    Content-Length: 10100
  3. Der gezeigte HTTP Response enthält sowohl einen Expires Header (für HTTP/1.0) als auch einen Cache-Control Header (für HTTP/1.1). Wird nun irgendeine Seite von Blog IT-Solutions in den nächsten 7 Tagen aufgerufen (bis zum 20. Dezember), welche die oben gezeigte CSS-Datei benutzt, dann muss der Browser für diese CSS-Datei keinen HTTP GET Request an den Webserver senden, sondern kann die Datei direkt aus dem Browser Cache laden und nutzen.

Dieses Beispiel zeigt auch deutlich, dass vom Leverage Browser Caching nur Besucher Ihrer Webseite profitieren, die bereits zu einem früheren Zeitpunkt auf Ihrer Webseite waren und die jeweiligen Dateien im Cache haben (Primed Cache). Ist der Cache Ihrer Besucher leer (Empty Cache), dann hat diese Performance-Maßnahme keinen Einfluss auf die Ladezeit – zumindest nicht beim ersten Aufruf. Sobald der Besucher allerdings eine zweite Seite aufruft, hat er bereits einige Dateien (CSS, JavaScript, Bilder) im Browsercache und muss für diese Dateien keinen expliziten HTTP GET Request mehr an den Webserver senden.

Expires Header in der .htaccess-Datei konfigurieren

Wie zu Beginn des Artikels bereits angedeutet, bedienen wir uns zur Konfiguration des Expires Headers an dem Apache Modul mod_expires. Dies hat den großen Vorteil, dass sowohl der Expires Header für HTTP/1.0 als auch der Cache-Control Header für HTTP/1.1 gesetzt wird. Der nötige Code, welchen Sie einfach in die .htaccess-Datei auf Ihrem Webspace kopieren müssen, sieht so aus:

<IfModule mod_expires.c>	 	
  ExpiresActive ON	 	
  <FilesMatch "\.(gif|png|jpg|jpeg|ico|css|js)$"> 	 	
    ExpiresDefault "access plus 1 month" 	 	
  </FilesMatch>	 	
</IfModule>

Die erste Zeile prüft, ob das Modul mod_expires auch auf Ihrem Server installiert ist. Dies verhindert, dass Ihre Seite nicht mehr funktioniert, falls das Modul nicht gefunden werden kann. Die zweite Code-Zeile aktiviert die Generierung der Expires Header für die in Code-Zeile 3 festgelegten Dateitypen. Die vierte Zeile fügt dann zu den entsprechenden Dateien einen Expires Header und einen Cache-Control Header für die Dauer von einem Monat an.

Wenn Sie nun beispielsweise mit Firebug die HTML Header überprüfen, werden Sie feststellen, dass die nötigen Header-Informationen an die jeweiligen Dateien angefügt wurden.

Hinweis: Bitte leeren Sie zuvor Ihren Browsercache bzw. bei Nutzung eines Content Delivery Networks müssen Sie zuerst alle Dateien von den Servern bereinigen.

Leverage Browser Caching - Expires Header konfigurieren - Beispiel

Weitere Informationen zu den Einstellungsmöglichkeiten des mod_expires Modul erhalten Sie im Apache Manual.

Wichtig: Änderung von Dateien beim Einsatz von Leverage Browser Caching

Am Ende des Artikels noch ein wichtiger Hinweis: Wenn Sie nun Bilder oder CSS-Dateien auf Ihrer Webseite ändern, so sollten Sie unbedingt auch den Namen der jeweiligen Datei ändern. Ansonsten wird bei einigen Anwendern noch das alte Bild angezeigt oder die alte CSS-Datei genutzt.

Warum? Wenn Sie den Namen der Datei nicht ändern, dann werden alle Besucher, die Ihre geänderte Datei bereits früher in den Browser-Cache geladen haben, bis zum Erreichen des Ablaufdatums auf die alte Datei im Cache zugreifen. Dies können Sie verhindern, indem Sie einfach den Dateinamen, beispielsweise von einem Bild, ändern. Da die HTML-Datei nicht gecacht wird, ist in der HTML-Datei beim Aufruf der Seite der neue Bilder-Pfad vorhanden und der Browser schickt erneut einen HTTP GET Request an den Webserver und erhält das neue Bild.

Performance-Vergleich

Fully Loaded

VorherNachherVeränderung
ZeitRequestsBytesZeitRequestsBytesZeitRequests
Primed Cache0.514s576 KB0.553s32 KB+8 %-2

Durch die Konfiguration des Expires Header konnte – gemessen mit webpagetest.org – die Anzahl der HTTP GET Requests bei einem Aufruf der Seite mit Primed Cache (Seite wurde früher bereits aufgerufen und Dateien liegen noch im Cache) von 5 auf 3 reduziert werden. Hierbei hat sich die Ladezeit jedoch etwas verschlechtert, was aber aufgrund der vorliegenden Daten im Toleranzbereich der Messung liegt. Dass die Verbesserung hier nicht schwerer wiegt, liegt vor allem daran, dass die 3 übrigen Requests jeweils zu einer anderen Domain ausgeführt werden, was vor allem viel Zeit für den DNS Lookup und die Initial Connection kostet.

Das Ergebnis hier ist aber keinesfalls repräsentativ, was an der Messmethode von webpagetest.org liegt: Das Tool berücksichtigt bei der Repeat View Messung nur Requests, bei denen anschließend Daten übertragen werden. Dies ist bei Dateien, die sich seit dem letzten Abruf nicht geändert haben, nicht der Fall. Der Grund liegt im HTTP-Protokoll verborgen: Rufen Sie eine Seite ohne Expires Header ein zweites Mal auf, dann sendet der Browser für jede Datei einen HTTP GET Request an den Webserver. Hat sich die Datei seit dem letzten Abruf allerdings nicht geändert (kann anhand des Date Headers überprüft werden), dann sendet der Browser nur einen HTTP Response ohne Inhalt zurück der besagt: Ok, verwende die Datei die du bereits hast, weil sich die Datei seither nicht geändert hat.

Im Vergleich: Beim Leverage Browser Caching sendet der Browser keinen HTTP GET Request, weil er anhand des Expires Header sofort überprüfen kann, ob die Datei noch gültig ist oder nicht.

De facto liegt die Performance-Verbesserung für wiederkehrende Besucher viel höher. Steve Souders geht in seinem Buch davon aus, dass eine Webseite bei wiederkehrenden Besuchern durch den Einsatz des Leverage Browser Caching um etwa 50 Prozent schneller geladen wird.

Google Pagespeed

VorherNachher
Google PageSpeed Mobil78
Google PageSpeed Desktop8990

Google Pagespeed honoriert das Leverage Browser Caching mit einem Extrapunkt bei der Desktop-Anzeige. Aber auch hier wird noch bemängelt, dass beispielsweise der Expires Header für die CSS und JavaScript-Dateien mit 60 Minuten zu niedrig gesetzt ist. Tatsächlich ist der Wert nicht hoch, allerdings wird dieser in unserem Fall direkt vom Tool WP Super Cache gesetzt.

YSlow

VorherNachher
YSlow Punkte8894
YSlow GradeBA

YSlow zeigt sich im Vergleich zu Google Pagespeed in diesem Fall viel erkenntlicher und macht einen deutlichen Sprung nach oben.

Fazit

Das Leverage Browser Caching sollte auf jeder Ihrer Webseiten aktiviert sein, da der Aufwand zur Implementierung sehr gering ist, der Nutzen allerdings umso höher. Vor allem Ihre Stammleser werden es Ihnen danken, wenn die Seite um 50 Prozent schneller geladen wird.

Im nächsten Artikel dieser Guideline geht es um das Thema Komprimierung im Speziellen bei Bildern, welche ein großes Potential zur Optimierung bieten.

Veröffentlicht von Josef Seidl

Josef Seidl ist Unternehmer und hat an der TU München und der Stanford University Wirtschaftsinformatik studiert. Er ist begeistert von Technik, schätzt performante Webseiten und ist gerne in den Bergen unterwegs. Zu finden ist er auch bei LinkedIn.

2 Kommentare » Schreibe einen Kommentar

    Schreibe einen Kommentar zu Josef Antworten abbrechen

    Pflichtfelder sind mit * markiert.


    DSGVO Cookie Consent mit Real Cookie Banner