Home Menü

WordPress – Optimierung durch Komprimierung von Dateien

Die Komprimierung von Dateien bei der Auslieferung einer Webseite kann die Ladezeit für den Besucher deutlich reduzieren. So kann die Größe von klassischen HTML- oder CSS-Dateien durch Komprimierung im Durchschnitt um 70 Prozent reduziert werden. Was dazu nötig ist? Ein paar Codezeilen in der .htaccess-Datei Ihrer Webseite.

Dieser Artikel ist Teil der Guideline High-Performance Websites mit WordPress.

Grundlagen

Wie im Artikel Reduzierung von HTTP Requests bereits ausführlich gezeigt, werden beim Aufruf einer Webseite vom Browser verschiedenste HTTP GET Requests an den Webserver abgesetzt. Ein Beispiel für einen HTTP GET Request beim Aufruf der Startseite von Blog IT-Solutions könnte wie folgt aussehen:

GET / HTTP/1.1
Host: www.blog-it-solutions.de
User-Agent: Mozilla/5.0 (...) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate

Die entscheidende Zeile im obigen Code beginnt mit Accept-Encoding. Diese Zeile sorgt dafür, dass der Webserver in seinem HTTP Response – wenn möglich – eine komprimierte Datei (in diesem Fall eine HTML-Datei) zurück liefert. Diese wird, wenn eine Komprimierung seitens des Webservers möglich ist, entweder mittels gzip oder deflate komprimiert.

Bitte achten Sie darauf, dass in der Regel nur HTML-Dateien, CSS– und JavaScript-Dateien (u.a.) diese Methode der Komprimierung nutzen. Es wäre zwar prinzipiell auch bei Bildern oder PDF-Dateien möglich, allerdings würde dies im schlimmsten Fall sogar zu einem Anstieg der Dateigröße führen. Mehr Infos dazu lesen Sie im nächsten Artikel dieser Serie.

Zur Vollständigkeit noch eine kleine Information am Ende des Abschnitts: Damit eine komprimierte Übertragung von Dateien möglich ist, muss sowohl der Browser als auch der Webserver mit komprimierten Dateien umgehen können. Zum einen muss der Webserver die verschiedenen Dateien serverseitig komprimieren, damit diese in reduzierter Dateigröße über das Internet übertragen werden können. Zum anderen muss der Browser in der Lage sein, die erhaltene Datei wieder zu entpacken, damit diese fehlerfrei dargestellt werden kann. Letzteres ist allerdings ab Internet Explorer 6.0 und Mozilla Firefox 5.0 problemlos möglich.

Test des Webservers – Komprimierung bereits aktiviert?

Ob Ihr Webserver aktuell bereits komprimierte Dateien ausliefert, können Sie sehr leicht mit Firebug im Tab Netzwerk überprüfen:

Steht der Wert Content-Encoding im Antwort-Header auf gzip oder deflate, dann liefert Ihr Webserver zumindest HTML-Dateien bereits komprimiert aus. Falls CSS-Dateien und JavaScript ebenfalls bereits komprimiert ausgeliefert werden, dann können Sie – theoretisch – an dieser Stelle des Artikels bereits zu Lesen aufhören.

Eine andere – vielleicht einfachere Möglichkeit – zu testen, ob die eigene Webseite (HTML-Datei) bereits komprimiert ausgeliefert wird, ist der Compression-Test auf whatsmyip.org.

Konfiguration am Webserver für die komprimierte Auslieferung von Dateien

Obwohl mittlerweile alle gängigen Browser mit komprimierten Dateien umgehen können, muss auf manchen Webservern noch die nötige Konfiguration vorgenommen werden, damit dieser auch komprimierte Dateien ausliefert. Unter Apache 2.x geschieht dies mithilfe des mod_deflate Moduls. Anders als der Name vermuten lässt, kann dieses Modul nicht nur mit der deflate Kompression umgehen, sondern auch mit gzip.

Hinweis: Um die Konfiguration erfolgreich durchführen zu können, muss auf Ihrem Webserver bereits das Modul mod_deflate aktiviert sein. Dies ist bei vielen Anbietern bereits im Standard der Fall. Wenn Sie nur über einen Shared-Hosting-Tarif verfügen und das Modul noch deaktiviert ist, prüfen Sie in der Weboberfläche des Anbieters ob eine manuelle Aktivierung möglich ist oder wenden Sie sich an den Support.

Grundsätzlich gibt es beim Apache Webserver zwei verschiedene Wege um die Komprimierung zu aktivieren:

  • Änderung der Konfigurationsdatei httpd.conf auf dem Webserver (Zugriff auf Konfigurationsdatei notwendig)
  • Änderung der .htaccess-Datei im Root-Verzeichnis der Webseite

Prinzipiell empfiehlt Apache die Konfiguration via .htaccess-Datei nur, wenn der Webseitenbetreiber keinen Zugriff auf die Konfigurationsdatei (httpd.conf) besitzt. Da viele Leser allerdings keinen direkten Zugriff auf diese Datei haben, wird im Folgenden die Konfiguration via .htaccess-Datei beschrieben.

Eine der simpelsten Konfigurationen, welche einfach an das Ende der im Root-Verzeichnis liegenden .htaccess-Datei angefügt wird, sieht wie folgt aus:

<IfModule mod_deflate.c>
  <FilesMatch "\.(html|css|js|txt)$">
    SetOutputFilter DEFLATE
  </FilesMatch>
</IfModule>

Erläuterung: Das IfModule-Statement bewirkt, dass der Code innerhalb der Kontrollstruktur nur ausgeführt wird, wenn das Modul mod_deflate auch geladen wurde. Somit werden Konfigurationsfehler und im schlimmsten Fall sogar Abstürze des Apache Webservers verhindert. Die nächste Codezeile, beginnend mit FilesMatch, stellt ebenfalls wieder eine Art Kontrollstruktur dar, welche bewirkt, dass nur Dateien mit der Endung .html, .css, .js und .txt durch SetOutputFilter DEFLATE komprimiert werden.

Eine erweiterte Version dieser Konfiguration, mit Verwendung von MIME-Types und Ausschluss älterer Browser, könnte wie folgt aussehen:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html 
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE text/plain 
  BrowserMatch ^Mozilla/4 gzip-only-text/html 
  BrowserMatch ^Mozilla/4\.0[678] no-gzip 
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
</IfModule>

Erläuterung: Wie im Beispiel zuvor, werden auch hier mittels IfModule potentielle Apache-Fehler vermieden. Die Code-Zeilen beginnend mit AddOutputFilterByType bestimmen die MIME-Typen, welche in Zukunft komprimiert ausgeliefert werden sollen. Hierzu zählen HTML-Dateien (text/html), CSS (text/css), JavaScript (application/x-javascript) und Text (text/plain). Anschließend werden bestimmte Browser von der komprimierten Übertragung ausgeschlossen. Dies ist nötig, da ältere Browser zwar dem Webserver via HTTP Header signalisieren, dass sie mit komprimierten Dateien umgehen können, letztlich aber bei der Verarbeitung dieser Dateien Probleme haben.

Hinweis: Einige WordPress-Plugins wie beispielsweise WP SuperCache (/wp-content/cache/.htaccess) oder Autoptimize (/wp-content/cache/autoptimize/.htaccess) verwenden ihre eigenen .htaccess-Dateien. Falls Sie also eines dieser Plugins verwenden, dann beachten Sie bitte, dass diese .htaccess Dateien in einigen Fällen (bei Abruf der optimierten bzw. gecachten Dateien) die Einstellungen der .htaccess-Datei im Root-Verzeichnis überschreiben.

Performance-Vergleich

Leider ist in diesem Artikel der Guideline kein aussagekräftiger Performance-Vergleich möglich, da auf Blog IT-Solutions die Komprimierung von Dateien bereits längere Zeit aktiviert ist. Grundsätzlich kann man allerdings zahlreiche Statistiken (u.a. von Steve Souders) heranziehen, welche besagen, dass die Dateigröße durch Komprimierung im Schnitt um etwa 70 Prozent reduziert werden kann. Dies spart vor allem Zeit beim Content Download (Erläuterung).

Auch ein Test über das bereits vorgestellte Tool von whatsmyip.org zeigt, dass die Komprimierung speziell bei der HTML-Datei große Wirkung zeigt:

Fazit

Durch die komprimierte Übertragung von Dateien vom Webserver zum Browser kann die benötigte Zeit von einzelnen Requests teils erheblich reduziert werden. Da die Konfiguration mittels .htaccess-Datei recht einfach und vor allem schnell vorgenommen ist, sollten Sie in Zukunft auf diese Optimierungsmöglichkeit nicht mehr verzichten.

Im nächsten Teil dieser Artikelserie beschäftigen wir uns im Speziellen mit der Optimierung von Bildern auf Webseiten.

Veröffentlicht von Josef Seidl

Josef Seidl hat an der TU München und der Stanford University Wirtschaftsinformatik studiert, bevor er mit INNOSPOT sein eigenes Unternehmen gründete. Er ist begeistert von Technik, schätzt performante Webseiten und ist gerne in den Bergen unterwegs. Zu finden ist er auch bei LinkedIn und privat bei Twitter.