Caching und Komprimieren über den Apache HTTP Server

Erneut ein Artikel der im Zusammenhang mit Google steht. In den letzten Tagen wurde viel über die neuen Kriterien für Googles Suchmaschinen-Ranking diskutiert. Unter anderem ist nun auch eine Optimierung für mobile devices ausschlaggebend für eine gute Platzierung in den Suchergebnissen. Google hat diesen mobile friendly-Test zur Verfügung gestellt, mit dem man seine Website analysieren kann. Dabei kommen die meisten responsiven Websites relativ gut weg. Bei Sites, die nicht für mobile Geräte optimiert sind, werden einige Hinweise zur Verbesserung angegeben. Wir nutzen für die Optimierung üblicherweise den Dienst von CrossBrowserTesting. Dort kann jede URL auf einer Vielzahl verschiedener physischer Geräte und diversen zugehörigen Browsern getestet werden. Das Ergebnis wird dabei direkt über eine remote connection sichtbar, wodurch Feintuning am mobile Design betrieben werden kann.

Deutlich aufschlussreicher als der mobile friendly-Test ist allerdings der Geschwindigkeitstest. Dieser analysiert die Website nach unterschiedlichen Kriterien für Mobil oder Desktop.

Ergebnis des PageSpeed Tests

 

Hierbei kommen einige Faktoren zusammen, welche die Geschwindigkeit der Website beeinflussen. Google geht unter anderem explizit auf Bildoptimierung, sinnvolles Einbinden von externen JS- und CSS-Ressourcen sowie auf das Reduzieren (minify) dieser Ressourcen ein.

Zwei weitere Punkte sind uns dabei ins Auge gesprungen: Browser-Caching und Komprimierung.

Komprimierung

Bei jedem Aufruf einer Website werden via HTTP Request alle benötigten Ressourcen vom Server abgefragt. Dieser stellt dann beispielsweise die index.html sowie alle benötigten Bilder, CSS- und JS-Dateien zur Verfügung. Diese Daten können je nach Website bis zu mehreren MB an Traffic bedeuten, die natürlich geladen werden müssen, bevor die Site komplett dargestellt werden kann.

Moderne Browser können inzwischen aber dem Server mitteilen, dass sie auch komprimierte Daten akzeptieren, falls diese zur Verfügung stehen. Der Request Header beinhaltet dann beispielsweise folgende Zeile:

Accept-encoding: gzip, deflate

Dies erlaubt dem Server die gewünschten Daten komprimiert an den Browser zu senden, von welchem diese dann lokal entpackt werden. Tatsächlich lassen sich dadurch oftmals über 75 % des transferierten Datenvolumens einsparen. Dass die Daten gepackt gesendet werden wird dem Client im Response Header mitgeteilt:

Content-encoding: gzip

Wir möchten hier nicht zu sehr ins Detail gehen, darum beschränken wir uns auf die einfachste Methode für den Apache HTTP-Server. Details zu unterschiedlichen Methoden finden Sie in diesem Artikel von Stephen Pierzchala.

Um das benötigte Modul mod_deflate zu aktivieren, genügt ein Eintrag in der .htaccess, welcher hier auf der Apache Website nachzulesen ist. Durch anhängen dieser Zeile an die htaccess wird die Komprimierung durch den Webserver für die gängigsten Dateitypen aktiviert.

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

Edit 24.04.15 – Wir haben festgestellt, dass unser Javascript mit diesem Befehl nicht immer komprimiert wurde. Wir mussten noch einen weiteren Abschnitt hinzufügen, nun funktioniert es:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript

Mit diesem Tool auf GidNetwork kann das Ergebnis überprüft werden. Für www.k-webs.ch kommen wir alleine mit dem Markup von über 15 KB auf unter 5 KB, also auf ca. 1/3 des ursprünglichen Volumens.
Resultat der Komprimierung

Aktivieren des Caching

Eine weitere Möglichkeit eine Website zu optimieren ist das Caching. Dabei speichert der Browser einzelne Komponenten der Website lokal und braucht diese bei einem nächsten Besuch der Site nicht wieder vom Server zu laden.

Bei einem ersten Abruf der Website kann über den Response Header vom Server mitgeteilt werden, wie lange einzelne Komponenten der Site fresh, d.h. gültig, bleiben. Bilder, wie z.B. das Logo, ändern sich üblicherweise auch über einen längeren Zeitraum nicht. Dasselbe gilt für CSS und JS sobald die Website einmal live geschaltet ist. Der HTML-Code dagegen kann sich relativ häufig ändern und sollte daher auch regelmässig neu vom Server abgerufen werden. Welche Dateitypen wie lange direkt aus dem Cache geladen werden dürfen, kann für Apache wieder in der .htaccess festgelegt werden.

Wir nutzen für diesen Fall Apaches mod_expires Modul. Dieses setzt die Einträge für Expires und Cache-Control im HTTP Header. Mehr Informationen zu diesen Headern finden Sie in diesem sehr detaillierten Caching Tutorial von Mark Nottingham. Unser Eintrag in der .htaccess sieht folgendermassen aus:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 12 hours"
</IfModule>

Edit 24.04.15 – Auch hier mussten wir das JS gesondert mit application/x-javascript ansprechen. Der Code sieht nun also so aus:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 12 hours"
</IfModule>

Über das mod_expires Modul wird die freshness für einzelne Dateitypen festgelegt. Die maximale Dauer darf dabei ein Jahr nicht überschreiten! Gemessen wird die Zeit jeweils ab dem access, also dem Abruf der Seite. Im Response Header werden dann automatisch die Einträge hinzugefügt, welche angeben ab wann die Daten wieder neu vom Server geladen werden müssen. Übrigens werden diese Header nicht nur von Browsern genutzt, sondern auch von Content delivery networks (CDN) wie CloudFlare.

Testen kann man die Einträge bei REDbot. Dort werden neben dem abgerufenen Response Header auch zusätzliche Informationen zum Caching und auch zur Komprimierung angegeben.

Ein Kommentar zu “Caching und Komprimieren über den Apache HTTP Server

  1. Pingback: WordPress WYSIWYG-Editor lädt nicht – Probleme mit TinyMCE’s plugin.min.js | k-webs tech blog

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.