Langsame WordPress-Plugins mit Query Monitor finden und beheben

Eine WordPress-Seite, die mehrere Sekunden bis zum ersten Byte braucht, kostet Besucher und Geduld im Team. Häufig steckt nicht der Server dahinter, sondern ein einzelnes Plugin, das bei jedem Seitenaufruf langsame Datenbankabfragen absetzt, dieselbe Abfrage mehrfach wiederholt oder auf einen externen Dienst wartet. Mit dem kostenlosen Plugin Query Monitor finden Sie diesen Verursacher gezielt, statt Plugins auf Verdacht abzuschalten. Diese Anleitung zeigt, wie Sie Query Monitor einrichten, die richtigen Ansichten lesen und das Ergebnis sauber absichern. Alle Werte und Meldungen stammen aus einer Testinstanz mit WordPress 7.1.2 und Query Monitor 4.0.7.

Voraussetzungen

• WordPress: Query Monitor 4.0.7 setzt laut Plugin-Verzeichnis WordPress 6.2 und PHP 7.4 voraus. Getestet haben wir mit WordPress 7.1.2 und PHP 8.4.
• Rolle: Administrator. Query Monitor zeigt seine Daten standardmäßig nur Administratoren, in Multisite-Netzwerken nur Super-Admins.
• Zugriff: WordPress-Backend für Installation und Auswertung. Für das Aufräumen der Datei db.php zusätzlich FTP/SFTP oder SSH. WP-CLI ist optional und beschleunigt die Messungen.
• Testumgebung: idealerweise eine Staging-Kopie der Website mit denselben Plugins und Daten. Messungen auf einer leeren Testinstallation sagen wenig aus.
• Backup: ein aktuelles Backup von Dateien und Datenbank, bevor Sie auf der Live-Website Plugins installieren oder deaktivieren.

Schritt 1: Ausgangswert messen

Bevor Sie ein Plugin installieren, halten Sie fest, wie langsam die Seite heute ist. Ohne diesen Wert können Sie später nicht belegen, ob eine Änderung etwas gebracht hat. Messen Sie die Antwortzeit des Servers, nicht die gefühlte Ladezeit im Browser, denn Bilder, Schriften und Skripte verfälschen das Bild.

curl -s -o /dev/null -w "%{http_code} %{time_starttransfer}\n" https://ihre-domain.de/

Der zweite Wert ist die Zeit bis zum ersten Byte in Sekunden. Wiederholen Sie die Messung drei bis fünf Mal und notieren Sie den typischen Wert. Ist ein Seiten-Cache aktiv, bekommen anonyme Besucher oft eine zwischengespeicherte Kopie. Das eigentliche Problem sehen Sie dann nur bei angemeldeten Nutzern, im Backend oder beim ersten Aufruf nach dem Leeren des Caches.

Verifizieren: Sie haben für jede betroffene Seite einen Ausgangswert mit HTTP-Status 200 und wissen, ob ein Seiten-Cache die Messung beeinflusst.

Schritt 2: Query Monitor installieren

Installieren Sie das Plugin im Backend über „Plugins“ → „Plugin hinzufügen“, Suche nach „Query Monitor“, dann „Jetzt installieren“ und „Aktivieren“. Per WP-CLI geht es in einem Befehl, die deutsche Übersetzung laden Sie gleich mit:

wp plugin install query-monitor --activate
wp language plugin install query-monitor de_DE

Beim Aktivieren legt Query Monitor eine symbolische Verknüpfung wp-content/db.php an, die auf eine Datei im Plugin-Ordner zeigt. Dieses sogenannte Drop-in ersetzt die Datenbankklasse von WordPress und liefert erst die Detaildaten zu jeder Abfrage, etwa Aufrufer und Laufzeit. Prüfen Sie, ob die Verknüpfung existiert:

wp qm enable

Im Labor meldet der Befehl bei vorhandener Verknüpfung Success: Query Monitor's wp-content/db.php is already in place, sonst legt er sie an: Success: wp-content/db.php symlink created. Liegt bereits eine fremde db.php eines Cache- oder Sicherheits-Plugins vor, bricht er mit Error: Unknown wp-content/db.php is already in place ab. Überschreiben Sie diese Datei nicht, das andere Plugin braucht sie. Query Monitor funktioniert dann mit weniger Details weiter.

Warum auf Staging? Query Monitor hat laut Entwickler nur geringen Einfluss auf die Seitenerstellungszeit, verbraucht auf Seiten mit Hunderten Abfragen aber spürbar mehr Speicher. Auf einer Live-Website mit knappem PHP-Speicherlimit kann das den Unterschied machen. Wie Sie eine Staging-Kopie anlegen, beschreibt die Anleitung WordPress-Staging-Umgebung mit WP-CLI einrichten.

Verifizieren: In der Werkzeugleiste oben erscheint ein neuer Eintrag mit vier Werten, zum Beispiel 2,49 s 6,8 MB 0,34 s 30Q. Abgemeldete Besucher sehen davon nichts: Im Labor enthielt die Startseite ohne Anmeldung keine Daten von Query Monitor.

Schritt 3: Werkzeugleiste und Überblick lesen

Rufen Sie die langsame Seite im Frontend auf, während Sie als Administrator angemeldet sind. Die vier Werte in der Werkzeugleiste bedeuten von links nach rechts: Zeit zur Seitenerstellung, Spitze der Speichernutzung, Gesamtzeit aller Datenbankabfragen und Anzahl der Abfragen. Eine rot oder orange hinterlegte Leiste weist auf langsame Abfragen, PHP-Fehler oder fehlgeschlagene HTTP-Anfragen hin.

Der Vergleich der ersten und dritten Zahl ist der wichtigste Hinweis. In unserem Test dauerte die Seitenerstellung 2,49 Sekunden, die Datenbank aber nur 0,34 Sekunden. Der Großteil der Zeit lag also außerhalb der Datenbank. Typische Ursachen sind externe Anfragen oder aufwendige PHP-Berechnungen. Ist die Datenbankzeit dagegen fast so hoch wie die Gesamtzeit, liegt das Problem bei den Abfragen.

Verhältnis	Bedeutung	Weiter mit
Datenbankzeit nahe Gesamtzeit	langsame oder sehr viele Abfragen	Schritt 4
Datenbankzeit klein, Gesamtzeit hoch	externe Anfragen oder PHP-Last	Schritt 5
Speicher nahe am Limit	großer Datenbestand oder Plugin lädt zu viel	Panel „Arbeitsumgebung“ prüfen

Klicken Sie auf den Eintrag in der Werkzeugleiste, um das Panel zu öffnen. Im Panel „Überblick“ sehen Sie dieselben Werte zusammen mit dem PHP-Zeitlimit und dem Speicherlimit. Das Panel „Arbeitsumgebung“ zeigt PHP-Version, memory_limit, max_execution_time und die Datenbankversion.

Verifizieren: Sie können für die betroffene Seite sagen, ob die Zeit überwiegend in der Datenbank oder außerhalb davon entsteht.

Schritt 4: Datenbankabfragen einem Plugin zuordnen

Öffnen Sie im Panel „Datenbankabfragen“ die Unteransicht „Abfragen nach Komponenten“. Query Monitor summiert hier Anzahl und Zeit der Abfragen je Plugin, Theme und WordPress-Core. Ein Plugin mit auffällig hohem Anteil ist Ihr erster Kandidat.

Die Ansicht „Slow Queries“ listet Abfragen, die länger als 0,05 Sekunden dauern. Diesen Schwellwert legt Query Monitor im Quellcode als Konstante QM_DB_EXPENSIVE fest. Im Labor erschien dort eine absichtlich verlangsamte Abfrage von 0,3 Sekunden mit Komponente „Plugin: langsam-demo“ und Aufrufer langsam_demo_run. Sie können den Schwellwert in der wp-config.php anheben:

define( 'QM_DB_EXPENSIVE', 0.5 );

Nach dieser Änderung verschwand im Test die Markierung für langsame Abfragen, weil 0,3 Sekunden unter der neuen Grenze lagen. Setzen Sie den Wert daher nur hoch, wenn Sie gezielt die schlimmsten Ausreißer suchen, und entfernen Sie die Zeile danach wieder.

„Doppelte Abfragen“ zeigt Abfragen, die in einem Seitenaufruf mehrfach identisch laufen. Im Test tauchte dieselbe Abfrage auf wp_options fünfmal auf, Aufrufer und Komponente waren direkt daneben genannt. Einzelne Dopplungen sind normal. Dutzende Wiederholungen deuten auf einen fehlenden Zwischenspeicher im Plugin hin, ein Fall für den Hersteller-Support.

Verifizieren: Sie kennen die Komponente mit dem größten Zeitanteil und haben die konkrete langsame oder doppelte Abfrage samt Aufrufer notiert.

Schritt 5: HTTP-Anfragen und PHP-Fehler prüfen

Viele Plugins fragen bei jedem Seitenaufruf externe Server ab, etwa für Lizenzprüfung, Statistik oder Schriftarten. Antwortet der Dienst langsam oder gar nicht, wartet Ihre Seite bis zur Zeitüberschreitung. Das Panel „HTTP-API-Abrufe“ listet jede Anfrage über die WordPress-HTTP-API mit Ziel, Dauer, Komponente und Ergebnis. Fehlgeschlagene Anfragen färbt Query Monitor als Warnung ein.

Im Labor hat ein Test-Plugin eine nicht erreichbare Adresse abgefragt. Query Monitor zeigte die Anfrage mit 2,0 Sekunden Dauer, Komponente „Plugin: langsam-demo“ und der Meldung cURL error 28: Connection timed out after 2006 milliseconds. Diese zwei Sekunden erklärten fast die gesamte Differenz zwischen Seitenerstellung und Datenbankzeit aus Schritt 3.

Prüfen Sie auch das Panel „PHP-Fehler“: Warnungen und Hinweise kosten bei hoher Anzahl Zeit, und der Hinweis auf die verursachende Komponente spart die Suche im Log. Für die Analyse von PHP-Fehlern ohne Query Monitor lesen Sie WordPress Debug-Modus aktivieren: Error-Logs analysieren.

Verifizieren: Sie wissen, ob externe Anfragen oder PHP-Fehler Zeit kosten, und kennen das auslösende Plugin.

Schritt 6: Verdacht bestätigen und handeln

Die Zuordnung von Query Monitor ist ein starker Hinweis, aber kein Beweis. Bestätigen Sie den Verdacht auf der Staging-Kopie, indem Sie das Plugin deaktivieren und erneut messen wie in Schritt 1:

wp plugin deactivate plugin-slug
curl -s -o /dev/null -w "%{http_code} %{time_starttransfer}\n" https://staging.ihre-domain.de/
wp plugin activate plugin-slug

Ersetzen Sie plugin-slug durch den Ordnernamen aus wp plugin list. Sinkt die Zeit deutlich, haben Sie den Verursacher. Danach stehen Ihnen mehrere Wege offen, jeweils mit eigenen Nachteilen:

• Update prüfen: Viele Performance-Probleme sind in neueren Versionen behoben. Lesen Sie das Änderungsprotokoll, bevor Sie aktualisieren.
• Einstellungen anpassen: Statistik-, Protokoll- oder Live-Funktionen lassen sich oft abschalten. Das kostet Funktion, spart aber Zeit bei jedem Aufruf.
• Hersteller informieren: Schicken Sie Abfrage, Aufrufer und gemessene Zeit mit.
• Plugin ersetzen: Wird ein Plugin nicht mehr gepflegt, hilft oft nur der Wechsel. Wie Sie das erkennen, zeigt Veraltete und aufgegebene WordPress-Plugins erkennen und ersetzen.

Performance ist kein einmaliger Zustand. Jedes Plugin-Update kann neue Abfragen oder externe Anfragen mitbringen, und wachsende Datenbestände machen bisher harmlose Abfragen langsam. Planen Sie deshalb nach größeren Updates eine kurze Messung ein. Wer diese Kontrolle zusammen mit Updates und Sicherungen nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und legt wöchentliche Backups auf externem Speicher ab.

Verifizieren: Nach der Maßnahme liegt die gemessene Zeit bis zum ersten Byte messbar unter dem Ausgangswert aus Schritt 1, und die Funktion der Website ist unverändert.

Schritt 7: Query Monitor wieder entfernen

Query Monitor ist ein Diagnosewerkzeug. Lassen Sie es nicht dauerhaft auf der Live-Website aktiv: Es kostet Speicher, und jedes zusätzliche Plugin ist ein weiteres Update, das gepflegt werden muss. Deaktivieren und löschen Sie es nach der Analyse:

wp plugin deactivate query-monitor
wp plugin delete query-monitor
ls -la wp-content/db.php

Laut Quellcode entfernt Query Monitor beim Deaktivieren die Datei db.php nur, wenn sie zu Query Monitor gehört und das eigene Datenbank-Drop-in geladen war. Im Labor blieb nach Deaktivieren und Löschen per WP-CLI eine verwaiste Verknüpfung zurück, die ins Leere zeigte. Die Website lief weiter mit Status 200, weil WordPress eine nicht auflösbare Verknüpfung ignoriert. Entfernen Sie sie trotzdem, denn bei einer Neuinstallation würde sie wieder aktiv, und andere Plugins können dann ihre eigene db.php nicht anlegen. Prüfen Sie vorher, dass die Verknüpfung wirklich auf den Ordner query-monitor zeigt:

readlink wp-content/db.php
rm wp-content/db.php

Löschen Sie keine db.php, die auf ein anderes Plugin zeigt oder eine echte Datei ist. Entfernen Sie außerdem eine gesetzte Konstante QM_DB_EXPENSIVE aus der wp-config.php.

Verifizieren: wp plugin list zeigt Query Monitor nicht mehr, ls -la wp-content/db.php meldet keine verwaiste Verknüpfung, die Startseite antwortet mit Status 200.

Typische Fehler

• Keine Werte in der Werkzeugleiste: Sie sind nicht als Administrator angemeldet oder die Werkzeugleiste ist im Profil unter „Werkzeugleiste für mich auf der Website anzeigen“ abgeschaltet. Abgemeldete Besucher sehen grundsätzlich nichts.
• Error: Unknown wp-content/db.php is already in place: Ein anderes Plugin nutzt das Datenbank-Drop-in. Lassen Sie die Datei stehen. Die Zuordnung von Abfragen zu Komponenten fällt dann weniger detailliert aus.
• Messung zeigt kaum Unterschiede: Ein Seiten- oder Objekt-Cache liefert zwischengespeicherte Ergebnisse. Leeren Sie den Cache vor der Messung oder messen Sie angemeldet.
• Nach dem Deaktivieren noch db.php vorhanden: Im Test blieb eine verwaiste Verknüpfung zurück. Entfernen Sie sie wie in Schritt 7 beschrieben.

Häufige Fragen

Macht Query Monitor meine Website selbst langsamer?

Etwas. Der Entwickler beschreibt den Einfluss auf die Seitenerstellungszeit als gering, bei Hunderten Abfragen pro Seite steigt aber der Speicherbedarf. Für eine Analyse von wenigen Stunden ist das in der Regel unkritisch, als Dauerlösung auf der Live-Website nicht sinnvoll.

Kann ich Seiten messen, die nur abgemeldete Besucher sehen?

Ja. In den Einstellungen von Query Monitor können Sie ein Authentifizierungs-Cookie setzen. Damit sehen Sie die Ausgabe auch abgemeldet in diesem Browser. Löschen Sie das Cookie nach der Analyse wieder über „Authentifizierungs-Cookie löschen“.

Ersetzt Query Monitor ein Slow Query Log der Datenbank?

Nein. Query Monitor zeigt nur die Abfragen des Seitenaufrufs, den Sie gerade ansehen. Langsame Abfragen aus Cronjobs, Importen oder von anderen Besuchern erfasst das Slow Query Log des Datenbankservers. Wie Sie es einschalten, zeigt MySQL Slow Query Log einrichten und langsame Abfragen finden.

Testumfang

Wir haben Query Monitor mit WordPress 7.1.2 im Labor ausprobiert. Die langsame Abfrage, doppelte Abfragen und eine nicht erreichbare HTTP-Anfrage unseres Test-Plugins erschienen in der Werkzeugleiste, samt Zuordnung zum verursachenden Plugin. Auffällig war, dass nach Deaktivieren und Löschen eine verwaiste db.php zurückblieb. Multisite und produktive Websites haben wir nicht geprüft, testen Sie deshalb zuerst auf einer Kopie.

Fazit

Query Monitor macht sichtbar, welches Plugin wie viel Zeit kostet: Werkzeugleiste für den ersten Eindruck, Komponentenansicht für die Zuordnung, HTTP-Panel für wartende externe Anfragen. Wer mit Ausgangswert, Staging-Kopie und Gegenmessung arbeitet, trifft belastbare Entscheidungen statt Plugins auf Verdacht zu entfernen. Soll jemand die Updates danach dauerhaft betreuen, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Staging-Umgebung mit WP-CLI einrichten
• WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler selbst beheben
• Veraltete und aufgegebene WordPress-Plugins erkennen und ersetzen
• Query Monitor im WordPress-Plugin-Verzeichnis
• WP-CLI: wp plugin
• WordPress Advanced Administration: Optimization