Performanceanalyse von Plugins

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 🙂

Langsame Datenbankabfragen identifizieren

Gestern hatte ich euch berichtet, welche Fehler man bei der Analyse machen kann. Heute möchte ich euch einen ersten Tipp geben, wie ihr Performanceprobleme mit Datenbankabfragen erkennen könnt.

Ein sehr wichtiger Performancewert ist ja die sogenannte “Time to first byte”, also die Zeit die es dauert, bis der Server nach einer Anfrage die ersten Daten zurückschickt. Ist diese Zeit sehr hoch (etwa mehr als 0,5 Sekunden), dann ist in der Regel eines dieser beiden Dinge schuld (oder beide): die Ausführungszeit der PHP-Skript oder die Dauer der Datenbankabfragen. Um die PHP-Skripte geht es in einem anderen Artikel, also beschäftigen wird und heute mal mit den Datenbankabfragen.

Exkurs: Annahmen zu Datenbankabfragen

Ich möchte auch heute ein wenig auf typische Annahmen eingehen, weshalb eine Seite langsam ist, und diese ein wenig entkräften.

Weiterlesen →

Häufige Fehler bei der Performanceanalyse einer Website

Eine Frage, die eigentlich fast ständig bei Meetups, Facebook-Gruppen oder ähnlichem aufkommt sind Fragen zur Performance einer Seite. Daher möchte ich heute mal einen kleinen Überblick geben, welche Tipps ich in diesem Fall gebe um eine Seite erst einmal

Analysefehler 1: Die falschen Schlüsse ziehen

In den allermeisten Fällen startet das Gespräch damit, dass ein schlechtes Ergebnis bei Google PageSpeed Insights erreicht wurde. Auf einigen Seiten liest man, dass man möglichst 95 Punkte oder mehr erreichen und alle Fehler beheben muss. Ich verrate euch jetzt mal ein schockierendes Geheimnis: das ist Blödsinn 😉

Weiterlesen →

Edit Shortcuts im Customizer

Im Beitrag von gestern hatte ich euch am Ende ja noch kurz einen Hinweis auf die “Edit Shortcuts” gegeben. Heute möchte ich ein wenig genauer darauf eingehen, worum es sich dabei handelt und wie ihr diese auch für eure Optionen verfügbar machen könnt.

Automatisch verfügbar für neue Features

Die Edit Shortcuts sind fest mit den sogenannten “Selective Refresh Partials” verbunden. Also mit jenen Elementen des Customizers, die bei einer Änderung der Einstellungen das Ergebnis sofort im Vorschaubereich anzeigen, ohne dabei die gesamte Vorschau neu laden zu müssen.

Aber hier kommt auch schon die schlechte Nachricht. Man kann Edit Shortcuts deshalb nicht einfach zu global für alle Optionen aktivieren. Es muss stattdessen die Customizer Option ebenfalls um einen “Selective Refresh” erweitert werden.

Weiterlesen →

Neuen Video-Header in TwentyThirteen einsetzen

Zusammen mit WordPress 4.7 wurden die sogenannten Video-Header eingeführt. Damit ist es möglich, anstelle eines Bilder, ein Video als Hintergrundbild zu verwenden. Eingestellt werden diese dann über den Customizer. Ich habe mir das neue Feature mal angesehen. Es gibt ja schon einige Anleitungen mit dem Code-Snippet, das man dazu verwenden muss. Aber ich hatte noch keine Anleitung gesehen, die es mal in ein bestehendes Theme einbaut. Daher möchte ich euch heute zeigen, wie ihr es beispielsweise in TwentyThriteen verwenden könnt.

Der Bild-Header in TwentyThirteen

Ich setze ja selbst kein Theme mit Bild-Header ein. Allerdings verwenden viele Seiten, die ich kenne, das beliebte Default-Theme TwentyThirteen. Hier gehört ein Bild-Header ja fest zum Layout (auch wenn man es im Grunde sogar ausblenden kann).

Das Bild wird hierbei über einen CSS-Hintergrund umgesetzt.Die Größe des Headers wird durch dessen Textinhalt festgelegt und hat mindestens 230px Höhe:

Weiterlesen →