Webseiten zippen
Dieser Tipp ist nicht speziell auf Textpattern gemünzt und kann auf jedem Apache2-Webserver angewendet werden, der über die entsprechenden Module verfügt.
Wenn man viel Bild- und Textmaterial auf der Website hat, kann das Laden der Seiten schon deutlich und vor allem auffallend lang werden. Es gibt aber Abhilfe: mod_deflate – ein Apache-Modul das die Daten beim Ausliefern an Browser, welche das verstehen, komprimiert (zippt) und damit nicht nur Ladezeiten optimiert, sondern auch weniger Traffic erzeugt.
In unserer .htaccess finden sich die folgenden Zeilen:
<ifModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript
<ifModule mod_headers.c>
Header append Vary User-Agent
</ifModule>
</ifModule>
Ein paar Erläuterungen:
ifModule – diese XML-artige “Umrahmung” sorgt dafür, dass der Inhalt nicht geladen wird, wenn mod_deflate auf dem Server nicht vorhanden ist. Man kann den Codeschnippsel also ungestraft auch auf “inkompatiblen” Webservern in die .htaccess kopieren. Es wird dann eben nur nicht “deflated”.
AddOutputFilterByType – das ist die eigentliche Magie des Ganzen. Alle Dateien, deren Typ in dieser Zeile aufgeführt werden, sollen vom Server komprimiert werden.
Zeilen 3 bis 5 – das ist ein Workaround für Besucher, die hinter Proxyservern sitzen. Der Proxyserver könnte/kann die Dateien per mod_deflate laden, der Client hinter dem Proxy sollte das nicht. Damit das funktioniert, sollte mod_headers auf dem Webserver verfügbar sein. In den meisten Fällen ist das der Fall.
Mit diesen wenigen Zeilen konnte ich die Pakete aus PatternText.de auf gut 1/5 ihrer tatsächlichen Größe einstampfen. Mal mehr, mal weniger. Es lohnt sich.
PS: Man sollte natürlich vor und nach Arbeiten an der .htaccess ausgiebigst Backups der Datei anlegen und bei Updates an Textpattern darauf achten, dass die Zeilen nicht durch die neue .htaccess im Update überschrieben werden.
Patrick Kollitsch 3 Kommentare
Re. Zeilen 3-5
Auf http://httpd.apache.org/docs/2.0/mod/mod_deflate.html heißt es:
“If you use some special exclusions dependent on, for example, the User-Agent header, you must manually configure an addition to the Vary header to alert proxies of the additional restrictions. For example, in a typical configuration where the addition of the DEFLATE filter depends on the User-Agent, you should add:”
Da in Deinem 6-Zeiler Beispiel keinerlei User-Agent abhängige Filter eingebaut sind, kann das doch im Sinne von “if …, (then) you must …” entfallen, oder verstehe ich das falsch?
Oder andersrum: Es schadet nicht, aber in Deinem Beispiel ist es kein Muss. Oder?
Ich bin mir nicht sicher, ob das so ist :) Fuer mich war das immer ein AddOn, das dem jeweiligen Proxy sagte, dass es Unterschiede zwischen ansonsten identischen Seiten geben kann, da die wiederum gezippt sind und evtl. in der Groesse variieren koennen.
Kann gut sein, dass ein kleines Problem mit dem Cachen der Ueberschriften hier im Blog mit dem mod_deflate zusammen haengt. Ich werde also ueber kurz oder lang das ganze intensiver ansehen muessen.
Nach den Anwendungsbeispielen (s. Link o.) dient es der Unterscheidung von Browsern, die mit gzip oder deflate nicht umgehen können. Im Zweifelsfall (meine Interpretation) dekomprimiert der Proxy und liefert unkomprimiert aus. Aber:
Ich verwende bei mir asy_jpcache und habe zusätzlich Deinen Vorschlag eingebaut. Bis jetzt sehe ich keinen Unterschied bei gecachten Seiten. Bei ungecachten Seiten bin ich mir noch nicht ganz sicher, ob die Antwortzeiten nicht länger geworden sind. Kann ja sein, dass evtl. der doppelte Komprimierversuch Zeit kostet. Aber an meinen Firefox wird in beiden Fällen brav die asy_jpcache Variante ausgeliefert (sprich: wird erzeugt oder ist vorhanden, danach durchgereicht).
© 2008/2009 David's Neighbour und Autoren