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 ebenso am IIS aktiviert werden. Dafür ist diese 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 Sie vollen Zugriff auf den Webserver haben, sollte dies kein Problem sein. Wenn Ihnen nur Webspace von seinem Provider zur Verfügung gestellt wurde, haben Sie diesen direkten Zugriff auf den Webserver in der Regel nicht. In diesem Fall können Sie die Komprimierung in der .htaccess-Datei konfigurieren.
Variante 1: Die Komprimierung erfolgt über das Webserver-Modul „deflate“.
Zuerst sollten Sie überprüfen, ob seitens des Providers das deflate-Modul aktiviert ist. Hierzu fügen sie in Ihre .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 Sie selbst keinen zusätzlichen Aufwand betreiben müssen. 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 müssen Sie 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 können Sie 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 Sie den übertragenen Response-Header analysieren. Wie eingangs erwähnt muss Content-Encoding: gzip enthalten sein. Dann funktioniert die Komprimierung korrekt.
Update: 17.12.2013
Ein Leser wies mich darauf hin, dass die Komprimierung mit 7-Zip oder lZArc nicht 100% valide ist.
Weiterführende Informationen hierzu finden Sie im Beitrag:
Valide GZIP Kompression für statische Webseiten.
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.