:: apt-get it or for-get it ::
Blog-Optimierungen: Der Einsatz von Gzip
In dem Artikel Grenzerfahrungen: WP Cacheplugins, Apacheoptimierung oder doch neue Hardware? hatte ich grob nach Möglichkeiten gefragt diesen oder allgemein Blogs zu optimieren. Eine Sache, die ich relativ schnell umsetzen konnte, habe ich dabei schon realisiert. Mein Dank geht an allen Kommentatoren dieses Artikels, die so unterschiedliche Lösungsvorschläge präsentiert hatten, dass ich noch mehrere Wochen daran arbeiten kann.
Was mir bis dato neu war, war die Firefox Extension YSlow, welches sich in die Extension Firebug integriert und genau für den Einsatz, der Analyse eine Webseite einen hervorragenden Dienst erledigt. Mit Firebug selber kann man schon sehr gut die Ladeperformance, der einzelnen Elemente einer Webseite analysieren und sich in einer schönen Zeitleistengrafik ansehen. YSlow bietet darüberhinaus noch viele weitere Tipps und Vorschläge. Unter anderen wurde mir auch der Einsatz von Gzip vorgeschlagen.
Einsatz von gzip als Apache2 Modul
Zur Verdeutlichung, was gzip auf meine Index-Seite bewirkt:
Ohne gzip:
mit gzip:
Das sind also gut 2MB Reduktion nur auf der Index Seite, was schon recht beachtlich ist, finde ich, wenn man sich dazu auch noch die Ladezeiten ansieht. Zu mindestens bei mir haben sie sich von weit über 10 Sekunden auf rund 3 Sekunden reduziert. Das nenne ich schon mal Fortschritt. Ob man das dann auch schon gefühlt merkt, weiß ich nicht. Könnt ja mal kurz Bescheid geben.
Ich habe dazu das Apache2 Modul mod_deflate benutzt. Auf einem Debian/Ubuntu-Rechner aktiviert man es wie folgt:
a2enmod deflate
Dazu noch folgende Erweiterungen in die httpd.conf bzw. in die zugehörige Site-Konfiguration des virtuellen Apache-Host:
# Deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript image/jpeg image/gif image/png
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
DeflateCompressionLevel 9
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
und abschliessend ein Neuladen der Konfiguration des Webservers mit:
/etc/init.d/apache2 force-reload
Neuere Browser beherrschen den Umgang mit komprimierten Inhalten, mit BrowserMatch schliesst man problematische Browser aus. Mit DeflateCompressionLevel kann man den Kompressionslevel regulieren. Mit dem Schlüsselwort AddOutputFilterByType legt man fest, welche Inhaltstypen komprimiert werden. Den grössten Effekt hat man wohl bei Textdateien, wie css, js oder html. Aber auch meine Bilddateien lassen sich noch gut komprimieren. Eventuell sollte ich aber lieber darauf achten, dass ich meine Bilder besser schon beim Publizieren kleiner rechne.
Das ist natürlich nur ein Anfang. Als Nächstes teste ich den Einsatz eines Cache Plugin für WordPress und eventuell möchte ich gerne ein paar CSS und Javascript Dateien zusammenfassen, was mich aber vor weiteren Problemen stellt, da die meisten dieser Dateien von irgendwelchen Plugins stammen.
Links
Grenzerfahrungen: WP Cacheplugins, Apacheoptimierung oder doch neue Hardware?
https://addons.mozilla.org/de/firefox/addon/5369
https://addons.mozilla.org/de/firefox/addon/1843g
| Artikel drucken | Dieser Beitrag wurde von Oliver am 16. Januar 2009 um 08:41 veröffentlicht und unter Web, Wordpress abgelegt. Du kannst allen Antworten zu diesem Beitrag durch RSS 2.0 folgen. Du kannst eine Antwort schreiben oder einen Trackback von deiner eigenen Seite hinterlassen. |
vor 1 Jahr
Klasse Beitrag, danke für die Hinweise und Infos.
Bei einem Projekt vor einer Weile hab ich noch den Tomcat schön so konfiguriert, dass alles optimal läuft, bei meinem eigenen Apache hab ich natürlich an sowas nicht gedacht.
Werd das am Wochenende auch mal bei mir umsetzen. :)
vor 1 Jahr
Sag mal: Findest Du nicht, dass 500kb Javascript bzw. 2mb insgesamt ziemlich heftig sind? Auch komprimiert isses net recht viel besser, da der Client die 500kb Javascript ja trotzdem interpretieren muss…
vor 1 Jahr
@Tscherno: auf jeden Fall, viel zu viel
Vieles stammt sogar aus Plugins, die ich gar nicht mehr benutze.
vor 1 Jahr
Was mir dazu einfällt. In der Regel ist es besser den Apache mit
apache2ctl graceful
neu zu starten. Dann werden nicht alle Verbindungen sofort getötet sondern warten jeweils auf ihr Ende. (Also aktive Downloads werden nicht abgebrochen.)
Siehe auch http://developer.yahoo.com/yslow/help/#guidelines
vor 1 Jahr
Leider hat nicht jeder Zugriff auf die httpd.conf. In der .htaccess meiner Blogs ist folgendes eingetragen, damit fahre ich eigentlich ganz gut (Bilder werden vom Server automatisch mit Etag versehen):
SetOutputFilter DEFLATE
Um zu sehen, ob Elemente einer Webseite GZIP-komprimiert sind, braucht man kein YSlow, auch kein Firebug. Safari hat das Werkzeug im Lieferumfang ;)
vor 1 Jahr
@gillyberlin lies mal http://tinyurl.com/7nl2wj
vor 1 Jahr
Danke für den Tipp mit graceful Martin, ich habe bisher immer die Hardcorevariante gewählt ;)
vor 1 Jahr
Hi Oli,
ich betreibe selbst einige Heavyload-Seiten, und benutze auch seit Jahren die gzip-Kompression.
Deine Einstellung für DeflateCompressionLevel ist mit dem Wert 9 wirklich sehr hoch.
Meiner Erfahrung nach bringt es nicht wirklich viel, den Wert über 3 oder 4 zu setzen.
Das erhöht dann nur noch den Serverload.
Ich habe nach einigen Tests das Kompressionslevel auf 2 gesetzt. Das war bei mir ein sehr guter Kompromiss aus Größe und Serverbelastung.
mfg,
karsten
vor 1 Jahr
@Martin: ja richtig, ich benutze sonst auch immer: /etc/init.d/apache2 reload, was diesem graceful entspricht, leider funktioniert das in diesem Fall aber nicht mit dem gzip, du hast aber recht immer erst die weichere variante benutzen
@Sergej Müller: stimmt, aber nicht jeder hat einen Safari
@Karsten: ok hier werde ich dann wohl noch ein bisschen experimentieren
vor 1 Jahr
@Oli
Nein? Oh ;)
Ich wollte nur hingewiesen haben, damit Blogger auf dem Mac jetzt nicht nach FF-Addons suchen, um rausfinden zu können, ob auf den Webseiten GZIP aktiv ist.
vor 1 Jahr
Hm, also 80 HTTP Request für eine einzige Seite erscheint mir doch als extrem viel.
Um JS und CSS-Ressourcen zu minimieren und kombinieren gibt es beispielsweise http://code.google.com/p/minify/.
Für WordPress existiert bestimmt ein Plugin mit ähnlicher Funktionalität.
vor 3 Wochen
http://wordpress.org/extend/plugins/wp-minify/
vor 1 Jahr
Auch lesenswert: http://www.jestro.com/web-design/optimize-apache-slow-vps-wordpress/
vor 1 Jahr
Achja was man bei GZIP-Komprimierten Seiten noch beachten sollte: Die Seite wird dann erst aufgebaut wenn Sie komplett übertragen ist!
vor 1 Jahr
@Tscherno
Ich glaube, bei modernen Browsern ist es sowieso der Fall, sie warten mit der Ausgabe auch ohne GZIP-Content, um das “springen” der Seite zu vermeiden.
vor 1 Jahr
Ich nutze auf meinem Server auch mod_deflate. Meiner Erfahrung nach bringt es nur höhere Serverlast JPGs und GIFs erneut zu komprimieren, als das sie noch komprimiert werden können. Ich würde, an deiner Stelle, dies rausnehmen.
vor 1 Jahr
Effizienter ist es, Bilder direkt beim Hochladen – also beim Verfassen des Artikels und Einfügen der Bilder – optimieren zu lassen. Gibt’s als Plugin für WordPress: http://playground.ebiene.de/752/wordpress-plugin-bilder-beim-upload-optimieren/
vor 1 Jahr
Das mit den vorher komprimieren bringt mich auf einen Gedanken: Kann man die Javascripts vieleicht schon GZIPed auf dem Server ablegen? Dann könnte man sich die CPU-Load fürs Live-Komprimieren komplett sparen!
vor 1 Jahr
@Tscherno: aber dann können wohl ältere Browser damit nichts anfangen
vor 1 Jahr
Genau, für solche Fälle baut man in der httpd.conf oder in der .htaccess eine Abfrage und an die älteren Browser wird die unkomprimierte Version der Dateien ausgegeben.
vor 1 Jahr
YSlow betrügt dich leider ein bisschen. Die 2MB kommen aus den Bildern die Mittels Lightbox nachgeladen werden. Aus irgendwelchen Gründen lädt YSlow bei seiner Berechnung die vollaufgelösten Bilder, die der Nutzer erst beim Klick ansieht.
Aber schön das ich dir helfen konnte mit meinen Tipps :-)
vor 1 Jahr
Ältere Browser können mit dem Javascript und CSS Gedöns meist eh nix anfangen…
vor 1 Jahr
@Tscherno: Kommt drauf an, was für dich alt ist… IE6 auch?
vor 1 Jahr
Ich finde, du betreibst viel zu viel Symptombehandlung, statt der Ursache nachzugehen. Du nutzt u. a. 17 JavaScript-Files (dazu Protoype und jQuery gemixt!).
Auch die Bilder sind viel zu gewichtig – das hier bspw. wiegt 200 kB, da PNG. Eine sinnvolle Komprimierung via Photoshop (oder ein anderes Programm, was Web-Bilder anständig speichert) in einem verträglichen Format (JPG) und du kannst das auf ein Minimum reduzieren. Auch wenn mittlerweile sehr viele Leute mit DSL unterwegs sind, darf man solche Aspekte nicht aus den Augen verlieren.
vor 1 Jahr
Achja nochwas:
GZIP vom Server komprimiert nur AFAIK den Text der Übertragen wird. An Bildern etc. wird nichts geändert.
Die Anzeige von YSlow zeigt dir auch das die Ersparnis nicht wegen zippen ist, sondern weil aus irgendeinem Grund nur 30 statt 60 Bilder geladen werden ;)
vor 1 Jahr
Ja, IE6 ist auch alt. Für den biete ich nur noch eine _lesbare_, _bedienbare_ Seite an. Design und Schnickschnack sind mir da völlig egal. Es gibt keinen Grund mehr mit dieser Virenschleuder unterwegs zu sein.
vor 1 Jahr
Hab jetzt auch mal mod_deflate bei mir aktiviert, allerdings nur mit Kompressionsstufe 3 und ohne Bilder zu komprimieren. Ich achte eigentlich da drauf, dass Bilder bei mir nicht zu groß sind.
Ob es nun schneller ist, kann ich nicht so recht beurteilen. Ich befürchte fast, der Overhead durch das Komprimieren macht die Beschleunigung durch das Übertragen komprimierter Daten wieder zunichte. ^^
vor 1 Jahr
@Haf:
mod_deflate und alle anderen können keine Bilder komprieren, die sind schon von sich aus komprimiert. Zippe bei dir lokal mal ein JPG, das wird sogar noch größer!
vor 1 Jahr
@ Andi: Dass Jpegs sich in der Regel nicht mehr komprimiren lassen, ist mir bekannt. Bei PNGs ist es soweit ich weiß gleich, bei GIFs könnte ich mir auf Grund der Lauflängenkomprimierung vorstellen, dass da ein Packer mit gutem Algorithmus noch was verkleinern kann, habs aber nie probiert.
Meintest Du mit Deiner Aussage ganz allgemein Komprimieralgorithmen?
Ich hab ja wie gesagt die Bild-Parameter aus der Konfiguration rausgenommen bei mir. :)
vor 1 Jahr
Es gibt einen Dienst im Netz, der unter Umständen Bilder zusätzlich verkleinern kann. Dabei werden u. a. Header-Informationen entfernt, die nicht von Bedeutung sind, ob da noch zusätzliche Kompressionsverfahren genutzt werden, weiß ich leider nicht mehr genau. Ich finde das entsprechende Bookmark nicht mehr … *kotz*
vor 1 Jahr
smush.it, gibt es auch als fertiges Plugin für wordPress, hab ich oben den Link gepostet.
vor 1 Jahr
So, Gzip ist jetzt bei mir auch an, mit ist aufgefallen, dass das WP-Admin jetzt erheeeeblich schneller läuft. Nice!
vor 1 Jahr
Man sollte im Auge behalten, dass Gzip zwar den Traffic verringert, dafür die Prozessorlast erhöht
vor 1 Jahr
Hmm ich habe noch ein kleines Problem, yslow bemängelt bei mir, dass 3 js und ein paar css Dateien nicht gzipped seien.
Meine Konfig sieht so aus:
# Deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript image/jpeg image/gif image/png
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
DeflateCompressionLevel 2
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
Habe ich was vergessen!?
vor 1 Jahr
Ich werde das auch mal installieren. Mal sehen was es so bringt.
vor 1 Jahr
Die “BrowserMatch”-Zeilen stimmen teilweise nicht, da fehlen Backslashes. Siehe http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
vor 7 Monaten
“Das ist natürlich nur ein Anfang…” daher habe ich mich in den letzten Tagen ein wenig näher mit dem Thema beschäftigt und einen kleinen Blog-Eintrag dazu geschrieben ->
http://voku-online.de/comment-n153.html