Softeller

Im ersten Teil dieser Reihe bin ich darauf eingegangen, wie mithilfe des Page Speed Tools von Google herausgefunden werden kann, welche Maßnahmen zur Performance-Optimierung der eigenen Website die erfolgversprechenderen sind, und warum die Geschwindigkeitsoptimierung nicht auf die leichte Schulter zu nehmen ist. Im letzten Teil haben wir die HTTP Komprimierung eingeschaltet.

Heute: Browser Caching

Als weiteren wichtigen Punkt erachten die Experten der Google-Labore den sinnvollen Einsatz des Browser-Caches. Webbrowser können geladene Inhalte zwischenspeichern, und müssen so die gleiche Ressource nicht mehrfach abrufen, falls sie öfter innerhalb einer Website (z.B. auf mehreren Seiten) gebraucht wird. Ebenfalls müssen zwischengespeicherte Grafiken, dann nicht erneut aufgerufen werden, wenn die gleiche Website nach einigen Tagen wieder besucht wird. Dazu benötigt der Browser aber die Information, welche Daten er wie lange zwischenspeichern darf. Denn am Webserver dynamisch erzeuge Inhalte beispielsweise können zwar stets den gleichen Namen und die gleiche Größe haben, ihr Inhalt kann trotzdem variieren. Weisen wir also die Browser unserer Besucher an, bestimmte statische Daten zu cachen, entlastet das unsere Webserver und führt gleichzeitig zu einer schnelleren Ladezeit bei wiederholten Besuchen oder beim Besuch mehrerer Seiten. Die Page Speed Analyse gibt uns wieder einige Tipps:

Sinn macht das Zwischenspeichern vor allem für Inhalte, die sich selten ändern, vor allem also für Grafiken. Auch CSS-Dateien und Javascripts kommen in Frage. Hier ist aber zu bedenken, dass bei häufigen Änderungen der Styles oder Skripte, diese Änderungen beim Besucher erst nach Ablauf der Cache-Zeit oder bei einem kompletten Refresh der Website sichtbar werden. In der Entwicklungsphase einer Site kann das hinderlich sein. Gleiches gilt für das Ändern von Grafiken.

Ich habe mich daher für ein eher defensives Caching entschieden – das aber immer noch besser ist als gar keines. Hier wieder der Code für die Apache 2 .htaccess-Datei:

ExpiresActive on
ExpiresByType image/png "access plus 1 day"
ExpiresByType image/gif "access plus 1 day"
ExpiresByType image/jpeg "access plus 1 day"
ExpiresByType text/css "access plus 1 day"
ExpiresByType text/javascript "access plus 1 day"
ExpiresByType application/javascript "access plus 1 day"
ExpiresByType application/x-javascript "access plus 1 day"

AddType image/vnd.microsoft.icon .ico
ExpiresByType image/vnd.microsoft.icon "access plus 1 day"

Wir definieren für alle Grafiken, CSS und JS-Dateien eine Lebensdauer von einem Tag. Außerdem definieren wir für Icon-Dateien eine solche Lebensdauer, damit auch die favicon.ico-Datei nicht unnötig häufig geladen wird.

Natürlich kann mit längeren Caching-Zyklen noch viel mehr erreicht werden, hier ist Experimentieren erlaubt.

Diese Konfiguration, wie auch die Konfiguration der HTTP Komprimierung, kann natürlich auch Host-weit in der hosts.conf vorgenommen werden.

Auch diese Konfiguration benötigt im Apache die Aktivierung eines zusätzlichen Moduls, nämlich mod_expires. Dies funktioniert wie im letzten Artikel, auf Debian Unix z.B. einfach durch das Anlegen eines Symlinks (Apache Neustart danach nicht vergessen):

cd /etc/apache2/mods-enabled
ln -s /etc/apache2/mods-available/expires.load
/etc/init.d/apache2 restart

Soviel für heute, im nächsten Teil werfen wir einen Blick auf die wichtigsten HTML-Optimierungen.