Test WP-Optimize Plugin für WordPress

Posted on 09. Jun, 2010 by in Multimedia

Gestern hatte ich mal wieder einen Tag an dem ich mehr Zeit hatte. Deshalb konnte ich mir mal wieder meine ToDo-Liste vornehmen. Ganz oben stand der Test des Plugins WP-Optimize für WordPress. Auf das Plugin wurde ich aufmerksam durch den Artikel WP-Optimize Plugin auf Elementarwissen.de.

Innerhalb dieses Artikels wird beschrieben was WP-Optimize macht und ob es was nützt. Unterstützt wird das Ganze durch einen kleinen Feldtest an einem WordPress-Projekt. Das Ganze wird ausgewertet und eine Alternative für eine Teilaufgabe von WP-Optimize wird vorgestellt.

WP-Optimize bereinigt die Datenbank von Datenmüll. Als Beispiel dafür gilt die Zwischenspeicherung der einzelnen Beiträge und Artikel. WordPress legt jedes Mal einen neuen Datenbankeintrag an, anstatt den alten Eintrag zu überschreiben. Braucht man keine ältere Version von Beiträgen ist das Plugin ganz nett :-) . Nebenher gibt es noch weitere Funktionen.

Die Funktionen

  • Löschen der Zwischenspeicherung von Beiträgen
  • Entfernung von als Spam markierte Kommentare / nicht genehmigte Kommentare
  • Optimierung der Tabellen in der Datenbank

Die Annahme

Wie es bei dynamischen Websites üblich ist, wird auch bei WordPress die angeforderte Seite erst durch Datenbankabfrage erzeugt. Demnach gehe ich davon aus, dass die Datenbankgröße und deren Aufbau ein Einflussfaktor auf die Ladezeit der Website hat. Gerade jetzt, wo der Google Ranking-Faktor Ladezeit immer mehr in der Diskussion ist, interessiert es sicher immer mehr Leute wie schnell die Ladezeit eines Webprojektes ist. Doch nicht nur aus Sicht der Suchmaschine, sondern gerade aus Sicht der Usability, sollte der Faktor Ladezeit betrachtet werden. Websites sollten für User und nicht für Suchmaschinen gestaltet werden. Sorry für diese populisitische Aussage, aber ich konnte mir es nicht verkneifen.

Doch kann nun das Plugin WP-Optimize einen positiven Effekt auf die Ladezeit einer Website haben wenn es die Zwischenspeicherungen löscht, Kommentare löscht und Tabellen optimiert?

Der Test

Natürlich möchte ich mit diesem Artikel nicht nur Theorie sondern auch die Praxis behandeln. Um die Frage des positiven Effektes zu beantworten, habe ich das WordPress Plugin WP-Optimize mit einem Webprojekt getestet.

Daten zum Projekt:

  • Alter: ca. 1 Jahr
  • Datenbankgröße: 185 MB
  • Ladezeit: ca. 0,8 s (ermittelt mit Searchmetrics)

Bevor ein neues Tool oder Plugin ausprobiert wird entweder das komplette Projekt sichern oder aber das Tool / Plugin lokal testen. Da ich WP-Optimize direkt an einem Projekt testen wollte, kam für mich der erste Weg in Frage. Nach der Sicherung habe ich das Tool in das Plugin-Verzeichnis von WordPress geladen und im Backend von WordPress aktiviert. Entgegen vieler Plugins, die ihre Einstellmöglichkeiten im Einstellungs-Menü von WordPress hinzufügen, findet man WP-Optimize im Dashbord.

Die Funktionen wurden bereits oben beschrieben. Die Funktionen der Kommentarbearbeitung von WP-Optimize habe ich nicht genutzt, da ich das Plugin Antispam Bee von Sergej Müller nutze. Somit habe ich lediglich die Funktionen der Löschung der Zwischenspeicherung ( in einem Jahr haben sich über 1000 angesammelt) sowie die Optimierung der Datenbank genutzt. Auf der Unterseite des Plugins im WordPress-Backend sind alle Datenbanken Datensätze sowie das mögliche Einsparungspotenzial zu sehen. Abbildung 1 zeigt einen Screenshot einiger (unkenntlich gemachter) Datenbänke Datensätze. Leider habe ich keinen Screenshot beim eigentlichen Test gemacht.

Screenshot Plugin WP-Optimize Backend

Nachdem ich die Löschung und Optimierung  durchgeführt habe, erfolgte eine erneute Überprüfung der Daten zum Projekt.

Das Ergebnis

Alter: immer noch ca. 1 Jahr ;-)

Datenbankgröße: 181 MB

Ladezeit: ca. 0,8 s (ebenfalls mit Searchmetrics ermittelt)

Vergleicht man nun die Werte Datenbankgröße und Ladezeit, kann man erkennen, dass lediglich marginale Effekte in der Datenbankgröße erzielt wurden.   Leider erzielte das Tool keine Reduzierung der Ladezeit der Website, vielleicht kann ein Effekt bei größeren Datenbanken erzielt werden.

Alternativen

Im Rahmen meiner Recherche zum Plugin, bin ich auf eine Hardcode-Lösung zur Bekämpfung der Zwischenspeicherung von WordPress Artikeln und Seiten gestoßen. Im Blog Webdemar.com wird beschrieben wie man WordPress Post-Revisions deaktivieren kann. Ich habe es noch nicht getestet, jedoch würde dies das Plugin aus Sicht der Zwischenspeicherung überflüssig machen.

Dennoch hat das Plugin WP-Optimize einen Mehrwert, da hierdurch eine Verkleinerung der Datenbank mit nur einem Knopfdruck erreicht werden. Beim Test verursachte das Plugin keine Probleme der Projekt-Datenbank. Somit kann ich WP-Optimize weiterempfehlen.

Verwandte Artikel:

  1. zwei neue Plugins

Tags: , , , , ,

5 Responses to “Test WP-Optimize Plugin für WordPress”

  1. equalizer (2 comments)

    04. Okt, 2010

    So richtig hast du keine Ahnung, von was du schreibst – oder?
    “Löschen der Zwischenspeicherung von Beiträgen” – das dümmste, was man machen kann. Seiten im Cache müssen NICHT neu generiert werden. Entlastet die Datenbank und sorgt für SCHNELLERE Auslieferung der Daten durch den Webserver.
    “Demnach gehe ich davon aus, dass die Datenbankgröße und deren Aufbau ein Einflussfaktor auf die Ladezeit der Website hat.”
    Das ist großer Bullsh*t – die größe der Datenbank hat nichts mit ihrer Performance zu tun. Den “Aufbau” (Struktur!) der DB verändert auch das Plugin nicht, kann hieraus auch keine Performancevorteile ziehen.
    “im Backend von WordPress”
    Dein Backend nennt sich Administrationsbereich. Bitte – wenn schon “Fachbegriffe”, dann richtig!
    “Auf der Unterseite des Plugins im WordPress-Backend sind alle Datenbanken sowie das mögliche Einsparungspotenzial zu sehen”
    Nicht der Datenbanken – sondern Datensätze!
    “Abbildung 1 zeigt einen Screenshot einiger (unkenntlich gemachter) Datenbänke”
    Wieso machst du die Tables unkenntlich? Ist Quatsch, da sowieso überall gleich!

    -> “”Demnach gehe ich davon aus, dass die Datenbank ein Einflussfaktor auf die Ladezeit der Website hat”"
    Der dürfte in so einem kleinen Projekt SO GERING sein, dass es sich nicht lohnt.

  2. admin (3 comments)

    04. Okt, 2010

    Werter anonymer Kritiker,

    erst einmal möchte ich mich für den ausführlichen Kommentar bedanken. Nun ein Statement zum Kommentar.

    1. Kritikpunkt. Mit Zwischenspeicherung meinte ich die Post Revisions, ich hoffe das ist das selbe was du denkst. Und nun zu deiner Kritik. Ich glaube wenn von einer statischen Seite ca. 20 Post Revisions vorhanden sind, weil immer mal wieder etwas gewechselt oder ergänzt wird, ist es durchaus sinnvoll ältere Versionen zu löschen :-) .

    2. Kritikpunkt
    Mein angestellter Programmierer behauptet dies auch immer. Am Beispiel eines Plugins welches eine ständig wachsende Datenbank hat und von Monat zu Monat länger braucht um zu laden, kann ich dies zumindest aus subjektiver Sichtweise eines Nichtinformatikers widerlegen :-P

    3. Kritikpunkt “Backend”
    Zitat Wikipedia:”Der Begriff Backend wird im Unternehmensdeutsch auch häufig irreführenderweise mit grafischen Benutzeroberflächen (meist webbasiert) für Verwaltungs- und Administrationsanwendungen gleichgesetzt.” Da hast du natürlich vollkommen recht. Aber wie ich bereits in meinem ersten Artikel hier geschrieben habe, betreibe ich diesen Blog um etwas zu lernen. Danke dafür. Und übrigens ich bin Unternehmer und deutsch ;-)

    4. “Datensätze”

    stimmt, man legt ja im Normalfall nur eine Datenbank an

    5. Unkenntlich gemacht
    “Wieso machst du die Tables unkenntlich? Ist Quatsch, da sowieso überall gleich!” Ich hab mal gehört, es soll auch Plugins geben, die selber Datensätze in der Datenbank anlegen (siehste ich bin lernfähig) und es muss ja nicht jeder wissen, welche Plugins ich benutze.

    6. Kritikpunkt

    Dass du anhand dieses Artikels die Größe des Projekts, mit dem ich den Test durchführte, erkennen konntest finde ich wirklich bemerkenswert!

    An dieser Stelle nun noch meine Kritik.

    Ich stelle mich gern jeder Diskussion, aber dann bitte hab auch die cojones hier unter einer Identität und nicht nur mit einer Fake E-Mail zu schreiben

  3. admin (3 comments)

    04. Okt, 2010

    Ich hab jetzt mal die Fehler in Datensätze korrigiert. Ich hab jetzt auch wieder entdeckt, dass ich die Datenbankgröße hingeschrieben habe. Deshalb ist es natürlich möglich die Größe des Projektes abzuschätzen. Aber natürlich muss man dazu etwas Erfahrung haben und das scheint ja zumindest bei dir so.

  4. equalizer (2 comments)

    07. Okt, 2010

    1. Kritikpunkt:
    Ich dachte hier wurde an den Cache gedacht – da habe ich nicht richtig gelesen. Ist dennoch irrelevant, da diese an sich nur Speicher belegen, aber keine Datenbankperformance ziehen. Das lässt sich auch ganz einfach erklären (und dürfte Kritikpunkt 2 gleich mit aufgreifen):
    Das DBMS (Datenbankmanagementsystem) fragt nur die Datensätze ab, die du haben möchtest. Wenn du von Merseburg (ich nehme mal an, die Adresse im Impressum stimmt) nach Berlin fährst, wirst du vermutlich über die A9 fahren – meistens sogar Richtung Norden. Du wirst nicht erst anfangen nach Süden in Richtung München zu fahren, um dann über Stuttgart und Frankfurt nach Bremen und dann erst Berlin zu fahren. Die Straßen sind zwar vorhanden, aber nur weil in Deutschland immer mehr Straßen verfügbar sind, wirst du nicht überall langfahren und somit mehr Kilomenter bis zum Ziel brauchen. Ich denke/hoffe du verstehst, auf was ich hinaus will: das DBMS weiß wo die Daten liegen (hierüber wird intern ein Index geführt) und kann somit extrem schnell darauf zugreifen.
    Natürlich dauern die Abfragen umso länger, je mehr Daten du hast – das liegt in der Natur der Sache. Um einen 50kg Sack Zement von A nach B zu tragen wirst du vermutlich länger benötigen, als würdest du selbst ohne diesen Sack dort hin gehen. Hier helfen dann meist optimierte SQL-Queries, die wirklich nur benötigte Daten abfragen.

    3. Kritikpunkt: Hat sich dann wohl geklärt. Nur sollte man eben bei einem “technischen Beitrag” auch darauf achten, das korrekte Vokabular zu nutzen.

    4. Kritikpunkt: Sagen wir: “meistens”.

    5. Kritikpunkt: Daraus kann man zumindest ableiten, welche Plugins du dir installiert hast. Ob diese aktiv sind oder nicht erkennt man daraus nicht.

    Zu deiner Kritik:
    Nun, ich kann dir gern meine “echte” eMail-Adresse geben. Auf meine wahre Identität wirst du damit trotzdem nicht schließen können – da die Domain nämlich nicht mir gehört.

  5. Patrick Wieschollek (1 comments)

    02. Feb, 2011

    Update:

    Ich hab mal wieder in das Plugin geschaut. Nach gut 2-3 Monaten sind nun ca. 5 MB einsparbar, ebenso konnten über 1000 Post Revisions gelöscht werden. Ich bin immer noch der Meinung es ist ein sehr nettes Tool ;-)

Leave a Reply