Nachdem ich euch gestern gezeigt habe, welche Tools es für die Analyse von MySQL Datenbankabfragen gibt, möchte ich heute auf den zweiten potentiellen Flaschenhals bei der Performance eingehen: die Ausführungszeit der PHP-Skripte. Hierbei soll es auch darum gehen, Plugins zu identifizieren, die besonders viel Ladezeit verursachen.

Das Plugin „P3 (Plugin Performance Profiler)“

Eine Erhebung solcher Daten ist nicht gerade einfach. Glücklicherweise gibt es genau für diesen Zweck ein sehr gutes Plugin. Den Plugin Performance Profiler oder abgekürzt einfach P3 genannt. Nachdem ihr dieses kostenlose Plugin installiert habt, könnt ihr über „Werkzeuge | P3 Plugin Profiler“ einen neuen Test starten. Ich war mal so mutig und habe es für diese Seite gemacht 🙂

Wenn ihr einen „Auto Scan“ startet, dann wird das Plugin innerhalb des Frames einige Seiten laden und dabei die Ladezeit und den Einfluss der Plugins testen. Standardmäßig werden folgende Seiten getestet:

• Die Startseite
• Eine Suche nach dem Namen der Seite
• Vier Schlagwort-Seiten
• Vier Kategorie-Seiten
• Die vier der letzten Beiträge
• Das Admin-Dashboard
• Die Beiträge-Übersicht im Dashboard
• Die Plugin-Seite im Dashboard

Nach dem Scan bekommt ihr zum einen eine kleine Zusammenfassung über die wichtigsten globalen Kennzahlen der Analyse:

Sehr interessant ist hier schon mal der Wert von „Plugin Impact“. Dieser gibt an, wie viel Zeit innerhalb von Plugin Funktionen verbraucht wurde. Ist diese Zahl sehr hoch, dann kann das Performanceproblem tatsächlich an einem Plugin (oder mehreren) liegen. Einen Hinweis darauf kann euch der Reiter „Runtime by Plugin“ liefern:

In diesem Beispiel haben die Plugins „MultilingualPress“, „All In One Seo Pack“ und „Jetpack“ den größten Einfluss auf die Ladezeit. Per Mouseover erfahrt ihr, wie lange die Ausführung pro Plugin insgesamt gedauert hat. Bei manchen Plugins zeigt P3 eine Warnung an, dass die gemessene Ladezeit eventuell zu hoch sein könnte. Dies ist beispielsweise in diesem Beispiel bei „Jetpack“ der Fall.

Detaillierte Auswertung

Nun könnte man also der Meinung sein, dass Jetpack schuld an der schlechten Performance ist. Eine Meinung, die sich ja hartnäckig in der WordPress Community hält 😉 Interessant ist es aber, wenn man mal die Zahlen genauer betrachtet. Unter dem Reiter „Advanced Metrics“ findet ihr erst einmal die nackten Zahlen:

Total Load Time:	2.5267seconds avg.
Site Load Time:	1.8189seconds avg.
Profile Overhead:	0.7078seconds avg.
Plugin Load Time:	0.4778seconds avg.
Theme Load Time:	0.0239seconds avg.
Core Load Time:	1.3068seconds avg.
Margin of Error:	0.0104seconds avg. (2.5267 observed, 2.5162 expected)
Visits:	31
Number of PHP ticks:	29,888 calls avg.
Memory Usage:	67.36 MB avg.
MySQL Queries:	78 queries avg.

Wie ihr also sehen könnt, wurde ein Großteil der Ladezeit im Core verbracht. Bei der weiteren Analyse ebenfalls noch sehr interessant ist der Reiter „Detailed Timeline“, die alle oben aufgelisteten Zugriffe einzeln darstellt. Hier mal das Schaubild dazu (es enthält normalerweise auch den Core, den ich aber ausgeblendet habe, damit die anderen Linien besser sichtbar sind):

Jeder Messwert auf dem Liniendiagramm entspricht einem der Requests. Es ist bei der Analyse auch zu beachten, dass der Test selbst einen Einfluss auf die Performance hat. Im Diagramm ist das P3 Plugin ja auch selbst aufgeführt.

Manueller Scan

Ein ganz wichtiger Aspekt kommt beim „Auto Scan“ auch noch dazu. Die Tests laufen in einem iframe im Backend durch. Man ist also als Administrator eingeloggt. Daher wird auch die Adminbar und einige andere Dinge aus dem Backend bei jedem Request aufgerufen. Daher würde ich euch empfehlen, auch mal einen „Manual Scan“ zu machen. Hierzu klickt er den anderen Button im Screenshot oben. Anschließend ruft ihr eure Seite in einem Inkognito-Tab (oder einem anderen Browser) auf. Navigiert dann auf verschiedene Unterseiten, die ihr testen wollt. Sobald ihr fertig seid, klickt ihr im Fenster unten rechts auf „I’m Done“. Es wird dann ein Bericht mit eurem manuellen Scan erstellt. Ihr könnt über diesen Weg sogar AJAX Requests analysieren. Alle Scans werden in einer History gespeichert und ihr könnt sie nachträglich noch einmal ansehen.

Tipp: Plugins einzeln deaktivieren und Unterschied testen

Solltet ihr also ein Plugin gefunden haben, das eine starke Auswirkung auf die Performance aufweist, dann würde ich euch empfehlen, erst einmal nur dieses eine Plugin zu deaktivieren. Wenn sich merklich etwas ändert, dann stehen die Chancen recht hoch, dass auch dieses Plugin verantwortlich ist (es muss aber nicht die einzige Ursache sein).

Wenn ihr dann das Plugin ausfindig gemacht habt, dann muss weiter analysiert werden, woran es genau liegt. Hierzu könnte man sich beispielsweise die Datenbankabfragen dieses Plugins ansehen. Oder aber man greift zu noch mächtigeren Werkzeugen, wie etwa dem Xdebug Profiling, was aber wirklich eher etwas für Profis ist.

Fazit

Ich hoffe, nach den drei Artikeln der vergangenen Tage, habt ihr einen kleinen Einblick bekommen, mit welchen Tools und Plugins man die Performance einer Seite analysieren und Engpässe finden kann. Jeder Seite hat ihre eigenen Ursachen für eine schlechte Gesamtperformance. Es kann auch an externen Faktoren, wie etwa der Anbindung oder des Standortes des Rechenzentrums, liegen. Aber ich denke, dass ihr mit den Tipps schon eine ganz gute Übersicht bekommen solltet.

Ich denke ich schließe hiermit meine kleine Artikelreihe zur Performance ab. Es sei denn, ihr habt noch eine Frage, deren Beantwortung noch einen weiteren Artikel wert ist 😉 Ansonsten freue ich mich wie immer über Kommentare 🙂