Zu viele Plugins: warum jedes einzelne dreifach kostet

Zu viele Plugins sind nicht an einer Zahl zu erkennen, sondern daran, dass Plugins da sind, die keiner mehr braucht, doppelt arbeiten oder nicht mehr gepflegt werden. Jedes davon kostet dreifach: Es lädt Dateien, die die Seite langsamer machen, es bringt fremden Code mit, der eine Sicherheitslücke haben kann, und es muss bei jeder Aktualisierung mitgeprüft werden. Deshalb ist die Plugin-Liste die eine Stelle, an der ein einziger Schritt — ein Plugin löschen — drei Probleme zugleich kleiner macht. Deaktivieren reicht dafür nicht.

Was die Plugin-Liste erzählt

Die Plugin-Liste im Backend ist oft die aufschlussreichste Seite einer Website. Sie erzählt ihre Geschichte: Hier wurde mal ein Slider gebraucht. Da hat jemand ein zweites Formular-Plugin installiert, weil das erste nicht ging. Dort liegt eine Erweiterung für ein Theme, das seit Jahren nicht mehr in Betrieb ist.

Jede dieser Altlasten ist nicht nur Ballast, sondern Ladezeit, Angriffsfläche und Wartungsaufwand. Die drei Kosten im Einzelnen:

Kosten 1: Ladezeit

Viele Plugins bringen eigene Stil- und Skriptdateien mit — und laden sie auf jeder Seite, nicht nur dort, wo ihre Funktion vorkommt. Das Formular-Plugin lädt auf der Startseite, das Slider-Plugin auf der Kontaktseite.

Das ist kein Schönheitsfehler. Googles Prüfwerkzeug Lighthouse beschreibt, was solche Dateien kosten:

• Ein Skript, das im Kopf der Seite ohne defer oder async eingebunden ist, und jede normale Stildatei blockieren die erste Darstellung der Seite.
• Bei einem blockierenden Skript muss der Browser es erst herunterladen, einlesen, übersetzen und ausführen, bevor er weitermachen kann.
• Auch nachrangig geladener Code konkurriert beim Herunterladen um die Bandbreite — und verbraucht auf dem Handy Datenvolumen.

Für WordPress gibt Lighthouse einen einzigen, bemerkenswert direkten Rat: die Zahl der Plugins verringern oder austauschen, die ungenutztes JavaScript in die Seite laden.

Das WordPress-Handbuch für Plugin-Entwickler sagt dasselbe von der anderen Seite: Skripte sollen nur auf den Seiten eingebunden werden, auf denen sie gebraucht werden. Wo ein Plugin das nicht tut, ist Entfernen der wirksamste Schritt — wirksamer als jedes Optimierungs-Plugin, das die Dateien danach zusammenfasst oder verschiebt.

Kosten 2: Sicherheit

WordPress selbst ist selten das Problem. Patchstack, ein Anbieter für WordPress-Sicherheit, zählt in seinem Bericht „State of WordPress Security in 2026" für das Jahr 2025:

Kennzahl	Wert
neue Schwachstellen im WordPress-Umfeld	11.334 (42 Prozent mehr als 2024)
davon in Plugins	91 Prozent
davon in Themes	9 Prozent
im WordPress-Kern	6, alle mit geringem Risiko
ohne Korrektur des Herstellers zum Zeitpunkt der Veröffentlichung	46 Prozent

Die Angriffsfläche einer WordPress-Website sind also fast vollständig ihre Plugins. Das WordPress-Handbuch für Entwickler nennt Plugins und Themes selbst die wesentlichen Schwachstellen des Systems.

Und es geht schnell. Bei den massenhaft angegriffenen Lücken lag der Median bis zur ersten massenhaften Ausnutzung laut Patchstack bei fünf Stunden; rund die Hälfte der Lücken mit hoher Auswirkung wurde innerhalb von 24 Stunden ausgenutzt. Wer einmal im Monat aktualisiert, ist bei einer neuen Lücke also nicht Stunden, sondern Wochen offen. Jedes Plugin weniger ist eine Stelle weniger, an der das passieren kann.

Deaktiviert ist nicht gelöscht

Ein Plugin, das nichts tut, ist nicht harmlos. Ein deaktiviertes Plugin liegt mit allen seinen Dateien weiter auf dem Server, und manche Schwachstellen lassen sich über diese Dateien auch dann ausnutzen. Die Sicherheitsanleitung von WordPress.org ist entsprechend knapp: Plugins aktuell halten, und ein Plugin, das du nicht benutzt, löschen.

Kosten 3: Wartung

Jedes Plugin muss aktualisiert werden, jede Aktualisierung kann etwas kaputtmachen, jede will geprüft werden. Zwanzig Plugins sind zwanzig mögliche Konflikte bei jedem WordPress-Update — und zwanzig Änderungsprotokolle, die jemand lesen sollte.

Dazu kommt, was Plugins in der Datenbank hinterlassen. WordPress lädt bei jedem Seitenaufruf einen Teil der gespeicherten Einstellungen in einem Rutsch, die sogenannten automatisch geladenen Optionen. Seit Version 6.6 meldet der Website-Zustand im Backend ein kritisches Problem, wenn diese zusammen mehr als 800 KB groß sind. Ein häufiger Grund: Plugins, die Einstellungen angelegt und beim Entfernen nicht wieder aufgeräumt haben.

Ob aufgeräumt wird, hängt am Plugin. Das Plugin-Handbuch unterscheidet klar: Beim Deaktivieren sollen nur Zwischenspeicher geleert werden, erst beim Löschen über das Backend sollen Einstellungen und Tabellen entfernt werden — sofern der Entwickler das vorgesehen hat.

Wie viele sind zu viele?

Es gibt keine Zahl, die für alle gilt. Ein Shop braucht mehr als eine Visitenkartenseite, und eine feste Obergrenze lässt sich nicht belegen. Brauchbarer sind vier Grundsätze:

• Ein Plugin pro Aufgabe. Zwei Formular-, zwei Cache- oder zwei SEO-Plugins sind fast immer ein Zeichen, dass mal etwas nicht funktioniert hat und niemand aufgeräumt hat. Doppelte Plugins arbeiten oft gegeneinander.
• Kein Plugin für zehn Zeilen. Eine Weiterleitung, ein zusätzliches Feld, ein abgeschaltetes Standardverhalten lassen sich oft mit ein paar Zeilen Code lösen.
• Kein Plugin für Gestaltung. Was nur dafür da ist, dass etwas anders aussieht, gehört ins Theme oder ins CSS.
• Keine Alleskönner-Sammlungen, von denen du zwei Funktionen nutzt. Sie laden den Rest meist trotzdem mit.

Die ehrliche Regel lautet: Jedes Plugin muss begründen können, warum es da ist.

Der Kassensturz: drei Fragen je Plugin

1. Wird es noch gebraucht? Wenn du nicht sagen kannst, was es tut, ist das schon eine Antwort. Häufige Kandidaten: Slider einer alten Startseite, Wartungsmodus-Plugins nach dem Start, Import-Werkzeuge nach dem Umzug, Erweiterungen für ein abgelöstes Theme, Statistik-Plugins, in die nie jemand schaut, ein altes Cache-Plugin neben dem aktuellen.

2. Wird es gepflegt? Auf der Plugin-Seite bei WordPress.org stehen die Zahl der aktiven Installationen und das Datum der letzten Aktualisierung. Deutlicher wird WordPress.org selbst, wenn ein Plugin zurückfällt: Dann steht dort der Hinweis, das Plugin sei mit den letzten drei Hauptversionen von WordPress nicht getestet worden und werde womöglich nicht mehr gepflegt. Ein Plugin mit diesem Hinweis gehört auf die Ersatzliste, egal wie gut es beschrieben ist.

3. Gibt es einen leichteren Weg? Manchmal kann das Theme oder ein bereits vorhandenes Plugin dasselbe. Manchmal löst eine Einstellung das Problem.

Die praktische Warnung dazu: Vor dem Aufräumen ein Backup. Und einzeln vorgehen, nicht fünf auf einmal — sonst weißt du nicht, welches Entfernen etwas kaputtgemacht hat.

Was meistens bleibt

Die Plugins, die auf fast jeder Website eine echte Aufgabe erfüllen:

• Backup. Nicht verhandelbar.
• Sicherheit mit Überwachung auf bekannte Schwachstellen.
• Cache, sofern der Hoster das nicht selbst macht.
• SEO, wenn du Titel und Beschreibungen pflegst.
• Formular, sofern das Theme keins mitbringt.
• Bildoptimierung beim Hochladen.
• Je nach Betrieb: Einwilligungsverwaltung, Terminbuchung, Mehrsprachigkeit.

Alles darüber hinaus sollte eine Begründung haben.

Die Lücke zwischen zwei Aktualisierungen

Die fünf Stunden erzeugen ein Problem, das Sorgfalt allein nicht löst: Selbst wer täglich aktualisiert, ist zwischen Bekanntwerden einer Lücke und dem Erscheinen der Korrektur ungeschützt. Und bei 46 Prozent der Fälle gab es zum Zeitpunkt der Veröffentlichung noch gar keine Korrektur.

Die übliche Antwort heißt virtuelles Patchen: Ein Sicherheitsanbieter verteilt eine Regel, die das Angriffsmuster blockiert, bevor das Plugin selbst korrigiert ist. Patchstack gibt an, solche Regeln im Moment der Veröffentlichung einer Lücke auszurollen — das ist die Aussage eines Anbieters, der diesen Dienst verkauft, aber sie beschreibt das Prinzip.

Für eine kleine Visitenkartenseite ist das oft mehr, als nötig ist. Für einen Betrieb, dessen Website Anfragen erzeugt oder Bestellungen entgegennimmt, ist es die naheliegende Antwort auf ein Zeitproblem, das sich durch schnelleres Handeln nicht lösen lässt. Das beste Mittel bleibt trotzdem das einfachste: Ein Plugin, das nicht installiert ist, braucht keinen Schutz.

Wie du das selbst prüfst

• Die Plugin-Liste durchgehen. Bei jedem: Weißt du, was es tut? Wann wurde es zuletzt aktualisiert?
• Deaktivierte Plugins suchen. Jedes davon gehört gelöscht, nicht deaktiviert.
• Den Netzwerk-Reiter auf einer einfachen Seite öffnen. Nimm die Impressumsseite — eine Seite ohne Funktionen — öffne mit F12 die Entwicklerwerkzeuge und lade sie im Reiter „Netzwerk" neu. Jede Skript- und Stildatei aus wp-content/plugins/, deren Funktion auf dieser Seite gar nicht vorkommt, ist unnötige Last. Das ist der überzeugendste Test, weil man sofort sieht, wie viel geladen wird, das nichts tut.
• Lighthouse laufen lassen. In denselben Entwicklerwerkzeugen zeigt der Reiter „Lighthouse" ungenutztes JavaScript und blockierende Dateien — mit dem Pfad, aus welchem Plugin sie kommen.
• Nach doppelten Aufgaben suchen. Zwei Cache-, zwei SEO-, zwei Formular-Plugins.
• Den Website-Zustand öffnen (Werkzeuge → Website-Zustand) und nachsehen, ob die automatisch geladenen Optionen angemahnt werden.

Was zu tun ist

1. Backup, dann aufräumen. Einzeln, mit Prüfung nach jedem Schritt.
2. Deaktivierte zuerst löschen. Das ist Fortschritt fast ohne Risiko.
3. Doppelte auflösen. Entscheide dich für eins.
4. Ungepflegte ersetzen. Für fast jedes verwaiste Plugin gibt es eine gepflegte Alternative. Der Wechsel ist einmal Arbeit und danach Ruhe.
5. Über das Backend löschen, nicht per Dateizugriff — nur dann kann ein Plugin seine Einstellungen und Tabellen selbst entfernen.
6. Das Plugin-Inventar in die regelmäßige Wartung aufnehmen. Einmal im Quartal die Liste durchgehen und fragen, ob noch jedes gebraucht wird.
7. Vor jeder Neuinstallation drei Fragen: Brauche ich das wirklich? Wird es gepflegt? Habe ich ein Backup?

Die Plugin-Liste ist die Stelle, an der drei Probleme gleichzeitig kleiner werden. Jedes entfernte Plugin macht die Seite schneller, verkleinert die Angriffsfläche und spart Wartung.

Quellen

• Patchstack, State of WordPress Security in 2026 — 11.334 Schwachstellen 2025, plus 42 Prozent, 91 Prozent Plugins, 9 Prozent Themes, 6 im Kern, 46 Prozent ohne Korrektur, Median fünf Stunden, rund die Hälfte binnen 24 Stunden, Schutzregeln bei Veröffentlichung: patchstack.com
• WordPress.org, Hardening WordPress — Plugins aktuell halten, ungenutzte Plugins löschen: developer.wordpress.org
• WordPress.org, Common APIs Handbook: Security — Plugins und Themes als wesentliche Schwachstellen: developer.wordpress.org
• DreamHost, Abandoned WordPress Plugins — Dateien deaktivierter Plugins bleiben auf dem Server und können ausgenutzt werden: dreamhost.com
• Chrome for Developers, Lighthouse: Reduce unused JavaScript — Kosten ungenutzten Codes, Rat zu WordPress-Plugins: developer.chrome.com
• Chrome for Developers, Lighthouse: Eliminate render-blocking resources — blockierende Skripte und Stildateien: developer.chrome.com
• WordPress.org, Plugin Handbook: Enqueuing — Skripte nur dort einbinden, wo sie gebraucht werden: developer.wordpress.org
• WordPress.org, Plugin Handbook: Uninstall Methods — Deaktivieren gegenüber Löschen, Aufräumen von Einstellungen und Tabellen: developer.wordpress.org
• Make WordPress Core, Options API: Disabling autoload for large options — Prüfung im Website-Zustand ab 800 KB seit WordPress 6.6: make.wordpress.org
• WordPress.org Support-Forum — Wortlaut des Hinweises „not tested with the latest 3 major releases": wordpress.org