WordPress ist ein überaus nettes Blog-System.
Mit nur einem winzigen Nachteil: Es ist aufgebläht.

Damit der Spaß an der Freude auf lange Sicht nicht zu kurz kommt, wird man im Laufe der Zeit dies und das erweitern, ändern, schrauben – und das System mit Plugins erweitern. Somit haben wir einen sehr schönen, umfangreichen, individuellen – und langsamen Blog!

Wo setzt man an? Der neuste Trend lautet Cache! Zum Beispiel mittels Plugin – Stichwort: WP Super Cache
Man sollte aber nie vergessen: Die Eierlegende Wollmilchsau gibt es nur im Märchen. Und ein Plugin um die (Geschwindigkeits-) Nachteile anderer Plugins und Konfigurationen auszumerzen hat auch schon wieder einen schalen Beigeschmack.
Nichtsdestotrotz einen Blick wert – später!
Bevor man auf Plugins zurückgreift und versucht via Knofpdruck zu optimieren, kann man selbst auch einiges erreichen.

Ein guter Anfang für eine Analyse und Optimierung ist ein Online-Test wie Pingdom.
Neben der Gesamtladezeit der Seite bekommt man einen netten Einblick in das, was bei jedem Seitenaufruf geladen wird – und das kann schonmal erschreckend sein.
Spätestens jetzt wird klar, dass Plugin-Entwickler es lieben, eigenen CSS und JS in dem Header mit auszugeben.

Zeit für eine erste Analyse: Wofür brauche ich genau das Plugin?
Ein Beispiel von mir. Seit ewigen Zeiten habe ich den Download Monitor als Plugin verwendet. Überaus nett um Dateien zu verwalten und zum Download anzubieten, incl. Statistik. Auf ein stolzes Dutzend Downloads bin ich gekommen. Dafür ein extra CSS und JS bei jedem Seitenaufruf laden? Nein danke. Rausgeflogen.

Oft will man aber auf ein Plugin nicht verzichten, dass eigenes CSS oder JS lädt. Schonmal einen intensiveren Blick in die Optionen des Plugins geworfen? Einige (leider noch nicht viele) bieten die Möglichkeit an, Einstellungen zum CSS zu machen.
Zum Beispiel die NextGen Gallery, auf die ich ungern verzichten würde. Sie bring eine Menge CSS mit – aber mit einem Mausklick kann man das (separate) laden unterbinden und stattdessen den betreffenden Code in die styles.css des verwendeten Themes einbinden. Wieder ein Ladevorgang weniger – bei jedem Seitenaufruf.

Irgendwann sind diese Möglichkeiten – wenn man nicht einen gewaltigen Aufwand betreibt – erschöpft. Kommen wir also zu dem spannenden Thema Cache, in all seinen Varianten.

Über den PHP-Cache-Beschleuniger eAccelerator habe ich mich ja bereits in einem eigenen Artikel ausgelassen, dieser ist auf jeden Fall Pflicht – besonders für alles, was nachfolgend kommt.

Seit einiger Zeit hatte ich die Verknüpfung von eAccelerator mit dem WordPress Object-Cache hier im Einsatz, nach einer Anregung von Frank Bueltge – eAccelerator für WordPress. Die Ergebnisse können prinzipiell überzeugen, die einzelnen Datenbankabfragen gehen richtig in den Keller.
Leider ist der Code, bzw. die Code-Grundlage nicht mehr die neuste. Folglich gibt es einige Einschränkungen – bei mir im Backend funktionierte z.B. die Prüfung auf aktualisierte Plugins nicht mehr ordentlich. Die rote Zahl, die mit in der “Plugin-Navigation” immer ein Update ankündigte, blieb aus.

Eine weitere Version, die den WordPress-Cache mit eAccelerator verbindet, kann man ebenfalls probieren. Die Ausgangsbasis ist gleich, nur…

At the time of writing, the NeoSmart eAccelerator backend is old and doesn’t work nicely with the latest versions of WordPress. Specifically; it doesn’t implement the non-persistent groups. Caching these objects in a persistent fashion (longer than the current page view) results in some rather odd behaviour.

Einen Test ist dieser Object-Cache allemal wert.

Es gilt jedoch nicht immer: Cache = schneller
Darauf weisst auf der Coder selbst hin. Eine WordPress-Installation, die einen Server (natürlich mit eAccelerator) halbwegs für sich hat, die einen gut konfigurierten Mysql eigenen Query-Cache nutzt, wird in Verbindung mit dem Object-Cache ggf. langsamer im Seitenaufbau sein! Bei mir ist dies z.B. der Fall…
Die Anzahl der Queries auf die Datenbank geht stark zurück – dies schlägt sich aber nicht direkt in einem schnelleren Seitenaufbau wieder! Ausprobieren, testen, auswerten…

Optimierung ist individuell!

Wer jetzt noch nicht ganz den Pfaden und die Lust auf Optimierung via Cache verloren hat, dem empfehle ich noch ein weiteres Plugin. Basierend auf dem oben bereits genannten WP Super Cache Plugin:
WordPress Super Cache Plus

Die angelegten statischen html Seiten werden nicht mehr (wie beim Original) auf der Festplatte abgelegt, sondern es wird RAM genutzt.
Neben meinem Favoriten – eAccelerator – stehen APC, XCache, Zend-Cache und Memcached zur Verfügung.

Der Seitenaufbau ist mit dieser Lösung wirklich brutal schnell. Aber auch hier die Schattenseite: Will man wirklich statische Seiten ausliefern?
Für mich lautet die Antwort nein, aufgrund der Inkompatibilität von statisch gecachten Seiten mit meinem Landingsites-Plugin für SuMa-Besucher.
Diese begrüße ich lieber individuell, als schnell.

Ich wiederhole mich, Optimierung ist individuell. Jeder muss für sich abwegen, wo die Prioritäten gesetzt werden. Die Möglichkeiten sind in jedem Fall (fast) unendlich.
Die o.g. Möglichkeiten setzten natürlich woraus, dass man ein gewisses Grundwissen über Server, php, sql… hat. Oder eine gewisse Abenteuerlust :-)

Zu guter letzt noch ein Tip:
Für alle, denen Super Cache zu langweilig ist, Super Cache Plus zu gewagt…
W3 Total Cache ist auch noch einen Blick wert. Das tue ich nun in den kommenden Tagen – und werde sicherlich berichten… ;-)

Update: Ich sehe gerade, hombertho hat heute etwas zu W3 Total Cache geschrieben!