Softeller

Es gibt Websites, bei denen wartet man eeeewig.

Einige Seiten sind natürlich so inhaltsüberfrachtet, da fällt die Ursache gleich ins Auge. Andererseits gibt es auch umfangreiche Websites, die trotzdem schnell laden. Oft mag hier veraltete oder durch Shared Hosting überanspruchte Hardware die Ursache sein, die am anderen Ende der Welt vielleicht gar über eine selbstgespannte Leitung ans Internet angeschlossen ist. Trifft dies jedoch nicht zu, so kann der langsame Seitenaufbau aber auch an der eigenen Webserver-Konfiguration, am Aufbau der Website oder an Mängeln am HTML liegen. Ursachen, denen teilweise mit einfachsten Mitteln auf den Leib gerückt werden kann. Optimieren ist angesagt.

Aber warum überhaupt die Ladezeit der eigenen Website optimieren? Neben dem Nervenkostüm des Besuchers (und wohl potentiellen Kunden), kann die Trägheit beim Seitenaufruf mittlerweile auch die Positionierung in Suchmaschinen strapazieren. Beispielsweise rechnet Google seit geraumer Zeit auch die Aufrufzeiten in sein Qualitäts-Ranking mit ein. Somit wird Optimieren ein Muss.

Nun weiss der geneigte Leser, dass – wo und was auch immer optimiert wird – es hier stets um ein Verbessern hin zum Idealwert geht, das Ideal selbst aber stets unerreichbar bleibt. Ein “Fertig!” gibt es nicht. Je näher man dem Idealwert kommt, umso aufwändiger werden auch die Maßnahmen. Hier droht also stets die Gefahr, dass Aufwand und Ertrag sich nicht mehr gegeneinander aufrechnen. Also ist Augenmaß gefragt, wann es der Optimierung genug ist. Trotzdem gibt es oft sehr einfache Ansatzpunkte, bei denen mit wenig Aufwand viel erreicht werden kann. Auf einige dieser Punkte möchte ich mich konzentrieren.

Einen guten Einstieg bietet das von Google bereitgestellte Page Speed Tool. Es besteht aus einem Firefox-AddIn, das sich in das Analyse-Tool Firebug einhängt. Nach der Installation des Page Speed AddIns ruft man einfach die eigene Website in Firefox auf und klappt mit einem Klick auf den kleinen Käfer rechts unten das FireBug-Fenster auf. Firebug enthält nun zwei weitere Menüpunkte “Page Speed” und “Page Speed Activity”. Ein Klick auf “Analyze Performance” unter “Page Speed” erstellt eine erste, leicht verständliche Übersicht über die drängendsten Performance-Probleme der Website.

Das Tool berechnet zunächst einen Score für die aufgerufene Website, der einen Vergleich mit anderen Seiten ermöglicht. Mein Tipp: Die Seiten der wichtigsten Mitbewerber aufrufen, und prüfen, wo man sich selbst mit diesem Score einreiht.

Der Page Speed Test listet nun eine Reihe von Best Practices auf, Empfehlungen zur Optimierung der Ladezeit. Das Tool zeigt diese Best Practices gleichzeitig gewichtet nach deren Wirksamkeit an und gibt beim Aufklappen der einzelnen Punkte weitere hilfreiche Informationen, bspw. welche Dateien in welchem Maße betroffen sind, oder optimiert werden können.

Wer die Best Practices wirklich von A bis Z durchackert, hat sich damit sicher eine Menge Fleißbildchen verdient, aber konzentrieren sollte man sich dennoch auf die wichtigsten Punkte, also allen voran die mit dem roten Ausrufezeichen gekennzeichneten. Auf genau diese Maßnahmen möchte ich in einer Reihe von Posts kurz eingehen.

Heute also: Enable Compression

Praktisch alle modernen Browser unterstützen die HTTP Komprimierung mittels gzip oder deflate - Kodierung. Dabei sendet der Browser mit seiner Anfrage einen Header wie z.B. Accept-Encoding: gzip,deflate und somit weiß der Webserver, dass er an diesen Client gerne komprimierte Daten senden kann. Anstatt eine HTML-Seite nun im Rohformat zu senden, komprimiert er diese mit gzip oder deflate (zweiteres ist ein weniger verbreitetes Komprimierungsformat, empfohlen wird gzip) und senden den komprimierten Stream zurück, wobei er im Header wiederum angibt, mit welchem Algorithmus komprimiert wurde (z.B. Content-Encoding: gzip). Diese Funktion ist in den gängigen Webservern integriert bzw. über Zusatzmodule verfügbar, muss in der Regel aber explizit aktiviert werden.

Für Apache 2 Webserver funktioniert die Aktivierung beispielsweise durch die folgenden Einträge in der .htaccess-Datei:

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent env=!dont-vary

In der ersten Zeile erklären wir, dass für alle HTML, Text, CSS und Javascript-Dateien die Komprimierung zu nutzen ist. Denn: Bilddateien oder EXE-Downloads möchten wir in keinem Fall komprimieren – die erneute Komprimierung bereits reduzierter JPEG oder PNG-Grafiken, sowie bereits gepackter Software-Installationen, würde in keinem weiteren Größengewinn resultieren, und wäre somit kontraproduktiv.

In den drei folgenden Zeilen behandeln wir einige Ausnahmen von Browsertypen, die die Komprimierung nicht oder fehlerhaft unterstützen.

In der letzten Zeile kümmern wir uns noch darum, dass auch Proxy-Server die komprimierten Datenströme nur an Clients weitergeben, die diese auch angefordert haben.

Näheres erklärt auch die Apache Dokumentation für das Deflate-Modul.

Zu beachten ist, dass o.g. Konfiguration die Apache-Module mod_deflate und mod_headers benötigt. Diese müssen i.d.R. nicht extra installiert, aber im Apache aktiviert werden. Wie dies funktioniert hängt stark von der verwendeten Plattform ab, auf Debian Unix erfolgt die Aktivierung z.B. einfach durch das Anlegen einiger Symlinks (Apache Neustart danach nicht vergessen):

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

Somit ist mit einer einfachen Konfiguration bereits ein erster Performance-Boost erreicht. Sicher erfordert die Komprimierung nun etwas mehr Rechen-Ressourcen auf dem Webserver. Aber wenn der Server dem nicht standhält, wäre ohnehin ein Upgrade überfällig. Im nächsten Teil sehen wir uns das Browser Caching an.