Mit dem weit verbreiteten Komprimierungs-Algorithmus gzip lässt sich nicht nur viel Platz auf der Platte sparen; es lässt sich auch viel Traffic beim Einsatz eines Web-Servers einsparen und was noch interessanter ist: Es lassen sich die Ladezeiten der Webseiten deutlich reduzieren, was insbesondere den Usern mit geringer Bandbreite zugute kommt.

Während eine Bild-Datei als JPG oder GIF bereits komprimiert ist, werden HTML-Quellcodes oft noch umkomprimiert per http übertragen obwohl heute wahrscheinlich 99% der im Einsatz befindlichen Browser auch komprimierten Content verwerten können und die HTML-Codes aufgrund komplexer Layouts und JavaScripte immer umfangreicher werden und sich hervorragend komprimieren lassen.

Mit dem Apache Modul “mod_gzip” lassen sich zwei Strategien umsetzen um Content zu komprimieren. Entweder hält man statische Seiten auch als gzip-Versionen vor oder man lässt Apache via mod_gzip den Content “on thy fly” packen.
Natürlich hat die “pre compressed” Lösung einen Performance-Vorteil, weil nicht bei jedem Request erneut komprimiert werden muss. Die Pflege der gzippten Versionen für jedes Dokument der Site steht hier jedoch auf der Negativ-Seite.
Wenn man Apache/mod_gzip so einrichtet, dass “on the fly” gepackt wird, könnte man meinen, dass es die Performance des Servers herunterzieht… Aber anscheinend wird das kompensiert durch den Umstand, dass wir uns mit den zusätlichen CPU Zyklen zum Komprimieren ein kleineres Datenpaket erkaufen und sich dieses mit geringerem Resourcenaufwand übertragen lässt. Eine (resourcen-technisch) teurere Connection muss weniger lange aufrechtgehalten werden.

Und nicht vergessen: Auf der Positiv-Seite steht ein geringer Bandbreiten-/Traffic-Bedarf sowie schnellere Ladezeiten (insbesondere für schmallbandig angebundene Benutzer).

Es gibt also viele Vorteile – aber gibt es dabei auch einen Haken? Ja: mod_gzip einrichten und konfigurieren… Wenn das Projekt umzieht, muss die Konfiguration auf den neuen Server übernommen werden. Oder wenn das Projekt auf einem Shared-WWW-Server liegt, könnte dort mod_gzip evtl. nicht installiert sein.

Die Lösung:
Wenn man es hauptsächlich mit dynamischen Inhalten (z.b. per Datenbankabfrage erstellte Seiten) zu tun hat, so wird man sich wahrscheinlich für die “on the fly” Lösung interessieren und da liegt es dann nahe, dass man (übrigens ganz ohne Beteiligung von mod_gzip) php für die Aufgabe des Komprimieres einpannt. Alles was dazu nötig ist, ist das Einfügen des folgenden Codes als erste Zeile:

< ?php ob_start("ob_gzhandler"); ? >

Damit wird dann der HTML Code bevor er an den Browser gesendet wird komprimiert. Wenn also php sowieso schon im Einsatz ist, so bietet sich diese Lösung an um dem mog_gzip overhead aus dem Wege zu gehen. Alles was zu tun ist ist das einbringen der o.g. Anweisung in jede php Seite. Evt. noch statische HTML-Seiten könnten nun nach php umbenannt werden und mit der Zeile erweitert werden – aber das wäre natürlich viel Handarbeit.
Eleganter geht es, wenn man auch .htm bzw. .html Dateien durch die php engine verarbeiten lässt. Hierzu ändert man in der .htaccess Datei einfach:

AddHandler application/x-httpd-php .html .htm

bzw. in der Apache-Config:

< IfModule mod_php4.c>
AddType application/x-httpd-php .html .htm
< /IfModule>

Damit wird erreicht, dass nicht nur .php Dateien durch die php engine gehen sondern auch .htm und .html Dateien durch den Parser laufen.

Damit diese Dateien nun noch komprimiert werden ohne dass wir die o.g. Anweisung in alle Dateien einbringen, können wir in der Apache Config bzw. der .htaccess-Datei einfach:

php_flag output_buffering On
php_value output_handler ob_gzhandler
php_flag zlib.output_compression Off

diese Zeilen einfügen und damit per Voreinstellung die Komprimierung aktivern. Beachten Sie, die zlib-Komprimierung auszuschalten, damit nicht beide Algorithmen greifen – dies würde zu einem fehlerhaften Output beim Browser führen.

Ob mit diesen Einstellungen die http Komprimierung funktioniert können Sie z.B. über http://www.websiteoptimization.com/services/analyze/ prüfen.

Beachten Sie bei dieser Lösung, dass Sie nun per Voreinstellung alle php Dokumente durch den ob_gzhandler bearbeiten lassen. Dies kann zu Seiteneffekten (mit entsprechenden Warnungen) führen, wenn Sie php Anwendungen fahren die ihrerseit diesen Handler verwenden. Anwendungen wie phpBB, Postnuke oder DAlbum lassen per Configuration jedoch die Komprimierung deaktivieren, so dass der Handler nicht doppelt gesetzt. (Die deaktivieren die Komprimierung im Webinterface der Anwendung; Die Seiten werden aber dennoch komprimiert, weil Sie das im config so eingestellt haben).

Für Anwendungen, die binär-Daten wie z.b. Bilder per php aussenden (z.b. DAlbum, Activebarcode) sollten Sie die Komprimierung nicht aktivieren, denn die binärdaten/Images sind ja bereits komprimiert. Die nochmalige Komprimierung bringt dann natürlich nichts und kostet nur Resourcen. Setzen Sie den output_handler wieder auf NULL für die entsprechenden Verzeichnisse:

< Directory /mypath/gallery>
php_value output_handler NULL
< /Directory>

Weitergehende Informationen und Diskussionen gibt es unter www.php.net/ob_gzhandler.