Wenn man seine Website mit Pagespeed überprüft und dabei die Meldung „Enable Compression“ (Komprimierung anschalten) erhält, dann ist das ein Hinweis darauf, dass die Daten unkomprimiert vom Server zum User gelangen. Gerade bei größeren Webseiten kann man durch eine gzip-Compression aber einiges an Datenmenge (ca. 70-80 %) und damit auch an Übertragungszeit einsparen.
Generell gibt es 3 Möglichkeiten, wie man die gzip-Compression nutzen kann. Die einfachste ist ein simpler Eintrag in der .htaccess:
1. gzip-Compression über die .htaccess
<IfModule mod_deflate.c>
<FilesMatch "\\.(js|css|html|xml)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
In der ersten Zeile wird geprüft, ob das Modul mod_deflate auf dem Server aktiviert ist. Das ist nämlich Voraussetzung zur Nutzung der gzip-Compression. Danach werden dann alle Dateien mit der Endung .js, .css, .html, .xml komprimiert. Es können natürlich noch weitere Endungen hinzugefügt werden. Allerdings macht eine Kompression von Grafikformaten wie z. B. jpg, gif oder png wenig Sinn, da diese bereits von Haus aus komprimiert sind. Ein Nachteil dieser Methode ist, dass das Modul mod_deflate nicht bei allen Hostern installiert ist. In diesem Fall bietet sich Methode 2 an.
2. gzip-Compression mit PHP
Bei dieser Methode wird einfach bei jeder Seite, die man komprimieren möchte, in der ersten Zeile folgender Code eingefügt:
<?php
ob_start("ob_gzhandler");
?>
Diese Methode hat 2 Nachteile. Zum einen funktioniert sie nur mit php-Dateien. Die Datei muss also die Endung .php haben (dies kann man zwar auch umgehen, aber darauf will ich jetzt nicht näher eingehen). Außerdem muss der Code in jede Datei, die man komprimieren möchte, extra eingefügt werden. Wenn man viele Dateien hat, ist das natürlich eine Menge Arbeit. Deswegen sollte man zuerst die 1. Möglichkeit (gzip-Compression über die .htaccess) ausprobieren und nur wenn diese nicht funktioniert, die gzip-Compression über php erledigen.
3. Dateien vorkomprimieren
Die beiden ersten Methoden haben das Problem, dass sich dadurch die Serverlast etwas erhöht. Das ist eigentlich nicht weiter tragisch, da die eingesparte Datenmenge diesen Nachteil mehr als nur wettmacht. In einigen Fällen ist es aber trotzdem sinnvoll, die Kompression vorab von Hand zu erledigen. Dies bietet sich vor allem bei Dateien an, die einerseits sehr groß sind und andererseits nur selten geändert werden.
Wem bei dieser Beschreibung spontan Javascript-Bibliotheken wie z. B. jQuery einfallen, der liegt damit vollkommen richtig. In der aktuellen Version 1.4.2 hat jquery.js eine Größe von ca. 80 kb. Durch eine manuelle Kompression lässt sich die Dateigröße auf ca. 25 kb verringern. Nachdem man die Datei mit einem Packer wie z. B. 7zip verkleinert hat, kopiert man sie einfach in das gleiche Verzeichnis wie die Originaldatei. Um Kompatibilitätsprobleme mit dem Safari-Browser zu vermeiden, sollte man die Endung der komprimierten Datei von .gz auf .jgz ändern. Danach fügt man noch folgenden Code, den ich auf tutorialajax.com gefunden haben, in die .htaccess ein:
RewriteEngine on
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.jgz -f
RewriteRule (.*)\.js$ $1\.js.jgz [L]
AddType "text/javascript" .js.jgz
AddEncoding gzip .jgz
Mit diesem Code wird die gepackte Version der Datei anstelle der Originaldatei ausgeliefert.
Nutzung der gzip-Compression mit WordPress
WordPress-User können die oben beschriebenen Methoden ebenfalls problemlos einsetzen. Aber wie so oft bei WordPress, gibt es für diesen Zweck natürlich auch ein Plugin, das einem auch bei der gzip-Compression das Leben erleichtern. Dabei handelt es sich um das Plugin wpCompressor des bekannten WordPress-Entwicklers Sergej Müller. Das Plugin setzt für die Komprimierung die oben beschriebene Methode 2 (gzip-Compression mit PHP) ein, die allerdings nicht so schnell ist wie die 1. Methode. Deshalb sollten auch WordPress-User lieber die gzip-Compression über die .htaccess nutzen und nur, wenn der Hoster dies nicht ermöglicht, zum Plugin greifen.
Test der gzip-Compression
Zum Testen, ob die gzip-Compression auch tatsächlich funktioniert, kann man dieses PHP-Skript verwenden. Einfach den Namen der Website eintippen und auf „Check“ klicken. Dann kriegt man angezeigt, ob die angegebene Website komprimiert ist und welche Datenmenge eingespart wurde.
Fazit: Die Komprimierung von Webseiten macht auf alle Fälle Sinn und ist mit wenig Aufwand verbunden. Die einfachste und schnellste Methode ist die gzip-Compression über die .htaccess, die man durch eine Vorkomprimierung einzelner Dateien noch ergänzen kann. Falls dies vom Hoster nicht unterstützt wird, sollte man die Daten per PHP-Aufruf komprimieren.
Artikelreihe Webseiten beschleunigen:
Teil 1: Dateigröße von Grafiken verkleinern
Teil 2: Expires-Header verwenden
Teil 3: Parallele Downloads
Teil 5: Code optimieren
Hi, habe mich vor einiger Zeit auch mit dem Thema beschäftigt und kann nur dazu raten folgende Komponenten zu installieren:
– nginx als Webserver
http://suckup.de/blog/2010/07/26/webserver-beschleunigen/
– php-fpm 5.3.x + xcache
http://suckup.de/blog/2010/07/26/apc-eaccelerator-xcache/
Mit freundlichem Gruß,
Lars Moelleken
Ein sehr guter Artikel! Nur vermisse ich eins:
Gerade bei großen und stark frequentierten Seiten sollte man nach Möglichkeit auf dein Einsatz einer .htaccess-Datei verzichten und statt dessen die entsprechenden Anweisungen in die Config des virtuellen Hosts legen.
Dieser Ansatz hat aber auch Nachteile:
Eine .htaccess ist schneller editiert und an die Webserver-Config kommt nicht jeder Webmaster ran.
Hm, also ich würde den Artikel nicht so pauschal unterschreiben wollen.
Sicher, wenn man einen Server hat, der schlecht angebunden ist oder einen User, der ebenfalls an einer ISDN (oder schlechteren Leitung) sitzt, ist ein ZIPen des Inhalts richtig.
ABER: Moderne Browser fangen schon an, weitere Daten (Bilder, CSS-Files, etc.) zu laden, bevor die ursprüngliche Page fertig geladen wurde.
Durch ein zippen einerWebsite jedoch muss diese erst als ganzes geladen, entpackt und interpretiert werden, bevor weitere Files nachgeladen werden können.
Mit Firebug und dessen Page Speed Analyse kann man dies ziemlich genau nachvollziehen.
Aus diesem Grund habe ich bei meinen Server das zippen abgeschaltet, bzw. nur für Files vorgesehen die größer als 1MB sind oder keine HTML-Files sind.
@voku1987 + @Heiko
Der Artikel und die ganze Artikelreihe ist hauptsächlich für Webspace-Nutzer gedacht. Wenn man einen eigenen Server mit Root-Zugriff hat, hat man natürlich noch mehr Möglichkeiten, seine Webseiten zu beschleunigen.
@Wolfgang
Wie ich in der Artikelreihe ja mehrfach erwähnt habe, setze ich ja auch Pagespeed ein, um herauszufinden, wie ich meine Webseiten beschleunigen kann. Wie man damit einen Geschwindigkeitsverlust durch das Zippen erkennen kann, weiß ich aber nicht. Vielleicht kannst du das nochmal näher erklären.
Wenn man nur normalen Webspace hat, ist es aber zum Teil auch gar nicht möglich, die gzip-Kompression für html-Dateien auszuschalten. Mein Webhoster hat für HTML-Dateien die gzip-Kompression automatisch aktiviert. Da kann ich in die .htaccess reinschreiben, was ich will.
Zum Vorkomprimieren: Das kling ja genial! Hiermit könnte ich augenscheinlich alle JavaScript-Dateien mit Gzip direkt auf dem Server in *.jgz-Dateien verpacken und ausliefern? Habe einige JS-Dateien die praktisch nie angefasst werden und per Deflate den Weg zum Besucher finden. So ist’s allerdings etwas weniger Arbeit für den Server…
@Wolfgang: Habe auch mit mehreren Servern und Webseiten verschiedene Tests durchgeführt und lag immer beim gepackten Datenversand zeitlich vorn. Klar sollte man Bilder, gezippte Dateien oder Videos vom FilesMatch ausschließen, aber alles was irgendwo sowas wie Text ist, brachte grundsätzlich Vorteile.
Das ganze kann natürlich ein Nachteil sein, wenn der (v)Server nicht ganz so gut bestückt ist. Aber aktuelle root-Server mit mehreren CPU-Kernen und massig RAM machen das mit links. Und selbst mein privater vServer mit nur 2 Kernen und 1 GB RAM ist bei Stresstests weit weg vom Limit.
Ich kann mod_deflate nur empfehlen!
@Daniel Gerade für Javascript-Bibliotheken ist die Vorkomprimierung wirklich sehr gut geeignet. Probiere es einfach mal aus. Ist ja nicht viel Aufwand 😀
Hallo,
ich habe eben auch den „WebPageTest“ bezüglich der Geschwindigkeit meiner Webseite gemacht. U. a. wurde die fehlende Komprimierung angemerkt. Die verlinkten Hilfeseiten haben mir das Problem nicht wirklich verständlich erläutert.
Ich bin froh, dass ich zu allen meinen „Problemfällen“ hier auf der Seite eine verständliche Antwort gefunden habe. Vielen Dank dafür.
Tach,
ich hab das ganze auch mal probiert, da ich starke Performance Probleme bei meinem Blog habe.
In der .htaccess Datei stand aber bereits folgendes:
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
BrowserMatch bMSI[E] !no-gzip !gzip-only-text/html
Wenn ich das jetzt lösche und durch den Eintrag aus dem Tutorial ersetze kommt eine 500er Fehlermeldung (Internal Error)
Wo liegt da das Problem und wie kann ich es lösen?
Momentan wird nämlich garnichts gezippt laut dem GID Test.
Bei einer anderen Seite ging das übrigens alles ohne Probleme, beides bei 1&1 gehostet (unterschiedliche Pakete) nur einmal mit Redaxo und einmal mit WordPress, da liegt übrigens der Problemfall.
Ich hoffe ihr könnt mir bei meiner Frage helfen!
@Squueeze Lösche mal deinen Browser-Cache mit STRG + F5. Falls das nicht hilft, probier mal das WP-Plugin wpCompressor aus.
Guten Morgen! Also eine Fehlermeldung bekomme ich jetzt nicht mehr nachdem ich den Browsercache gelöscht habe. Allerdings funktioniert das mit der .htaccess Datei leider immer noch nicht. wpCompressor funktioniert dafür 🙂
Der GIDZip Test sagt folgendes:
Web page compressed? Yes
Compression type? gzip
Size, Markup (bytes) 64,770
Size, Compressed (bytes) 15,233
Compression % 76.5
YSlow sagt aber weiter:
„Grade F on Compress components with gzip
There are 14 plain text components that should be sent compressed“
Obwohl es jetzt in der .htaccess steht und das Plugin an ist, den Cache hab ich davor auch nochmal gelöscht.
Danke übrigens für deine schnelle Hilfe!
Endlich einen tollen Artikel zum Thema GZIP gefunden. Einfach erklärt und es wird auch auf die Integration via htaccess eingegangen. Hat mir sehr geholfen. Vielen Dank!
Hallo,
ich war von der Anleitung zur Vorkomprimierung ebenfalls sehr angetan, funktioniert auch im FF, Opera, Chrome, Safari, nur im IE8 nicht (IE grösser oder kleiner als 8 hab ich nicht getestet).
Ist damit ein Problem bekannt? Kann man via .htaccess den IE ausschließen, sodass der die ebenfalls auf dem Server befindlichen ungezippten js-Dateien nutzt? (Gegf. durch einen Befehl ähnlich oder gleich dem oben von Squueeze beschriebenen?)
LG Wolfgang
Zur Zeit beschäftige ich mich auch mit diesem Thema und ich wollte fragen, ob die Ausführungen unter Punkt drei (Dateien Komprimieren) noch aktuell und korrekt ist.
Außerdem wollte ich fragen, ob das folgende richtig ist, so wie ich das verstanden habe.
Ich Komprimieren meine Java Skript-Datei als gzip (wobei die Endung jgz ist) und diese komprimierte Datei kommt in das gleiche Verzeichnis wie meine nicht komprimierte Java Skript-Datei.
Danach lege ich eine .htaccess mit dem unter Punkt drei aufgeführten Inhalt an und diese kommt auch in das Verzeichnis mit den Java Skript-Dateien.
Im HTML-Dokument integriere ich die nicht komprimierte Java Skript-Datei mit und das war es?
Also wenn ein Browser gzip unterstützt, dann läd er die komprimierte Java Skript-Datei.
Ist das alles richtig?
Recht herzlichen Dank schon mal für die Antwort!
Hallo Johannes,
soweit alles korrekt, nur die htaccess-Datei speicherst Du nicht im Ordner mit den js-Dateien, sondern auf der obersten Ebene Deines Webspace, dann greift sie auch für die darunter liegenden Ebenen. (Wenn Du sie bislang noch nicht gebraucht hast und Dich intensiver damit beschäftigst, wirst Du merken, dass man mit der htaccess viele sinnvolle Sachen machen kann).
LG Wolfgang
PS und zur Vervollständigung: der von mir im Post vom 24-02-12 beschriebene „Fehler“ mit dem IE hat sich erledigt; offenbar war die js-Datei nicht sauber gezippt, was die anderen Browser nicht gestört hat, aber eben den IE. Jetzt funktioniert es einwandfrei mit einer Kombination aus vorkomprimierten js-Dateien und im übrigen Komprimierung on-the-fly.
Hallo Wolfgang
Recht herzlichen Dank für deine ausführliche Antwort!
Bisher habe ich noch nicht mit einer .htaccess gearbeitet und ich weiß auch noch nicht wirklich, was man damit alles machen kann. Darüber muss ich mich erst noch informieren.
Für die Komprimierung habe ich http://refresh-sf.com/yui/ mit den vorgegebenen Standardeinstellungen verwendet.
Hallo nochmal
um alle Unklarheiten zu beseitigen, hätte ich noch folgende Frage:
ich komprimierte meine Java Skript-Datei und diese neue Datei hat dann die Endung gz.
Und diese Datei benenne ich einfach um und gebe ihr die Endung jgz
ist das richtig so?
Ja.
Danke für deine Antwort
Danke für den Tipp, klappt super. 🙂 Also die Option 1.
Moinsen Webbis,
als treuer 1und1 Kunde war die gzip Kompression eine Qual. mod_deflate funzt bei meinem Päckchen nicht und in jede Seite den Zusatz schreiben wollte ich nicht. Ergo 2 Monate gebastelt und gelesen. .htaccess abändern und ein Progrämmchen namens gzip.php (mit zlib komprimiert) funktionieren mittlerweile ohne Probleme. Damit kann man js, css und html kompriemiert ausliefern. Ohne extreme Proggi Kenntnisse sind weitere Mime Typen ergänzbar.
Gruss Silvio
Hallo, vielen Dank für diese Information. Habe ich gleich bei einem Kundenprojekt ausprobiert und die .htaccess entsprechend geändert.
Lt. Google Pagespeedtest ist die Geschwindigkeit schneller.
Gruß Rainer