WordPress Plugin-Bloat: Wann weniger Plugins mehr sind

Von Manuel Hack, ihp media · Aktualisiert am 15. Juni 2026

Eine WordPress-Website funktioniert, also wird sie gepflegt, und beim Pflegen kommen immer wieder neue Plugins dazu. Social-Sharing hier, ein Formular-Builder dort, ein Slider-Plugin, das der Entwickler damals für eine einzelne Startseiten-Animation installiert hat und das seither niemand mehr angefasst hat. Nach zwei Jahren stehen 30, 40 oder 50 installierte Plugins in der Liste, ein Drittel davon inaktiv, ein weiteres Drittel selten gebraucht. Das ist kein Einzelfall, das ist der Normalzustand bei Websites, die gewachsen sind statt geplant worden zu sein.

Der Plugin-Bestand beeinflusst direkt, wie schnell die Website lädt, wie groß die Angriffsfläche ist und wie viel Pflegeaufwand anfällt. Wer das methodisch angeht, sortiert einmal gründlich aus und prüft neue Plugins vor der Installation nach klaren Kriterien.

Was passiert, wenn WordPress ein Plugin lädt

WordPress lädt aktive Plugins früh im Bootstrap-Prozess, bevor die eigentliche Seite aufgebaut wird. Das System durchsucht das Plugins-Verzeichnis, liest die Plugin-Header und führt den PHP-Code aller aktiven Plugins aus. Ein Plugin, das eine Funktion für die Kontaktseite bereitstellt, läuft also auch beim Laden eines Blogartikels, eines Produkts oder der Startseite mit. Die offizielle WordPress-Dokumentation zur Performance-Optimierung formuliert das direkt: „Deactivate and delete any unnecessary plugins“ ist die erste und einfachste Maßnahme zur Verbesserung der Website-Geschwindigkeit.

Was dabei konkret passiert: Jedes Plugin registriert Hooks, lädt Klassen, prüft Bedingungen, stellt Assets wie CSS und JavaScript in die Warteschlange. Manche Plugins tun das selektiv und nur dort, wo sie gebraucht werden. Andere laden ihre Ressourcen global. Ein schlecht programmiertes Plugin kann Datenbankabfragen auslösen, externe API-Aufrufe starten oder CSS-Dateien einbinden, die kein Nutzer sieht, weil er die Funktion nie aufruft. Die Last ist nicht gleichmäßig verteilt, sie hängt stark von der Plugin-Qualität ab.

Inaktive Plugins hingegen sind kein Laufzeitproblem. WordPress führt deren Code nicht aus, solange sie deaktiviert sind. Aber sie bleiben ein Sicherheitsrisiko, denn ihre Dateien liegen lesbar auf dem Server, erhalten keine Updates mehr und können bei einer Fehlkonfiguration des Servers oder durch eine andere Schwachstelle trotzdem zugänglich sein.

Warum ein aufgeblähter Plugin-Bestand schadet

Performance: mehr Code, mehr Requests

Plugins, die CSS und JavaScript laden, erhöhen die Zahl der HTTP-Requests und die zu übertragende Datenmenge. Das ist kein abstraktes Problem: Ein Formular-Plugin, das seine Styling-Bibliothek auf jeder Seite der Website lädt, auch dort, wo kein Formular steht, kostet unnötig Ladezeit. Gutes Caching kann das mildern, aber es löst das Grundproblem nicht. Die WordPress-Dokumentation empfiehlt ausdrücklich, Plugins selektiv zu deaktivieren und dabei die Server-Performance zu messen, um zu verstehen, welche Plugins tatsächlich bremsen.

Sicherheit: mehr Code, mehr Angriffsfläche

Laut dem State of WordPress Security Report 2025 von Patchstack, einem Anbieter von WordPress-Sicherheitslösungen, entfielen im Jahr 2024 auf Plugins 96 Prozent aller neu entdeckten Schwachstellen im WordPress-Ökosystem, auf Themes 4 Prozent, auf den WordPress Core lediglich 7 Einzellücken ohne nennenswerte Bedrohungsstufe. Insgesamt wurden 2024 knapp 8.000 neue Sicherheitslücken im WordPress-Ökosystem registriert. 33 Prozent davon wurden nicht vor der öffentlichen Offenlegung gepatcht, weil die Plugin-Entwickler nicht reagierten. 1.614 Plugins und Themes wurden deshalb aus dem offiziellen WordPress-Repository entfernt.

Was das praktisch bedeutet: Wer 40 Plugins betreibt, hat potenziell 40 Angriffsvektoren. Wer 12 betreibt, hat 12. Die Reduktion ist keine Garantie gegen Angriffe, aber sie verkleinert die Fläche, die ein Angreifer scannen und ausnutzen kann.

Inaktive Plugins sind dabei kein unbedenkliches Lager. Ihre PHP-Dateien liegen auf dem Server, erhalten keine Updates und können bei manchen Sicherheitskonfigurationen direkt aufgerufen werden.

Wartungsaufwand: mehr Plugins, mehr Updates

Jedes Plugin braucht Updates. Wer 40 Plugins betreibt, hat 40 Pakete, die er im Blick behalten muss. Updates sollten auf einer Staging-Umgebung getestet werden, bevor sie live gehen, denn ein schlecht getestetes Update kann andere Plugins blockieren oder die Website lahmlegen. Die Zeitinvestition wächst linear mit der Plugin-Zahl. Wer Plugins aussortiert, spart nicht nur Ladezeit, sondern echte Arbeit bei jedem zukünftigen Update.

Plugin-Audit: systematisch aussortieren

Der Audit läuft in vier Schritten.

Schritt 1: Bestand aufnehmen. Im WordPress-Backend unter Plugins steht die vollständige Liste aller installierten Erweiterungen, aktiv und inaktiv. Wer die Liste exportieren will, nutzt WP-CLI: wp plugin list --fields=name,status,version,update_version. Das gibt eine saubere Übersicht mit Update-Status, was besonders hilfreich ist, um veraltete Plugins auf einen Blick zu erkennen.

Schritt 2: Funktion klären. Für jedes Plugin die eine Frage: Welche konkrete Funktion erfüllt es, und wo auf der Website ist diese Funktion sichtbar? Wenn die Antwort lautet „weiß ich nicht mehr“ oder „haben wir mal ausprobiert“, ist das ein Hinweis. Inaktive Plugins, bei denen niemand den Zweck kennt, können ohne Risiko gelöscht werden. Nicht nur deaktiviert, sondern gelöscht, damit die Dateien vom Server verschwinden.

Schritt 3: Ersatz prüfen. Kann WordPress Core, das Theme oder ein kurzes PHP-Snippet die Funktion übernehmen? Viele Plugins lösen Aufgaben, für die moderne WordPress-Installationen seit Jahren eigene Bordmittel mitbringen. Dazu mehr im nächsten Abschnitt.

Schritt 4: Konflikte aufdecken. Wenn nach dem Audit unklar ist, welches Plugin eine Verlangsamung oder einen Fehler verursacht, hilft das selektive Deaktivieren: Plugins nacheinander ausschalten und jeweils die Ladezeit messen oder prüfen, ob das Problem verschwindet. Das ist kein bequemes Verfahren, aber das einzige, das sicher den Übeltäter findet.

Kriterien für gute Plugins

Nicht jedes Plugin ist verzichtbar, und nicht jedes Plugin, das einen Zweck erfüllt, ist auch gut gewählt. Die Qualitätsprüfung vor der Installation kostet fünf Minuten und spart im Zweifel Monate Ärger.

Ein Plugin, das mehrere dieser Kriterien schlecht erfüllt, ist kein Schnäppchen, sondern ein konkretes Sicherheitsrisiko. Ein ungepatchtes Plugin in einem Repository ist eine der häufigsten Einfallstüren für WordPress-Hacks. Wer bei der Auswahl sorgfältig ist, verschafft sich weniger Arbeit und weniger Angreifbarkeit.

Was Theme, Core und Snippets schon können

Viele Plugins wurden installiert, um Funktionen nachzurüsten, die inzwischen im WordPress Core stecken oder die ein modernes Theme direkt mitbringt. Bevor ein neues Plugin installiert wird, lohnt die Frage, ob das wirklich nötig ist.

WordPress Core kann von sich aus RSS-Feeds erzeugen, einfache Weiterleitungen per 301 über die Permalink-Einstellungen steuern, Bilder in WebP umwandeln (ab WordPress 5.8), Lazy Loading für Bilder setzen (ab WordPress 5.5), das SVG-Format in der Mediathek verwalten (ab WordPress 6.3 mit entsprechenden Einstellungen), REST-API-Endpunkte bereitstellen, Revision-Historien führen und benutzerdefinierte Felder (Custom Fields) speichern, ohne dass ein eigenes Plugin nötig ist.

Ein gutes Theme oder Block-Theme übernimmt die Typografie-Einstellungen, globale Farben und Spacing-Werte, das Navigationsmenü mit Dropdown-Unterstützung, einfache Grid-Layouts für Archivseiten, und in vielen Fällen auch Basic-Animationen und Hover-Effekte über CSS-Variablen.

Ein kurzes PHP-Snippet im mu-plugins-Verzeichnis ersetzt manche Plugins vollständig. Typische Beispiele: das Entfernen des WordPress-Versionsstempels aus dem HTML-Quelltext, das Deaktivieren von Kommentaren website-weit, das Anpassen des Login-Logos, das Einschränken von Datei-Upload-Typen oder das Hinzufügen von Custom-Post-Types in einfachen Fällen. Ein mu-plugin wird direkt geladen, ohne Datenbankeintrag, und bringt keinen eigenen Plugin-Overhead mit.

Die Grenze liegt dort, wo die Anforderungen zu komplex werden, als dass ein Snippet sie sauber abdecken kann. Woocommerce, komplexe Formulare mit Conditional Logic, Buchungssysteme oder Membership-Bereiche brauchen echte Plugins. Die Frage ist nicht „so wenige Plugins wie möglich“, sondern „kein Plugin, das ein einfacheres Werkzeug ersetzen kann“.

Profi-Sicht: Query-Monitor und Ladezeitmessung

Wer genauer wissen will, welches Plugin wieviel kostet, braucht Messwerte statt Schätzungen. Das Plugin Query Monitor zeigt im WordPress-Admin-Toolbar für jede aufgerufene Seite die Datenbankabfragen, die Ladezeit einzelner Hooks, den PHP-Speicherverbrauch und die von Plugins eingebundenen Assets. Damit lässt sich gezielt nachvollziehen, welches Plugin auf einer bestimmten Seite was ausführt und ob ein Asset global oder gezielt geladen wird.

Für externe Ladezeitmessung eignet sich Google PageSpeed Insights, der auf dem Lighthouse-Prüfrahmen basiert und konkrete Einsparpotenziale zu ungenutzten JavaScript- und CSS-Dateien ausgibt. Wer sieht, dass 60 Kilobyte CSS eingebunden werden, von denen auf der betreffenden Seite 5 Prozent genutzt werden, hat einen konkreten Kandidaten für die Audit-Liste.

Der Messablauf beim selektiven Plugin-Deaktivieren: Ladezeit dokumentieren, Plugin deaktivieren, Seite im Inkognito-Modus mit geleerten Caches laden, Ladezeit erneut messen. Wenn die Differenz unter einem Messrauschen liegt und keine Funktion fehlt, war das Plugin kein Gewinn. Wenn die Seite sichtbar schneller wird, hat man den Übeltäter gefunden.

Wer auf Performance-Optimierung im Detail einsteigen will, findet in unserem Ratgeber zur WordPress Speed-Optimierung die wirksamsten Maßnahmen in der Reihenfolge ihres Aufwand-Nutzen-Verhältnisses.

Aus der Praxis: 34 Plugins auf 11

In einem Projekt übernahmen wir eine WordPress-Website, die über fünf Jahre von verschiedenen Freelancern gepflegt worden war. Bei der Übernahme zählten wir 34 installierte Plugins, 12 davon inaktiv. Von den verbleibenden 22 aktiven erledigten vier Funktionen, die das eingesetzte Theme inzwischen selbst bot, zwei waren Duplikate desselben Zwecks in verschiedenen Versionen, und eines war das Überbleibsel einer Slider-Lösung aus 2019, die auf der Website schon längst nicht mehr eingesetzt wurde.

Nach dem Audit standen noch 11 aktive Plugins. Alle inaktiven Plugins wurden vollständig gelöscht. Das Ergebnis war ein messbarer Rückgang der Seitenaufbauzeit im Backend, vor allem weil zwei der entfernten Plugins bei jedem Admin-Seitenaufruf Datenbankabfragen gegen eine externe API stellten. Die Zahl der CSS-Dateien im Frontend sank von 18 auf 11. Wichtiger als die Ladezeit-Differenz war aber der Wartungsaufwand: statt 22 Pakete beim monatlichen Update zu prüfen, standen noch 11 auf der Liste.

Keine erfundenen Prozentzahlen zur Ladezeit, weil die von Website zu Website stark variieren. Was zutrifft: weniger Plugins bedeutet weniger Angriffsfläche, weniger Konflikte und weniger Update-Aufwand. Das ist keine Theorie, das ist Praxis.

Wer sicherstellen will, dass Updates nicht zur Stolperfalle werden, findet im Ratgeber zu WordPress Updates ohne Risiko, wie ein sicherer Update-Prozess mit Staging-Umgebung aussieht. Wer zudem sicherstellen will, dass im Ernstfall eine saubere Datensicherung bereitsteht, liest unseren Ratgeber zur WordPress-Backup-Strategie.

Plugin-Audit-Checkliste

• Vollständige Plugin-Liste exportiert (aktiv und inaktiv)?
• Für jedes Plugin den konkreten Zweck dokumentiert?
• Alle inaktiven Plugins vollständig gelöscht, nicht nur deaktiviert?
• Geprüft, ob Theme oder Core die Funktion bereits bereitstellt?
• Plugins auf letztes Update-Datum und aktive Installationen geprüft?
• Duplikate entfernt (gleiche Funktion, zwei verschiedene Plugins)?
• Ladezeit vor und nach dem Audit gemessen?
• Query Monitor oder vergleichbares Tool zur Diagnose eingesetzt?
• Alle verbleibenden Plugins auf aktuellster Version?
• Staging-Umgebung für Update-Tests vorhanden?

Häufige Fragen

Wie viele Plugins sind zu viele?

Eine feste Zahl gibt es nicht. Entscheidend ist nicht die Anzahl, sondern ob jedes Plugin eine klar definierte Aufgabe hat, die weder Core noch Theme übernehmen kann, und ob es aktiv gepflegt wird. Zehn schlecht gewählte Plugins sind schlechter als 20 sorgfältig geprüfte. Als grobe Orientierung: Wer mehr als 30 aktive Plugins betreibt, sollte konkret prüfen, ob Duplikate oder Funktionen mit Bordmitteln dabei sind.

Sind inaktive Plugins ein Sicherheitsrisiko?

Ja. Inaktive Plugins werden von WordPress nicht ausgeführt, aber ihre Dateien liegen auf dem Server. Sie erhalten in der Regel keine Updates mehr, weil Betreiber sie vergessen. Je nach Server-Konfiguration können ihre Dateien direkt aufgerufen werden. Der sichere Schritt ist das vollständige Löschen, nicht nur das Deaktivieren.

Kann ein Plugin-Audit die Website kaputtmachen?

Das Deaktivieren eines Plugins auf Produktiv kann eine Funktion entfernen, die noch gebraucht wird. Deshalb sollte ein Audit zuerst auf einer Staging-Kopie durchgeführt werden. Auf der Staging-Umgebung Plugins deaktivieren, Seiten prüfen, und erst dann die verifizierten Änderungen auf die Live-Website übertragen.

Wie finde ich heraus, welches Plugin meine Website verlangsamt?

Der direkteste Weg ist das selektive Deaktivieren mit Ladezeitmessung: Plugins nacheinander ausschalten, Seite cachebereinigt laden, Ladezeit vergleichen. Für eine schnellere Diagnose zeigt das Plugin Query Monitor im Admin-Panel, welche Hooks und Datenbankabfragen von welchem Plugin ausgelöst werden.

Sollte ich Plugins kaufen statt kostenlose zu nutzen?

Nicht automatisch. Die Unterscheidung ist nicht kostenlos gegen kostenpflichtig, sondern gepflegt gegen vernachlässigt. Es gibt exzellente kostenlose Plugins mit langer Update-Geschichte und zuverlässigem Support, und es gibt kostenpflichtige Plugins, die ihren Preis nicht rechtfertigen. Die Qualitätskriterien gelten unabhängig vom Preis.

Was ist mit Plugins, die nur einmal gebraucht wurden, zum Beispiel für eine Migration?

Diese Kategorie ist besonders häufig. Nach einer Migration, einem Import oder einer Einmal-Anpassung bleibt das Plugin installiert und gerät in Vergessenheit. Diese Plugins sollten nach dem Einsatz sofort deinstalliert werden, nicht nur deaktiviert. Wer das vergessen hat, löscht sie beim nächsten Audit.

Die laufende Pflege Ihrer WordPress-Website, mit regelmäßigem Plugin-Audit, Updates und Sicherheitscheck, ist Teil eines professionellen Betreuungsvertrags. Wer das nicht intern abdecken kann oder will, lagert es ab und stellt sicher, dass es gemacht wird.