WordPress schneller machen: Inhalte komprimiert übertragen und cachen lassen

WordPress treibt rund 26% aller Webseiten der Welt an. Viele dieser Webseiten sind allerdings unnötig langsam und nerven damit ihre Besucher. Mit den richtigen Handgriffen lässt sich eine WordPress-basierte Webseite deutlich schneller an den Nutzer ausliefern und in einer kleinen Serie will ich ein paar Tricks dafür sammeln. Fangen wir an mit der komprimierten Übertragung von Inhalten durch den Server und dem Caching derselbigen.

Zunächst geht es um den Apache Webserver, und da um die komprimierte Übertragung der Inhalte, dann um das Caching von bestimmten Daten und schließlich noch um das Komprimieren und Cachen von Fonts. Anschließend gibt es noch einen kleinen Hinweis zum nginx Webserver, da ist auch einiges machbar.

Vorweg sei auch gesagt, dass die Geschwindigkeitsverbesserung bzw. die Ladezeiteinsparung vorher schlecht zu bestimmen ist. Werkzeuge wie Google Page Speed Insights, GTmetrix oder auch die Pingdom Tools zeigen allerdings deutlich bessere Werte, die auch fühlbar sind, wenn diese Maßnahmen integriert worden sind.

Testergebnisse für flomei.de finden sich ganz am Ende des Beitrags…


Apache

Apache-Webserver bieten die Möglichkeit, in der .htaccess-Datei die komprimierte Übertragung von Daten zu aktivieren. Weiterhin kann für die übertragenen Daten auch ein Zeitraum gesetzt werden, indem sie gecached, also zwischengespeichert, werden. Dies verbessert die Geschwindigkeit sowohl beim ersten als auch bei allen weiteren Aufrufen der Seite.


Kompression

Die meisten Apache-Webserver haben das Modul mod_deflate aktiviert, dass eine Kompression der gesendeten Daten ermöglicht. Hierbei wird gzip genutzt, um die Daten auf dem Server zu komprimieren, bevor sie zum Browser geschickt werden. Mit diesem Verfahren lassen sich besonders gut textbasierte Daten (HTML, CSS, JavaScript) komprimieren, die Anwendung dieser Kompression auf bereits komprimierte Daten wie zum Beispiel Bilder, bringt keinen wirklichen Vorteil.

Um die Kompression mittels Deflate zu aktivieren, muss folgender Block in die .htaccess-Datei des Webservers eingetragen werden:

# Deflate Kompression fuer Textinhalte aktivieren
# http://www.flomei.de/wordpress-schneller-machen-inhalte-komprimiert-uebertragen-und-cachen-lassen/
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/atom_xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>

Bei der Suche zu mod_deflate stößt man immer wieder auch auf das Modul mod_gzip. Hierbei handelt es sich um weiteres Modul für den Apache-Webserver, das eine Kompression der zu versendenden Daten durchführt. Sowohl mod_deflate als auch mod_gzip bedienen sich dabei allerdings intern an gzip, so dass das Ergebnis nahezu gleich ist. Minimale Abweichungen können durch die Konfiguration der Module entstehen, diese sind allerdings vernachlässigbar. mod_deflate ist tendenziell weiter verbreitet und damit die erste Wahl, weshalb hier auf den Code für mod_gzip verzichtet wird.

Profis finden in der Apache-Dokumentation weitere Informationen zu mod_deflate.


Caching

Selbst wenn die Inhalte komprimiert übertragen werden, so werden sie zunächst doch jedes Mal übertragen und erzeugen damit unnötigen Datenverkehr sowohl auf Server- als auch auf Browserseite. Abhilfe schafft hier das Caching bereits übertragener Daten.

Zum Einsatz kommt dafür auf Apache-Webservern das Modul mod_expires. Hiermit lässt sich der Expires-Header eines Dokuments oder einer Datei setzen, was dazu führt, dass der Browser diese Datei, sofern zwischengespeichert, erst nach dem angegebenen Datum erneut vom Server herunterlädt.

Wenn folgender Code in die .htaccess-Datei eingefügt wird, dann werden die Dateien, basierend auf ihren Dateitypen, für die spezifizierte Zeit lokal zwischengespeichert.

# Expires-Header fuer Dateien setzen
# http://www.flomei.de/wordpress-schneller-machen-inhalte-komprimiert-uebertragen-und-cachen-lassen/
<IfModule mod_expires.c>
   ExpiresActive On
   ExpiresDefault "access plus 1 month 1 days"
   ExpiresByType text/html "access plus 1 month 1 days"
   ExpiresByType image/gif "access plus 1 month 1 days"
   ExpiresByType image/jpeg "access plus 1 month 1 days"
   ExpiresByType image/png "access plus 1 month 1 days"
   ExpiresByType text/css "access plus 1 month 1 days"
   ExpiresByType text/javascript "access plus 1 month 1 week"
   ExpiresByType application/x-javascript "access plus 1 month 1 days"
   ExpiresByType text/xml "access plus 1 seconds"
</IfModule>

Ändern sich die Daten selten, könnten die Zeiträume noch länger definiert werden, allerdings werfen die Browser zu alte Daten automatisch weg, beziehungsweise entfernen die ältesten Daten sobald der lokale Cache eine definierte Größe erreicht hat. Den Caching-Zeitraum auf mehrere Jahre zu setzen, bringt also keine Besserung.

Auch hier finden Profis in der Apache-Dokumentation weitere Informationen.


Fonts komprimieren und cachen lassen

Mit der fast flächendeckenden Verbreitung und Nutzung von Webfonts sollte der Wunsch bestehen, auch diese komprimiert ausliefern und zwischenspeichern zu lassen. Zusätzlich zu den beiden oben gezeigten Codeblöcken, sollte deshalb auch der folgende Abschnitt in die .htaccess-Datei eingefügt werden:

# Fonts komprimieren und cachen lassen
# http://www.flomei.de/wordpress-schneller-machen-inhalte-komprimiert-uebertragen-und-cachen-lassen/
AddType application/vnd.ms-fontobject .eot
AddType application/x-font-ttf .ttf
AddType application/x-font-opentype .otf
AddType application/x-font-woff .woff
AddType image/svg+xml .svg

<IfModule mod_deflate.c>
   AddOutputFilterByType DEFLATE vnd.ms-fontobject 
   AddOutputFilterByType DEFLATE application/x-font-ttf 
   AddOutputFilterByType DEFLATE application/x-font-opentype 
   AddOutputFilterByType DEFLATE application/x-font-woff
   AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

<IfModule mod_expires.c>
   ExpiresActive on
   ExpiresByType application/vnd.ms-fontobject "access plus 1 year"
   ExpiresByType application/x-font-ttf "access plus 1 year"
   ExpiresByType application/x-font-opentype "access plus 1 year"
   ExpiresByType application/x-font-woff "access plus 1 year"
   ExpiresByType image/svg+xml "access plus 1 year"
</IfModule>

Hier werden zunächst mittels AddType die MIME-Types für Fontdateien definiert. Diese Information benötigt Apache, um eine Verbindung zwischen der Dateiendung und dem Inhalt herstellen zu können. Anschließend werden mittels des mod_deflate-Moduls die Fontdateien komprimiert übertragen und mittels mod_expire theoretisch bis zu ein Jahr lokal zwischengespeichert.

Dieser Eintrag hat natürlich nur dann Wirkung, wenn die Fontdateien vom selben Server wie die .htaccess-Datei ausgeliefert werden. Wer einen externen Anbieter wie Google Fonts oder etwas ähnliches nutzt, der muss darauf hoffen, dass auf deren Server entsprechende Einträge zur komprimierten Übertragung und zum Caching gesetzt sind.


nginx

So wie der Apache Webserver bietet auch nginx Möglichkeiten, die erzeugten Daten komprimiert ausliefern zu lassen. Hier kommt, wie beim Apache auch, gzip-basierte Kompression zum Einsatz.

Anders als beim Apache gibt es unter nginx keine .htaccess-Datei. Deshalb müssen die Anweisungen zur komprimierten Übertragung direkt in der Konfigurationsdatei des nginx hinterlegt werden. Der folgende kurze Code aktiviert die gzip-Kompression:

# gzip-Kompression unter nginx aktivieren
# http://www.flomei.de/wordpress-schneller-machen-inhalte-komprimiert-uebertragen-und-cachen-lassen/
gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Um die Effektivität dieser kleinen Helferlein zu testen, habe ich die Startseite von flomei.de in die drei oben verlinkten Werkzeuge geworfen und mir die Messergebnisse anzeigen lassen.

Vorher
Google Page Speed Insights: Mobil 72/100, Desktop 85/100
GTmetrix: Pagespeed Score A (91%), YSlow Score C (78%), Seitenladezeit 3,2 Sekunden für 519 kB
Pingdom Tools: Performance C (77)

Alle drei Tools merken an, dass man doch die Daten komprimiert übertragen und das Browser-Caching nutzen solle. Das habe ich jetzt mit dem Code von oben integriert und teste erneut…

Nachher
Google Page Speed Insights: Mobil 73/100, Desktop 88/100
GTmetrix: Pagespeed Score A (99%), YSlow Score B (80%), Seitenladezeit 2,4 Sekunden für 483 kB
Pingdom Tools: Performance C (76)

Während Google nur 1 bzw. 3 Punkte Verbesserung feststellt und Pingdom sogar schlechter ist als vorher (warum auch immer), macht GTmetrix den Unterschied schön deutlich. 36 kB weniger Daten und ganze 0,8 Sekunden schneller. Das ist die Richtung in die wir gehen wollen. Jetzt ist die Startseite des Blogs hier relativ übersichtlich, aus Erfahrung weiß ich, dass man da teilweise mehrere 100 kB sparen und die Ladezeiten um einige Sekunden verbessern kann.

Auch wenn das Internet (auch mobil) immer schneller wird, sollten wir Wert darauf legen, schnelle, schlanke Seiten auszuliefern. Das hier ist ein guter erster Schritt.

Florian Meier

Florian Meier

Florian Meier ist ausgebildeter Mediengestalter und hat sich selbst digitale Fotografie und Webentwicklung beigebracht. Er hat Druck- und Medientechnik studiert und ist wohl das, was man Digital Native nennt. Sein Geld verdient er mit Medien, aktuell als E-Business Print Manager bei der Longo Deutschland GmbH in Augsburg. In diesem Blog schreibt er über private Basteleien und Meinungen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.