Sie befinden sich hier:
» 
» 
12.05.2011

Performancegewinn durch Content-Komprimierung (gzip) am Apache-Webserver

Kategorie(n): Performance

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:

Accept-Encoding: gzip,deflate

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:

Content-Encoding: gzip

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:

AddOutputFilterByType DEFLATE text/plain

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:

<IfModule mod_deflate.c>
  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:

RewriteEngine on
<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.

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.

Datei
Größe
Einsparung
index.html
11,4kB
index.html.gz
3,64kB
68%
style.css
12,4kB
style-min.css
9,97kB
20%
style-min.css.gz
2,30kB
81%
jquery.js
117kB
jquery-min.js
55,9kB
52%
jquery-min.js.gz
19,2kB
84%

Autor: Mein Name ist Harry Kämpf und ich bin seit vielen Jahren als Projekt Manager im Webumfeld tätig. Auf diesen Erfahrungen basieren die Tipps zur Webseitengestaltung. Ich schreibe gern über Webthemen, nehme aktuelle Trends auf und gebe bei Bedarf kompetente Beratung. Mehr Infos können Sie auf ueber-mich.html nachlesen.

18

Kommentare:

28.Juni2013

Sehr hilfreiche Erläuterung. vielen Dank. Dennoch ist mir noch nicht klar, ob es reicht, wenn ich die Änderung in der .htccess-Datei mache, oder weitere Schritte notwendig sind, um solche Komprimierung zu erreichen: index.html.gz also, komprimiert der Server die Dateinen bei jeder Anfrage, oder einmal und dann hat er eine komprimierte Version der Datei?

Denn, wenn er jedes Mal neu komprimiert, dann stelle ich die Dateien in komprimierten Versionen zur Verfügung und spare die serverseitig größere Ressourcen damit.

28.Juni2013

Ja, statische Webseiten kann man bereits in komprimierter Form auf dem Webserver ablegen. Man generiert sie beispielsweise mit einem oben geschriebenen Tool oder generiert sie mit PHP und legt dann sowohl die unkomprimierte (z.B. index.html), als auch die komprimierte Version (z.B. index.html.gz) auf dem Webserver ab.
Der Webserver muss dann nur noch ausliefern.