Performance Tuning für Wordpress – der ultimative Guide zum WP-Tuning für Google PageSpeed und YSlow

Performance Tuning für WordPress – der ultimative Guide zum WP-Tuning für Google PageSpeed und YSlow

// September 27th, 2010 // Blog / Website, IT

Augenblicklich geistert das Thema WordPress-Tuning durch das Netz und meinen Feedreader. Da ich mit meinem Page Speed Score und mit dem von YSlow erst recht nicht zufrieden war, habe ich mich mal daran gemacht, beide und natürlich auch mein WordPress zu tunen. Hier der Artikel, welche Änderungen ich hierfür vorgenommen habe.

WP Minify (Combine external CSS / Javascript - Minify CSS / Javascript)

Nahezu jedes Plugin, welches Einfluss auf das Frontend von WordPress hat, nutzt Javascript oder zumindest CSS (Cascading Style Sheets). Oft werden außerdem von externen Diensten wie z.B. Google AdSense, Facebook, Flattr, etc. weitere JS benötigt. Werden diese Dateien nicht zusammengefasst, sind dies schnell 10-15 Files, die extra geladen werden müssen. Meistens sind es aber noch nicht mal die Dateien selbst, welche die Performance herunterziehen. So muss müssen für die externen Dateien z.B. zusätzliche DNS-Anfragen gesendet werden oder die Dauer des Caching ist zu gering konfiguriert. Abhilfe bietet hier WP Minify. Zwar bietet auch W3 Total Cache eine Minify-Funktion an, jedoch war ich mit dieser nicht ganz zufrieden. Das Problem bestand bei W3TC darin, dass Scripts, welche nach dem Schema "jquery.js?ver=1.4.2" aufgebaut sind, weder zusammengefasst noch minified werden. Da dies bei einem Großteil der Dateien der Fall ist, kam die Option innerhalb von W3TC für mich nicht in Frage.

Eine, in meinen Augen, bessere Alternative ist hier WP Minify. Die Minification funktioniert zuverlässiger und das Plugin bietet die Möglichkeiten auch externe Scripte und Style Sheets mit einzubeziehen oder Ausnahmen zu konfigurieren, welches bei einigen externen Diensten leider notwendig ist.

Nach der Installation von WP Minify kann man grundsätzlich die Standardeinstellungen nutzen. Lediglich die Cache Expiry Zeit würde ich nach oben setzen. Sollte ein weiteres Plugin installiert werden oder sich etwas an den Stylesheets oder den Javascripts ändern, kann man über einen Button den Cache manuell leeren, um so die Änderungen zu übernehmen. Die Optionen "Enable Minification on External Files" sollte deaktiviert bleiben, da man sonst Tage und Wochen damit verbringt, Ausnahmen zu konfigurieren. Ob man die Einstellung "Place Minified JavaScript in footer" nutzt, ist meist vom verwendeten WordPress-Theme abhängig. Da bei mir die Darstellung der Seiten im Header über jquery realisiert ist, käme es zu Problemen bei der Darstellung, würden die zugehörigen js-Dateien erst am Ende der Seite geladen.

Das Hinzufügen von externen CSS-Dateien wie z.B. http://api.flattr.com/button/default.css stellt meist kein Problem dar, da diese nicht dynamisch und daher sehr 'pflegeleicht' sind.

W3 Total Cache

Das ultimative Plugin zum Tunen von WordPress in Bezug auf Geschwindigkeit, Google PageSpeed und Yahoo YSlow ist W3 Total Cache. Nahezu alle der von Google und Yahoo geforderten Voraussetzungen für eine gute Bewertung, können mit diesem Plugin konfiguriert und erfüllt werden. Da die meisten Einstellungen bereits in anderen Blogs nahezu vollständig beschrieben wurden, gehe ich jetzt nur auf die Anpassungen ein, die ich, abseits von der Standardkonfiguration vorgenommen habe und die über W3TC hinaus gehen.

Caching

Vor der Installation des Plugins, habe ich auf meinem Server den "Alternative PHP Cache" kurch APC installiert, welcher eine bessere Caching-Performance bietet, jedoch nur auf vServern oder Rootservern installiert werden kann. Wer ein Webhosting-Paket nutzt, sollte wenn möglich auf "Disk" zurückgreifen (enhanced wenn möglich).

Minification

Trotz des installierten Plugins WP Minify sollte auch in W3TC Minify aktiviert werden, da W3TC im Gegensatz zu WP Minify auch HTML Minification unterstützt. HTML Minify sollte hier aktiviert werden, bei JS und CSS sollte dies jedoch aus o.g. Gründen deaktiviert werden. Wichtig ist, dass der automatische Upload für das CDN aktiviert ist, um die vollen Vorteile genießen zu können. Dies gilt natürlich nur, wenn auch ein CDN konfiguriert ist. Dazu aber weiter unten mehr.

Browser Cache Settings

Hier habe ich unter "General" alle Optionen bis auf "Set entity tag (eTag)" aktiviert (mit dieser Funktion teste ich aktuell noch). Besonders wichtig ist die Funktion "Enable HTTP (gzip) compression". Damit werden die HTTP-Daten über das gzip-Format komprimiert, was zu einer Beschleunigung der Ladevorgangs führt und besonders PageSpeed und YSlow freut. Wichtig ist, dass diese Option sowohl unter General, CSS + JS, HTML und sonstiges aktiviert wird.

Als Werte für die Dauer bis zur Erneuerung (Expires header lifetime) habe ich bei CSS & JS 432000 Sekunden (5 Tage), bei HTML 3600 Sekunden (1 Stunde) und bei Media & anderen Dateien 31536000 Sekunden (1 Jahr) angegeben. Letzteres wirkt zwar sehr hoch, aber Videos, Bilder, MP3s, etc. ändern sich normalerweise nicht, so dass dieser Wert vollkommen in Ordnung ist.

Content Delivery Network (CDN)

Aufgrund dessen, dass 'richtige' CDN-Anbieter aus Kostenpunkten für mich nicht in Frage kamen und wohl das Einrichten eines eigenen CDN für die meisten interessant ist, gehe auch auch nur hierauf ein. Auch wenn die Möglichkeit besteht, eine eigene Domain für das CDN zu registrieren, habe ich mich für die Lösung per Subdomain entschieden. Problem ist hierbei jedoch, dass bei der Verwendung von Cookies (die bei den meisten Blogs zumindest von WP selbst und Google Analytics gesetzt werden), diese auch für Subdomains gelten. Hier komme ich aber weiter unten nochmal zu sprechen.

Ich habe mir via Plesk eine Subdomain (static1.feldstudie.net) mit eigenen FTP-Zugangsdaten erstellt. Diese habe ich dann in den CDN-Einstellungen von W3 Total Cache angegeben. Da sich die Subdomain auf dem gleichen Server wie die Hauptdomain befindet, kann als "FTP hostname" localhost eingetragen werden.

Beim "FTP path" wird das absolute Verzeichnis angegeben, in welchem sich die Dateien später auf dem Server befinden sollen. Da der FTP-Account das Verzeichnis der Subdomain als 'Home-Verzeichnis' hat, muss nicht der komplette Pfad angegeben, der z.B. für root erforderlich wäre (/srv/www/vhosts/...). Ich habe bewusst ein Unterverzeichnis (wordpress-cache) gewählt, da die Subdomain auch für andere Dateien (z.B. ga.js) genutzt werden soll und so die Übersichtlichkeit gewahrt bleibt.

Unter "Replace site's hostname with" wird nun die URL angegeben, unter welcher die Dateien auf dem Content Delivery Network von außen erreichbar sind. W3TC biegt nun die eigentlichen Links zu Bildern, etc. auf die hier angegebene Adresse um. Hier gibt es die Möglichkeit, mehrere URLs anzugeben. Dies dient dazu, die Zugriffe auf CSS, Javascript (<head>, <body>, before </body>) und sonstige Medien auf eigene Subdomains zu legen. Der Sinn eines CDN ist ja, die Zugriffe auf Dateien und Medien über verschiedene Hostnamen zu parallelisieren. Dies funktioniert ähnlich wie bei einem Raid 0 bei Festplatten. Während die Datei 1 auf Hostname 1 noch geladen wird, kann der Browser bereits das Laden von Datei 2 auf Hostname 2 starten. Wird kein CDN genutzt, müsste der Browser mit dem Laden von Datei 2 warten, bis die Datei 1 fertig geladen ist. Das Problem bei aufwendigen Themes ist, dass trotz der Minification von JS und CSS, viele Bilder, CSS und JS geladen werden müssen. Wenn nun alle diesen Dateien von einem einzigen zusätzlichen Hostname geladen werden, haben wir nicht viel gewonnen und PageSpeed und YSlow bemängeln weiterhin "Parallelize downloads across hostnames". Aus diesem Grund habe ich insgesamt sechs Subdomains (static1 - static6.feldstudie.net) angegeben.

Da nur ein einziger FTP-Account angegeben werden kann und die meisten vServer- bzw. Webhosting-Anbieter standardmäßig einen Catchall-Eintrag im DNS konfigurieren, ist es nicht zwangsläufig nötig weitere Subdomains oder DNS-Einträge zu konfigurieren. Einfacher ist es, in der vhost.conf im conf-Verzeichnis der Subdomain folgende Einträge zu konfigurieren:

ServerAlias static2.feldstudie.net
ServerAlias static3.feldstudie.net
ServerAlias static4.feldstudie.net
ServerAlias static5.feldstudie.net
ServerAlias static6.feldstudie.net

Hiermit werden alle Anfragen auf z.B. static5.feldstudie.net von Apache auf static1.feldstudie.net umgeleitet. Konfiguriert man in W3TC mehr als vier Hostnames, werden alle Einträge ab dem Fünften für die Dateien und Medien verwendet, die kein CSS und JavaScript sind. In meinem Fall werden die nicht CSS- und JS-Dateien ca. zur Hälfte jeweils über static5 und static6 aufgerufen.

Wichtig ist, dass die Option "Enable changed files auto-upload" aktiviert ist. Dabei werden geänderte oder neu hinzugefügte Dateien in dem festgelegten Intervall per FTP auf die, in den CDN-Optionen konfigurierte, Subdomain kopiert. Standardmäßig geschieht dies nur für Dateien, die unter dem Punkt "General" angegeben wurden. Sollen zusätzliche Dateien kopiert werden, können diese unter "Custom file list" angegeben werden. Ausnahmen werden unter "Rejected files" angegeben. Besonders interessant ist die letzte Funktion für Bilder, die dynamisch generiert werden (z.B. Captchas). Nach der Konfiguration sollte der Upload der angegebenen Medien manuell angestoßen werden.

Weitere Informationen zum Thema CDN und WordPress findet Ihr hier: (Majeres, Bueltge,

Sonstige empfehlenswerte Einstellungen

Leverage Browser Caching

Google PageSpeed und Yahoo YSlow setzen sehr hohe Cacheing-Zeiten voraus. Daher habe ich gerade für die CDN-Subdomain eine .htaccess angelegt und als Grundlage hierfür die .htaccess genutzt, die W3TC im httpdocs-Verzeichnis meiner Hauptdomain angelegt hat. Diese Datei könnt Ihr am Ende dieses Artikel herunterladen.

Optimize images

Die im Blog verwendeten Bilder sollten natürlich möglichst klein sein. Hier empfiehlen sich die Formate jpg und png. Letzteres ist gerade für Grafiken mit transparenten Elementen / Hintergründen interessant, da jpg dies nicht unterstützt. Zusätzlich nutze ich das WordPress-Plugin "WP Smush.it", welches Bilder in Artikeln beim Veröffentlich über den Dienst Smush.it in der Größe optimiert und so oft noch einige Kilobytes spart.

Specify image dimensions / Serve scaled images

Wichtig ist auch, dass bei Bildern grundsätzlich die Dimensionen angegeben werden. Bei Bildern in Artikeln geschieht dies meist automatisch, jedoch sollte man bei in das Theme eingebundenen Dateien grundsätzlich darauf achten, dass dies auch wirklich der Fall ist. Gerade bei selbst eingebundenen <img>-Tags wird dies häufig vergessen oder einfach vernachlässigt. Da ich doch häufiger Emoticons in meinen Beiträgen verwende ist mir aufgefallen, dass bei der Umwandlung in Grafiken hier keine Dimensionen angegeben sind. Dies wird gerade bei PageSpeed rigoros mittels Abzug von Punkten bestraft. Hier hilft es in der, für das Theme zuständigen, CSS-Datei (bei mir style.css) einen neuen Eintrag hinzuzufügen:

img.wp-smiley {
width: 15px;
height: 15px;
}

Serve static content from a cookieless domain

Das wohl interessanteste Thema ist das Bereitstellen von statischen Inhalten auf einer cookielosen Domain. Gönnt man sich den Luxus einer dedizierten Domain oder eines echten CDN-Anbieters, erledigt sich dieser Punkt meist von selbst. Nutzt man jedoch eine Subdomain, steht man vor dem Problem, dass die Cookies der Hauptdomain auf die Subdomain vererbt werden. In meinem Fall traf das auf die von WordPress und Google Analytics gesetzten Kekse zu. Doch auch hier kann man recht simpel Abhilfe schaffen:

In der wp-config.php von WordPress ergänzt man einfach den bereits bestehenden Inhalt um die Zeile "define('COOKIE_DOMAIN', 'www.feldstudie.net');" Damit gelten die Cookies nur noch für die hier angegebene Domain. Da ich eine Weiterleitung für "nicht-www-Aufrufe" zu www.feldstudie.net konfiguriert habe, ist dies für mich vollkommen ausreichend.

Bei Google Analytics muss lediglich die Zeile "pageTracker._setDomainName("www.feldstudie.net");" hinzugefügt werden. Dies sollte vor der Zeile "pageTracker._initData();" geschehen, da sonst weiterhin ein paar der Cookies von GA auf die Subdomain vererbt werden. Hier der entsprechende Auszug aus meinem Google Analytics Code:

<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-xxxxxxx-1");
pageTracker._setDomainName("www.feldstudie.net");
pageTracker._initData();
pageTracker._trackPageview();
</script>

Weitere Informationen zu cookieless Domains gibt's auf "im-Tal.net"

Fazit

Mit wenigen Eingriffen kann man WordPress so konfigurieren, dass auch Google PageSpeed und Yahoo YSlow zufrieden sind. Schwierig wird es erst, wenn man viele externe Dienste wie Flickr, Flattr, YouTube, u.a. einbindet. Auf die hier benötigten Dateien, Cache-Zeiten, etc. hat man leider wenig Einfluss. Aus diesem Grund habe ich mich auch auf die Startseite konzentriert und die Artikelseiten etwas vernachlässigt. Weiterhin habe ich mich wenig um das PageSpeed-Kriterium "Use efficient CSS selectors" gekümmert, da imho WordPress mit den ganzen Plugins (33 aktiv) in Bezug auf CSS für meine Kenntnisse zu komplex ist und ich nichts verschlimmbessern wollte. Ich denke, ich kann aber mit einem PageSpeed Rating von 97/100 und einem "Grade A" (Performance Score 98) für eine Hobby-Website zufrieden sein.

Solltet Ihr weitere Fragen oder Probleme bei dem Tuning Eures WordPress Blogs haben, könnt Ihr diese gerne in den Kommentaren hinterlassen. Ich versuche Euch dann mit meinem beschränkten Wissen zu helfen.
Da mich das Tuning selbst und erst recht dieser Artikel sehr viel Zeit gekostet hat, würde ich mich über Verlinkung / Trackbacks, Kommentare, Votings bei Yigg, Wikio, etc. wirklich sehr freuen.

Weitere Interessante Artikel zu diesem Thema auf anderen Blogs (die nicht schon im Text verlinkt wurden):

CDN-htaccess (5.9 KiB, 638 hits)

Feldstudie.net