Mehr Performance für WordPress

Durch Zufall bin ich auf diesen Blog-Beitrag aufmerksam geworden, und habe ihn mit Interesse gelesen. Ich weiß immer noch nicht, ob ich ihn gut finde oder nicht!

Punkt 1 und 2 (WordPress und Plugins immer auf dem aktuellen Stand halten), halte ich für eine Selbstverständlichkeit, und dies nicht aus Gründen der Performance. Um genau zu sein denke ich nicht, das WordPress schneller wird, wenn ich eine aktuelle Programm-Version einsetze. Wenn es danach geht müsste ich eine Steinalt-Version von WordPress einsetzen – ohne Plugins. Was diese Punkte allerdings so wichtig macht ist schlicht und ergreifend die Sicherheit des Blogs! Also, immer schön updaten – aber bitte nicht aus Performance-Gründen.

Der dritte Punkt (Optimierung der Datenbankabfragen) dürfte den Durchschnitts-Wordpress-Benutzer überfordern! Außerdem kann ich durchaus davon abraten, direkt die Datenbank zu ändern. Der Schuss geht meistens nach hinten los, und es gibt durchaus effektivere Maßnahmen zur Steigerung der Response-Zeiten.

Punkt 4 ist auch Quatsch! Ich habe derweil eine ganz eigene Meinung über Leute, die phpMyAdmin als festes Werkzeug zum Editieren von Datenbanken verwenden, aber das ist grad ein anderes Thema. Eigentlich sind WordPress-Tabellen durchaus optimiert, da man meistens einen schreibenden Zugriff auf die Datenbank hat, und selten einen Löschenden. Die Chance das eine WordPress-Tabelle optimiert werden muss, tritt wohl nur bei alten oder großen Blogs mit vielen Kommentaren auf.

Der 5. Punkt reduziert durchaus die Last auf dem Server, nicht aber der Performance des Blogs. Ein Bild bleibt ein Bild, ob ich das vom Server direkt oder von irgendwo laden muss, dürfte beim Leser Unterschiede im Milli-Sekunden-Bereich ausmachen. Hinzu kommen (und das wird vollkommen vernachlässigt) zusätzliche DNS-Auflösungen. Man sollte schwer aufpassen das man den Zeitgewinn dadurch nicht direkt wieder verliert.

Punkt 6. ist auch recht nebulös. Eigentlich gehe ich davon aus das man Bilder optimiert wenn man sie einstellt, und nicht irgendwann mal. Ich bin mir sicher, dass niemand auf die Idee kommt 8-Megapixel-Bilder vom letzten Urlaub direkt online zu stellen.

Punkt 7 ist der erste vernünftige Punkt auf der Liste: das WP Super Cache Plugin. Dieses läuft auch hier auf dem Blog und leistet gute Arbeit. Allerdings sollte man das Teil mit Vorsicht genießen. Der Schluss das man einen vernünftigen Cache hat, ist verkehrt! Vernünftig funktioniert der Cache nur dann, wenn es entsprechende Zugriffszahlen gibt. Die Haltezeit einer Seite (10 Minuten) ist für die meisten Blogs viel zu kurz! Hier gilt es also erstmal, die Cache-Zeiten zu ändern, bevor das Plugin Nutzen bringt. Ansonsten ist es sehr zu Empfehlen. Allerdings besitzt es auch ein großes Manko: den Feed! Dieser wird nämlich vom Super Cache nicht zwischengespeichert und kann für erhebliche Last sorgen, falls man ihn nicht zu zum Beispiel Feedburner ausgelagert hat.

Punkt 8 gehört WP PHP Speedy. Naja – wen es glücklich macht ;) Auch hier stellt sich die Frage, ob die Performance die das Plugin bringt, nicht der Rechenleistung des Plugins im Wege steht. Prinzipiell macht das Plugin aus mehreren CSS-Dateien, und CSS-Anweisungen im Template selbst eine einzige Datei. Das gleiche macht es mit den Javascript-Dateien. Das reduziert die Anzahl der http-Anfragen, und das Design kann schneller gerendert werden. Prinzipiell eine super Idee. Kann ich aber auch per Hand machen – dann bringt es noch mehr Performance.

Punkt 9 gehört WP CSS, und da wäre ich erst einmal sehr sehr vorsichtig ob sich dieses Plugin nicht mit WP Speedy ins Gehege kommt! Zumindest dieses Plugin halte ich für im höchsten Maße überflüssig. Dann lieber WP PHP Speedy!

Bei Punkt 10 wird es wieder interessanter, da kommt DB Cache ins Spiel. Dieses cached Datenbankabfragen, und genau hier fangen dann die Probleme schon wieder an! Man muss sich nämlich genau überlegen, ob man dieses Plugin überhaupt braucht, oder ob WP Super Cache reicht. Habe ich letzteres nämlich installiert, habe ich im günstigsten Fall keine Datenbankabfragen zu Cachen! Habe ich allerdings einen stark frequentierten RSS-Feed, kann das Plugin durchaus Sinn machen!

Punkt 11 wiederum ist ganz lustig, aber ebenso unsinnig. Hier gilt das gleiche wie beim externen Lagern der Bilder. Ganz nett wenn man Traffic sparen will, aber schneller kommt es deswegen trotzdem nicht zum Leser!

Dazu gesellt sich dann Punkt 12: herzlichen Glückwunsch! Wenn ich Anzeigen lasse, wie langsam meine Seite ist, wird sie dadurch nicht unbedingt schneller :) Das ganze ist ganz gut um Vergleichstests zu machen, und die Wirkung der Plugins zu überprüfen, aber das wars auch schon. Total unnütz!

Optimize DB ist Punkt 12, und ein Plugin, das die Datenbank aufräumt. Eigentlich macht es somit nichts anderes, als einen „OPTIMIZE TABLE“. Es macht also automatisch, was man bei Punkt 4 händisch erledigen soll.

Alles in allem viel unnützes Zeug in  diesem Blog-Beitrag. Durchaus sinnvoll wenn man ein WordPress-Blog unter Hochlast betreibt, aber für den Durchschnitts-Blog wohl vollkommen uninteressant. Der größte Performance-Booster fürs Backoffice fehlt übrigens ganz: Google Gears!

Ähnliche Beiträge

Update auf WordPress 2.8.1 Für alle die es noch nicht mitbekommen haben, WordPress 2.8.1 ist da. Nachdem die Blogs noch alle auf der 2.7.1 liefen, habe ich heute auch mal die Ak...
Webworking nun auch Mobil Nachdem Caschy in seinem Blog über mangelnde Einbindung von mobilen Themes in diversesten Blogs berichtet hat, ist mir eingefallen, dass da ja was war...
Gastbeitrag bei T3N: Caching in WordPress Zugegebenermaßen ist der Titel "Jenseits des Optimierungs-Wahns – Wie man WordPress wirklich schneller macht" etwas reißerisch, zumal die vorgeschlage...
WordPress Gewinnspiel TemplateMonster Die Webentwicklung hat sich in den letzten Jahren stark gewandelt, früher waren fast alle Launches hundertprozentig individualisierte Lösungen. Mit zu...

Eine Antwort auf „Mehr Performance für WordPress“

  1. Naja, der Flaschenhals ist nicht das Backend (zumindest nicht solange Du keinen Dienst wie wordpress.com betreibst) sondern das Frontend. Jede Sekunde die du im Frontend einsparst multipliziert sich mit der Anzahl Deiner Besucher. Im Backend turnt man alleine oder mit ein paar Autoren rum. Ob da der Seitenaufbau 1,10 oder 30s dauert ist letztenendes irrelevant.

Schreibe einen Kommentar

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