WordPress-Plugin Optimierung

Vor Weihnachten habe ich ein schönes neues Spielzeug für WordPress entdeckt: P3 – Plugin Performance Profiler. Profiler – mein Lieblingsspielzeug. Denn ohne einen vernünftigen Profiler kann man auch nicht vernünftig optimieren. Ok, der P3 ist kein super ausgefeiltes Werkzeug, aber es zeigt für alle installierten Plugins an, wie viel Zeit für deren Ausführung benötigt wurde. Und mit der Information lässt sich schon so einiges anfangen. Vor allem zeigt es nämlich welche Plugins viel zu viel unnötige Rechenzeit beanspruchen, ohne dabei wirklich etwas zu tun.

P3 analysiert wieviel Rechenzeit die aktiven Plugins benötigen

Ein schönes Beispiel dafür: Admin Management Xtended. Das Plugin erweitert einiges im Backend, arbeitet aber auch dann, wenn das Backend gar nicht angezeigt wird. Eine simple Abfrage auf is_admin hat das „Problem“ erledigt (und es scheint auch noch zu funktionieren, aber wirklich getestet habe ich es noch nicht). Ein schönes Beispiel für ein schlecht geschriebenes Plugin (zumindest hinsichtlich der Performance – ansonsten ist es gut). Zu viele Plugins initialisieren immer alles und machen bei jedem Aufruf Berechnungen, Datenbankabfragen usw. – egal ob wirklich nötig oder nicht.

Ein anderes Beispiel ist der WordPress Download Monitor: Das Plugin lädt beim Initialisieren diverse Dinge aus der Datenbank vor – um den späteren Ablauf zu optimieren. An sich nicht unbedingt verkehrt, aber die Datenbankabfragen werden immer gemacht, egal ob sie wirklich benötigt werden, oder nicht. Und das kostet Zeit. Viel Zeit in diesem Fall.

Ein „Problem“ das viele Plugins haben: Sie speichern jede Menge Einstellungen einzeln in der Datenbank. Empfehlenswerter (und schneller) ist es, alle Einstellungen eines Plugins als Array in einem Datenbankeintrag zu speichern (sicherlich gibt es Ausnahmen für diese Regel). Das Laden vieler Einstellungen aus der Datenbank kann sich deutlich auf die Performance auswirken (und ich habe Plugins gesehen mit zig einzeln gespeicherten Optionen gesehen, die alle diese Einstellungen beim Initialisieren in globale Variablen laden um im Folgenden nicht mehr mit get_options zu arbeiten – mal wieder ganz egal ob das Plugin wirklich ausgeführt wird, oder nicht).

Was mir aufgefallen ist, beim Versuch diverse Plugins zu optimieren, es gibt kaum vernünftige Anleitungen, wann ein Plugin genau was machen sollte. Wann sollen welche Hooks registriert werden? Wie ist der genaue Ablauf der Ausführung? Welche Empfehlungen gibt es? Gibt es Performance-Tipps? Alles was ich bisher heruasgefunden habe, musst ich mir mühsam von verschiedenen Stellen zusammensuchen. Darum arbeite ich gerade an einem Artikel darüber – um es selbst zu lernen und das gelernte irgendwo festzuhalten und ggf. so auch weiterzugeben.

Aber wie gesagt – ich arbeite noch daran. Bis dahin spielt mit dem Plugin Performance Profiler herum. Der funktioniert übrigens erst ab WordPress 3.3.

3 thoughts on “WordPress-Plugin Optimierung”

  1. Oliver Schlöbe says:

    Hallo Bjoern,

    danke erst mal für den tollen Plugin-Fund! Kannte ich bisher noch nicht! 🙂

    Mein Plugin Admin Management Xtended nennst du im Zusammenhang mit Performance, daher danke für die Erinnerung, dass ich da Hand anlegen wollte. Das Problem ist/war wohl eher, so viele WP-Versionen wie möglich unterstützen zu wollen. Habe kürzlich die Min-Version heraufgesetzt, einige Sachen rausgeworfen, aber wohl einige Alt-Lasten drin gelassen (z.B. das Schreiben eines Meta-Tags im Frontend zu Support-Zwecken; vor mehreren Jahren auf die glorreiche Idee gekommen 😉 ). Aber ich wollte die ruhigen Feiertage eh mal nutzen, um für all meine Plugins Wartungs-Updates rauszuhauen.

  2. Bjoern says:

    @Oliver: Da Dein Plugin mit A anfängt, war es eines der ersten, das ich mir genauer angesehen habe. Eine einfache Abfrage auf is_admin beim Erzeugen der Instanz hat die „verbrauchte“ Zeit von 0,028s auf 0,009s gesenkt, daher habe ich es hier als Beispiel aufgeführt. Wie die restliche Performance ist, kann ich nicht sagen, aber das Plugin an sich gefällt mir sehr gut.

    Solche Altlasten, wie Du sie erwähnst, haben viele Plugins. Ob man unbedingt auch die ältesten WordPress-Versionen unterstützen muss ist Geschmackssache, würde ich sagen. Ich für meinen Teil würde das nicht machen, da es auch die Wartung immer mehr erschwert.

    Bin sehr gespannt auf Deine Wartungsupdates 🙂

  3. Oliver Schlöbe says:

    Die Jungs von Automattic hatten kürzlich einige Stats veröffentlicht, nach denen ältere WP-Installationen nach Veröffentlichung neuer Versionen kaum noch genutzt werden bzw. gleich geupdated werden, sodass ich davon weg bin, so weit wie möglich rückwärts kompatibel zu sein. Das erschwert wie du schon sagtest nicht nur die Wartung, sondern bläht auch das Plugin auf.

    Ich habe es nun auch mit is_admin() entschärft, wobei ich bisher eigentlich nur admin_init und admin_head Actions genutzt habe, sodass sich das Gros der Aktionen nur im Admin abgespielt hat. Aber es wurde halt bei jedem Aufruf auch im FE die Klasse instanziert, das fällt in Version 2.2.5 nun weg. 🙂 Und das alles nur, weil ich vor 3 Jahren einen Metatag im FE schreiben wollte, und daher auf das is_admin verzichtet habe… 😉

Schreibe einen Kommentar

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