Unnötige Plugin-Funktionen entfernen statt Plugins zählen

Cookbook: Ziel und Ergebnis

Du identifizierst konkrete teure Funktionen, Hooks, Queries oder Hintergrundjobs. Die Zahl installierter Plugins ist kein Leistungswert: ein einzelnes Plugin kann teuer, zwanzig kleine können unauffällig sein.

Rezept: Schritt für Schritt

1. Seitentypen und Pfade definieren: Cache-Miss, Admin, Suche, Cron, REST, Checkout und Login.
2. Auf Staging mit Query Monitor/APM bzw. PHP-Profiler Zeitanteile, Queries, HTTP-Aufrufe und Hooks erfassen.
3. Verdächtige Funktion oder Moduloption isolieren. Plugin-Deaktivierung nur als kontrollierter A/B-Test mit gleicher Messreihe.
4. Herstelleroption, bedingtes Laden, Update oder Ersatz zuerst prüfen; Core-/Plugin-Dateien nicht patchen.

Rechenweg oder Entscheidungsregel

Kosten pro Funktion = Aufrufe × mittlere Laufzeit\nGesamteffekt = Kosten pro Request × Requests pro Stunde

Ein 300-ms-Job einmal täglich ist meist weniger wichtig als ein 12-ms-Hook auf 1 Million Anfragen.

Praxisbeispiel

Plugin A benötigt 35 ms auf jedem Frontend-Request; bei 100.000 ungecachten Requests sind das 3.500 CPU-s. Plugin B benötigt 700 ms nur beim monatlichen Export. Zuerst Funktion A prüfen, obwohl B im Einzelprofil langsamer wirkt.

Prüfen, ob es funktioniert

• P95 der betroffenen Pfade und Server-CPU verbessern sich wiederholt.
• Keine Funktions-, Daten- oder Sicherheitsregression durch deaktiviertes Modul.
• Page Cache ist während Backend-Vergleich kontrolliert miss/aus, sonst wird Pluginarbeit verdeckt.

Rollback

Deaktivierte Moduloption oder eigenes bedingtes Lade-Snippet zurücksetzen. Bei Pluginwechsel Datenmigration und Rückkehrweg vorab testen; niemals Produktionsdaten löschen, nur weil ein Plugin deaktiviert wurde.

Was Last erzeugt

Plugins können PHP-Code ausführen, Datenbankabfragen starten, Optionen autoloaden, Cronjobs planen, externe APIs aufrufen und Frontend-Assets laden. Die Anzahl installierter Plugins misst keine dieser Größen.

Vorgehen

1. Seitentypen und langsame Pfade identifizieren.
2. PHP-Zeit, Query-Zeit, externe Requests, Autoload und Frontend-Assets je Komponente zuordnen.
3. Funktionsduplikate und ungenutzte Module deaktivieren.
4. Alternativen anhand gleicher Funktionen und realer Messung vergleichen.

Deaktivieren und Löschen

Eine deaktivierte Erweiterung führt normalerweise keinen Runtime-Code aus, kann aber Daten und Dateien hinterlassen. Löschen nur, wenn sie nicht mehr benötigt wird und Wiederinstallation/Backup geklärt ist. Sicherheitsupdates bleiben relevant, solange Code öffentlich liegt.

Erfolgskontrolle

Neben TTFB und Assets komplette Geschäftsprozesse testen. Unterschiede mit warmem/kaltem Cache und für eingeloggte Nutzer messen.

Quellen und Prüfstand

• WordPress: Performance-Optimierung
• WordPress: PHP-Optimierung

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.