Mich hat schon seit längerem gestört, dass Domspitzen für den Seitenaufbau merklich zu lange braucht. 5-7 Sekunden sind selbst bei einem preiswerteren VServer nicht zeitgemäß. Also habe ich mal wieder ein wenig rumgebastelt. Hier meine Erkenntnisse:
1. Twitter Tools abschalten
Ein wirklich nettes Plugin: Man kann seine aktuellen Twitter-Posts in einem Sidebar-Widget anzeigen lassen. Außerdem wird jeder neue Beitrag automatisch in die Welt hinaus gezwitschert. Ich habe das Plugin aktiviert und deaktiviert, zwischendrin die Ladezeiten gemessen. Der Unterschied ist beachtlich, deshalb will ich das Plugin hier auch separat nennen. Das soll übrigens keine generelle Kritik an TwitterTools sein, aber der Unterschied zwischen den Ladezeiten mit und ohne Plugin sind bei mir so signifikant, dass ich das nicht unerwähnt lassen möchte (weiter unten mehr zu Plugins) Performanceverlust/ -gewinn: ~2 Sekunden
2. WordPress Datenbank entschlacken
Hinter dem Domspitzen-VServer werkelt eine MySQL-Datenbank. Die ist mittlerweile auf stolze 18 MB angeschwollen. Das wäre je nach Applikation, die sie verwendet, gar nicht so viel aber es werden hier ja fast nur WordPress-Artikeltexte abgelegt. Fränk meint, das läge an der Versionierung von WordPress, die für jede Änderung eine neue Instanz in die DB haut. Und bei den vielen Typos, die ich immer korrigieren muss, können schon mal 18 MB zusammen kommen.
Um das Problem zu lösen, habe ich zunächst mit einer lokalen Installation von WordPress rumgespielt (klickst du Xampp, aktuelles WP). Das ist übrigens wirklich einfach unter XP zu bewerkstelligen, man muss nur daran denken, zuerst mit MyPhpAdmin eine entprechende DB anzulegen und dann richtig in wp-config.php zu hinterlegen. Als nächstes habe ich mein Theme vom Live-Server geholt (/wp-content/themes/XXX). Im WP Adminbereich findet sich bei Werkzeuge > Daten exportieren. Damit erzeugt man sich einen Vollexport aller Artikel und Seiten (inklusive Autoren). Das entstandene XML-File kann man nun über Werkzeuge > Daten importieren > WordPress in die neue / lokale Instanz reinpacken. Und siehe da; die neue DB ist nun deutlich kleiner geworden (bei DS sind es 1.4 MB von den ehem. 18 MB). Nun hat man beinahe eine 1:1 Kopie der Live-Instanz auf dem heimischen Gerät. Man wird feststellen, dass die meisten Artikel- und Seiten-IDs stimmen aber eben nicht alle. Nun wäre es ziemlich stressig, alle Artikel zu prüfen, ob die IDs noch stimmen und man sich nicht aus Versehen den sorgsam gepflegten Google-Index versaut. Deshalb ist es ratsam, die Permalinks entsprechend von Page-IDs auf ein anderes Format umzustellen. Ich habe mich für den Artikel-Titel entschieden (Einstellungen > Permalinks, dort “Benutzerdefinierte Struktur” und als Wert /%postname% ) Nun sollten alle Artikel-Links in der lokalen und produktiven Instanz übereinstimmen. Da ich die Permalinks gerade erst umgestellt hatte, habe ich nun erst einmal eine neue XML-Sitemap (z.B. mit einem Plugin) gebaut, zu Google geschickt und eine Nacht darüber geschlafen.
Um nun eine echte Performance-Messung durchzuführen, muss die zu testende WP-Instanz allerdings auf dem Web-Server laufen. Also – vorausgesetzt, der Provider erlaubt mehr als 1 DB anzulegen – tut man zunächst selbiges und legt eine neue Datenbank an. In ein Unterverzeichnis auf dem Server kopiert man sich nun die WordPress-Dateien der lokalen Instanz und passt wieder die wp-config.php entsprechend der neuen Datenbank-Konfiguration an. Das Verzeichnis kann man gern mit einem Passwort schützen bzw. der robots.txt sagen, dass die Such-Bots draußen bleiben müssen. Damit vermeidet man unschöne Indexierungen der Testinstanz.
Das bereits exportierte XML-File kann man nun auch in die neue, lokale Instanz importieren und ausgiebig testen. Performancegewinn: ~2 Sekunden
3. Plugins einzeln prüfen
Mit Hilfe der nun erstellten Testinstanz lässt sich sehr schön der Performance-Einfluss einzelner Plugins messen. Performancelastige Plugins lassen sich so identifizieren und ggf. abschalten oder ersetzen. Man kopiert dazu erst einmal den Inhalt von /wp-contents/plugins von der Live- in die Testinstanz (kleiner Tipp: Filezilla kann das direkt auf dem FTP, ohne die Daten vorher lokal abzulegen!) Im WP-Adminbereich unter Plugins kann man nun nach und nach die einzelnen Plugins aktivieren und die Performance prüfen (z.B. mit dem Firefox Addon ExtendedStatusBar). Um die Aussagekraft der Ergebnisse zu steigern, sollte man danach ruhig auch mal alle Plugins wie auf dem Livesystem aktivieren und dann nach und nach einzelne abschalten. Es kann ja sein, dass sich Plugins auch gegenseitig beeinflussen.
Mit dieser Vorgehensweise habe ich nun alle Plugins durchgeprüft. Wie bereits oben beschrieben, hat Twittertools erstaunliche 2 Sekunden Unterschied gemacht. Weit weniger schlimm als befürchtet benehmen sich die Google SiteMaps (~0.2 Sek aber so groß ist bereits die Fluktiation zwischen mehreren Messungen) und das von mir hochgeschätzte NextGenGallery: 0.6 Sekunden (aber nur, wenn ein Bild mit NextGenGallery im Artikel eingebunden ist!) und das ist bei dem ganzen JavaScript-Geraffel, was hier geladen wird, durchaus OK.
4. Auf die neue DB umschalten
Wenn man sich nun wirklich sicher ist, dass die Links auf die neue DB alle noch funktionieren, kann man den nächsten und auch letzten Schritt wagen und die neue DB in der wp-config.php der Live-Instanz eintragen. Dadurch kann man im Notfall auf die alte DB zurückschwenken und verliert nur diejenigen Inhalte, die man NACH dem Schwenk auf die neue DB erzeugt hat. An sich sollte nun aber alles laufen und auch ein ganzes Stück schneller, als mit der langsamen, alten Datenbank. Zur Kontrolle kann man sich mit Hilfe der Google-Anfrage
site:MEINEBLOGURL
alle indexierten Seiten ausgeben lassen und die Links mit einem entsprechenden Linkchecker prüfen.
Bei Domspitzen habe ich mit diesem Maßnahmenpaket gefühlte 4 Sekunden Ladezeit herausgeholt! Wem das noch nicht reicht, der sollte zur ultimativen Waffe greifen, die sich da WP-SuperCache nennt. Da hier mit sehr komplexen htaccess-Direktiven gearbeitet wird, sollte man hier unbedingt lokal und mit einer Live-Testinstanz testen, bevor man das ganze auf die Leserschaft loslässt. Und Backups machen! 
Tags: performance, plugins, wordpress