Performance: Page Speed Optimierung – Leverage browser caching

Um nochmal ein bißchen an der Performance Schraube zu drehen, habe ich es mir vor einiger Zeit mal angetan und mir Page Speed gezogen und daraufhin ein bisschen meine Seiten optimiert, denn schließlich empfiehlt Google das ja auch. Mit den bisherigen Optimierungen, wie zum Beispiel den Einträgen in die wp-config.php ist ja schon einiges passiert, aber Page Speed hatte doch noch ein bisschen was zu meckern.

So kam beim erstmaligen Aufruf der Score 82/100 für einen meiner Blogs dabei heraus und das, was als erstes mit einem roten Ausrufezeichen angemeckert wurde, war das Leverage browser caching.

Leverage browser caching – expire headers

Dann wollten wir uns dem Leverage browser caching auch als erstes widmen. In der Page Speed Hilfe ist für das Leverage browser caching nachzulesen, dass hier für die statischen Ressourcen im HTTP Header ein paar Werte fehlen, und zwar Expires oder Cache-Control: max-age sowie/oder Last-Modified und ETag.

Angemeckert wurden im Bereich Leverage browser caching als erstes die Expire headers ausschließlich nur für Bilder, JS und CSS Dateien. In der Page Speed Hilfe wird für Expires wird ein Minimum von einem Monat (bis hin zu einem Jahr) empfohlen, außerdem wird Expires dem Cache-Control: max-age vorgezogen. Okidoki, damit habe ich dann folgendes in meine .htaccess Datei eingetragen, um die Expire Headers für Bilder, JS und CSS Dateien auf 2 Monate zu setzen:

# Expire headers 5184000 Sekunden = 2 Monate
<IfModule mod_expires.c>
ExpiresActive On 
ExpiresByType image/x-icon "access plus 5184000 seconds" 
ExpiresByType image/gif "access plus 5184000 seconds"  
ExpiresByType image/jpg "access plus 5184000 seconds"  
ExpiresByType image/png "access plus 5184000 seconds"
ExpiresByType text/css "access plus 5184000 seconds"
ExpiresByType text/javascript "access plus 5184000 seconds"
ExpiresByType application/javascript "access plus 5184000 seconds"
ExpiresByType application/x-javascript "access plus 5184000 seconds" 
</IfModule>

Damit war das rote Ausrufezeichen bei Leverage browser caching schon mal in ein gelbes Warndreieck umgewandelt. Aber wir sind ja noch nicht so ganz fertig.

Leverage browser caching – cache expiration

Als nächstes meckerte Page Speed im Leverage browser caching die fehlende Cache Expiration von einigen Bildern etc. an. In der Page Speed Hilfe steht zwar zu lesen, dass es überflüssig ist, Expires und Cache Expiration gleichzeitig einzusetzen, aber trotzdem meckert Page Speed noch bei einigen Dateien (Expires haben wir ja oben bereits eingesetzt). Okidoki, dann wollen wir halt noch ein paar Cache Expirations hinzufügen und ich trage folgendes in meine .htaccess ein, um die Cache Expiration meiner Bilder und CSS Dateien auf 2 Monate zu setzen, der JS Dateien auf die Hälfte:

# BEGIN Cache-Control Headers
<ifmodule mod_headers.c>
  <filesmatch "\\.(ico|jpe?g|png|gif|swf)$">
        Header set Cache-Control "max-age=5184000, public"
  </filesmatch>
  <filesmatch "\\.(css)$">
        Header set Cache-Control "max-age=5184000, private"
  </filesmatch>
  <filesmatch "\\.(js)$">
        Header set Cache-Control "max-age=216000, private"
  </filesmatch>
</ifmodule>

Nun noch die ETags entfernen, denn schließlich sagt die Page Speed Hilfe, dass ETags und Last-Modified zusammen überflüssig sind:

# Turn ETags Off 
<ifmodule mod_headers.c>
   Header unset ETag 
</ifmodule> 
FileETag None

Das wars dann auch schon für diesen Teil. Der Page Speed Core ist mit diesen Leverage browser caching Änderungen von 82/100 auf 85/100 gestiegen (mühsam ernährt sich das Eichhörnchen). Ich habe zwar immer noch ein gelbes Warndreieck vorne dran, aber es werden nur noch externe Javascripts angemeckert (Adsense etc.) auf deren freshness lifetime ich so gar keinen Einfluss habe. Ja, so ist das mit Google, die schieben uns den schwarzen Peter für ihre eigenen, nicht optimierten Applikationen zu