Performancegewinn durch Content-Komprimierung (gzip) am Apache-Webserver
Eine gute Möglichkeit, um Transfervolumen zu sparen und somit die Performance der Webseiten zu verbessern, besteht darin, die statischen Inhalte einer Webseite (z.B. .html, .css, .js) in komprimierter Form vom Webserver ausliefern zu lassen. Die meisten modernen Browser akzeptieren problemlos komprimierte Inhalte. Der Webserver muss aber entsprechend konfiguriert werden.
Die folgende Darlegung bezieht sich auf den Apache-Webserver. Gzip kann man ebenso am IIS aktiviert werden. Dafür ist die folgende Anleitung allerdings nicht zutreffend.
Ablauf der Auslieferung komprimierter Inhalte
Der Browser teilt im Request-Header (Anfrage-Header) dem Apache-Webserver mit, dass er in der Lage ist, komprimierte Inhalte entgegen zu nehmen. Der Request-Header enthält in diesem Fall die Information:
Aufgrund dieser Anforderung versucht der Webserver die Inhalte in komprimierter Form auszuliefern. Ob der Webserver die Inhalte wirklich in komprimierter Form ausliefert, ist aus dem Response-Header (Antwort-Header) ersichtlich. Wenn im Respone-Header:
enthalten ist, dann erfolgt die Auslieferung des Inhaltes in komprimierter Form. In allen anderen Fällen in der normalen, unkomprimierten Form.
Aktivierung der Komprimierung am Apache Webserver
Die Komprimierung muss serverseitig aktiviert bzw. konfiguriert werden. Sofern man vollen Zugriff auf den Webserver hat, sollte dies kein Problem sein. Wenn man nur Webspace von seinem Provider zur Verfügung gestellt bekommt, hat man diesen direkten Zugriff auf den Webserver in der Regel nicht. In diesem Fall kann man die Komprimierung in der .htaccess-Datei konfigurieren.
Variante 1: Die Komprimierung erfolgt über das Webserver-Modul „deflate“.
Zuerst sollte man überprüfen, ob seitens des Providers das deflate-Modul aktiviert ist. Hierzu fügt man in seine .htaccess-Datei, die im obersten Verzeichnis (Rootverzeichnis) des Webservers liegt, folgende Zeile ein:
Wenn beim nächsten Seitenaufruf ein interner Serverfehler 500 zurück gegeben wird, so ist dies der Indikator, dass das Modul nicht zur Verfügung steht. In allen anderen Fällen wird die Webseite wie üblich ausgeliefert. Bei positivem Test kann der Eintrag wie folgt komplettiert werden:
AddOutputFilterByType DEFLATE text/plain text/html text/xml
AddOutputFilterByType DEFLATE text/css text/javascript
</IfModule>
Wenn das deflate-Modul zur Verfügung steht, erfolgt die Komprimierung serverseitig für die in der .htaccess-Datei konfigurierten Typen. Dies hat den Vorteil, dass man selbst keinen zusätzlichen Aufwand betreiben muss. Als Nachteil werden serverseitig natürlich größere Ressourcen benötigt. Dies ist vermutlich auch ein Grund, weshalb bei einigen Providern dieses Modul nicht aktiviert ist.
Variante 2: Webserver-Modul „deflate“ steht nicht zur Verfügung
In diesem Fall muss man die Komprimierung selbst übernehmen, d.h. es sind zusätzlich zu den vorhandenen Dateien jeweils noch die komprimierten Versionen der Dateien auf dem Webserver abzulegen. Die Dateien müssen gzip-komprimiert sein. Auf dem Webserver muss dann z.B. index.html und index.html.gz bzw. style.css und style.css.gz liegen. Es müssen immer beide Versionen zur Verfügung gestellt werden, damit die Inhalte auch unkomprimiert an Browser ausgeliefert werden können, die keine komprimierten Inhalte akzeptieren. Zum Komprimieren im gzip-Format kann man z.B. die freien Tools lZArc oder 7-Zip verwenden. Danach ist die .htaccess-Datei wie folgt zu erweitern:
<ifModule !mod_deflate.c>
AddEncoding x-gzip .gz
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME} \.(html|js|css)$
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)$ /$1.gz [L]
<FilesMatch "\.css\.gz$">
AddType "text/css" .gz
</FilesMatch>
<FilesMatch "\.js\.gz$">
AddType "text/javascript" .gz
</FilesMatch>
<FilesMatch "\.html\.gz$">
AddType "text/html" .gz
</FilesMatch>
</ifModule>
Der Erfolg beider Varianten kann z.B. mit dem Firefox Add-on Firebug geprüft werden, in dem man den übertragenen Response-Header analysiert. Wie eingangs erwähnt muss Content-Encoding: gzip enthalten sein. Dann funktioniert die Komprimierung korrekt.
Wann bringt die Komprimierung keinen Vorteil?
Bei sehr kleinen Dateien ist die Einsparung an Transfervolumen sehr gering. Dem gegenüber steht der erhöhte Aufwand zum Dekomprimieren der Inhalte. Deshalb macht es wenig Sinn, sehr kleine Dateien zusätzlich zu komprimieren. Bilder per gzip zu komprimieren bringt ebenfalls keinen Vorteil, da hierbei kaum eine Verkleinerung der Bilddateien zu verzeichnen ist. Bilder sollten per Bildbearbeitungsprogramm bereits optimal komprimiert werden.
Praktisches Beispiel zur Komprimierung statischer Inhalte
Zum Abschluß finden Sie hier noch eine Gegenüberstellung der Dateigrößen mit den prozentualen Einsparpotentialen basierend auf den Werten meiner eigenen Homepage. Sie enthält die Werte für die Normalform, die minimierte Form (mit YUICompressor) und die gzip-komprimierte Form.