WordPress Plugins reduzieren – das ist der Ratschlag, den ich am häufigsten gebe und der am seltensten befolgt wird. Dabei ist der Zusammenhang eindeutig: Fast jede langsame, fehleranfällige WordPress-Website, die bei mir auf dem Tisch landet, hat dasselbe Grundproblem – 35, 40, manchmal 50 aktive Plugins, von denen die Hälfte niemand mehr zuordnen kann. Für jedes einzelne davon zahlen Sie einen Preis, auch wenn es kostenlos war.
In diesem Artikel rechne ich vor, was Plugins wirklich kosten, zeige mein Vorgehen beim Plugin-Audit und liste konkret auf, welche typischen Plugins sich durch wenige Zeilen Code oder WordPress-Bordmittel ersetzen lassen – und wann ein Plugin die richtige Entscheidung bleibt.
Was Sie für jedes Plugin wirklich bezahlen
Ein Plugin kostet selten Geld, aber immer Ressourcen. Die Währung heißt Geschwindigkeit, Sicherheit, Stabilität und Wartungsaufwand.
Geschwindigkeit
Jedes aktive Plugin wird bei jedem einzelnen Seitenaufruf geladen – auch dann, wenn seine Funktion auf der Seite gar nicht gebraucht wird. Das klassische Beispiel: Ein Formular-Plugin lädt sein CSS und JavaScript auf allen 200 Seiten der Website, obwohl das Formular nur auf der Kontaktseite steht. Dazu kommen Datenbank-Optionen mit Autoload-Flag, eigene Cronjobs und zusätzliche Abfragen. In Query-Monitor-Messungen sehe ich regelmäßig einzelne Plugins, die 100 bis 300 Millisekunden Serverzeit pro Aufruf verbrauchen. Zehn solcher Kandidaten, und Ihre Website fühlt sich zäh an, bevor das erste Bild geladen ist. Warum das so stark auf die gefühlte Geschwindigkeit durchschlägt, habe ich im Artikel warum Ihre Website langsam ist und was wirklich hilft ausführlich beschrieben.
Sicherheit
Laut den jährlichen Auswertungen von Patchstack entfallen über 90 Prozent aller neu gemeldeten WordPress-Sicherheitslücken auf Plugins – nicht auf den WordPress-Kern. Jedes Plugin ist fremder Code mit denselben Rechten wie WordPress selbst. Besonders kritisch sind verwaiste Plugins, deren Entwickler keine Updates mehr liefern: Eine bekannte Lücke bleibt dann dauerhaft offen. Meine Faustregel: Ein Plugin, das seit über einem Jahr kein Update gesehen hat und weniger als 10.000 aktive Installationen zählt, ist ein Risikokandidat.
Konflikte und Update-Risiko
Plugins wissen nichts voneinander. Zwei Caching-Plugins, zwei SEO-Plugins oder ein Page-Builder plus ein Optimierungs-Plugin, das dessen Skripte zerlegt – solche Kombinationen produzieren die berüchtigten weißen Seiten nach Updates. Je mehr Plugins, desto mehr mögliche Wechselwirkungen: Bei 40 Plugins sind es rein rechnerisch 780 Paarungen, die sich in die Quere kommen können. Kein Entwickler dieser Welt testet das durch.
Wartungsaufwand
Jedes Plugin will aktualisiert werden – im Schnitt alle paar Wochen. Bei 40 Plugins bedeutet das im Jahr mehrere hundert Updates, von denen jedes einzelne etwas kaputt machen kann. Wer Updates deshalb aufschiebt, tauscht das Stabilitätsrisiko gegen ein Sicherheitsrisiko. Warum regelmäßige Pflege trotzdem alternativlos ist, erkläre ich im Beitrag zur WordPress-Wartung und warum sie unverzichtbar ist.
Datenbank und Backend
Weniger sichtbar, aber genauso real: Viele Plugins schreiben Optionen mit Autoload-Flag in die Datenbank, die bei jedem Seitenaufruf komplett geladen werden – auch die des längst gelöschten Sliders von 2019. Dazu kommen eigene Tabellen, Transients und Logdaten, die nie aufgeräumt werden. Ich habe wp_options-Tabellen mit über 20 Megabyte Autoload-Daten gesehen; da schleppt der Server bei jedem Aufruf Ballast mit. Und im Backend summiert sich das ebenfalls: Jedes Plugin lädt seine Admin-Skripte, Hinweisbanner und Dashboard-Widgets – die Redaktion spürt das bei jedem Klick.
Plugin-Audit: So gehe ich vor
Ein Plugin-Audit ist keine Raketenwissenschaft, braucht aber System. Mein Ablauf in Kundenprojekten:
- Inventur: Alle Plugins in eine Liste – mit Zweck, letztem Update des Entwicklers, Anzahl aktiver Installationen und der Frage: Wer im Team weiß, wofür das da ist? Bei erstaunlich vielen lautet die Antwort: niemand.
- Messen: Mit Query Monitor und einem Profiling-Tool wie Code Profiler messe ich, welche Plugins bei Ladezeit und Datenbankabfragen am meisten kosten. Das Ergebnis überrascht fast immer – oft sind zwei, drei Plugins für den Großteil der Serverzeit verantwortlich.
- Kategorisieren: Jedes Plugin landet in einer von drei Spalten: behalten (löst ein echtes Problem, wird gepflegt), ersetzen (geht schlanker mit Code oder Bordmitteln), löschen (Funktion wird nicht mehr gebraucht oder ist doppelt vorhanden).
- Testen: Auf einer Staging-Umgebung deaktiviere ich die Kandidaten schrittweise und prüfe die Kernfunktionen. Nie auf der Live-Seite, nie alle auf einmal.
Wichtig: Deaktivierte Plugins gehören gelöscht, nicht nur abgeschaltet. Auch inaktive Plugins liegen auf dem Server und können über bekannte Lücken angreifbar bleiben.
Und wie oft? Einmal im Jahr als festes Ritual – und zusätzlich immer dann, wenn die Website den Besitzer wechselt, ein Relaunch ansteht oder die Ladezeit spürbar kippt. Ein Audit auf einer Website mit 20 Plugins dauert bei mir zwei bis drei Stunden. Das ist überschaubar im Vergleich zu den Tagen, die eine gehackte oder durch ein Update zerlegte Website kostet.
Was sich durch Code oder Bordmittel ersetzen lässt
Viele Plugins lösen Probleme, die WordPress inzwischen selbst löst – oder die mit wenigen Zeilen im Child-Theme erledigt sind. Die häufigsten Kandidaten aus meinen Audits:
| Plugin-Typ | Typischer Vertreter | Schlanke Alternative |
|---|---|---|
| Slider auf der Startseite | Slider Revolution, MetaSlider | Statisches Bild mit klarer Botschaft – besser für LCP und Konversion |
| Code-Snippets | Code Snippets, WPCode | functions.php im Child-Theme oder ein kleines eigenes Plugin |
| Weiterleitungen | Redirection | Redirects direkt in der Serverkonfiguration (.htaccess, nginx) |
| Google Fonts | Fonts-Plugins | Schriften lokal im Theme einbinden – schneller und DSGVO-konform |
| Analytics-Einbindung | Diverse Tracking-Plugins | Snippet direkt im Theme oder per Tag Manager |
| Duplizieren von Beiträgen | Duplicate Post | Block-Editor: Alle Blöcke kopieren, oder eine 20-Zeilen-Funktion |
| Kontaktformular mit Zusatzmodulen | Contact Form 7 plus vier Add-ons | Ein schlankes Formular-Plugin ohne Add-on-Zoo oder ein maßgeschneidertes Formular |
Die Ersetzung durch eigenen Code lohnt sich vor allem dort, wo ein Plugin mit 5.000 Zeilen genau eine Funktion erfüllt, die sich in 20 Zeilen abbilden lässt. Solche gezielten Eingriffe gehören für mich zur normalen professionellen Webentwicklung – sauber versioniert im Child-Theme oder als kleines Site-Plugin, damit sie Updates überleben.
Wann ein Plugin die richtige Wahl ist
Damit kein falscher Eindruck entsteht: Plugins sind nicht das Problem – wahllose Plugins sind es. Es gibt Aufgaben, bei denen Eigenbau fahrlässig wäre. WooCommerce, mehrsprachige Setups mit Polylang oder WPML, Backups, komplexe Formulare mit Bezahlfunktion, Spam-Abwehr: Das sind gereifte Lösungen mit jahrelanger Entwicklung, Sicherheitsaudits und großer Nutzerbasis. So etwas baut man nicht nach.
Meine Kriterien, bevor ein neues Plugin auf eine Kundenseite darf:
- Löst es ein Problem, das wir wirklich haben – oder nur ein Problem, das wir haben könnten?
- Wird es aktiv gepflegt? Letztes Update, Kompatibilität mit der aktuellen WordPress-Version, Changelog.
- Hat es eine relevante Nutzerbasis und einen erreichbaren Support?
- Was kostet es zur Laufzeit? Vorher auf Staging installieren und mit Query Monitor messen.
- Gibt es die Funktion schon – im Kern, im Theme oder in einem vorhandenen Plugin?
Der letzte Punkt wird am häufigsten übersehen. Funktionsüberschneidungen sind der Normalfall: Das SEO-Plugin bringt schon eine Sitemap mit, das Caching-Plugin optimiert schon Bilder, das Theme hat schon Icons an Bord.
Bei Premium-Plugins kommt eine wirtschaftliche Dimension dazu: Eine Jahreslizenz von 50 bis 100 Euro ist gut investiert, wenn sie einen gepflegten, supporteten Baustein kauft – und schlecht, wenn sie nur ein Feature abdeckt, das im Theme längst steckt. Rechnen Sie ehrlich: Was kostet das Plugin über fünf Jahre, was würde die maßgeschneiderte Lösung kosten, und wer pflegt beides?
Was das Ausmisten konkret bringt
Ein Beispiel aus der Praxis: Eine Firmenwebsite kam mit 38 aktiven Plugins zu mir, Ladezeit der Startseite über vier Sekunden, der Admin-Bereich quälend langsam. Nach dem Audit blieben 16 Plugins übrig. Ergebnis: Serverantwortzeit von rund 1,2 Sekunden auf unter 400 Millisekunden, Startseite unter zwei Sekunden, und die Redaktion arbeitet wieder gern im Backend. Kein Caching-Trick, keine neue Hardware – nur weniger Ballast.
Dazu kommt der stille Gewinn: weniger Updates, weniger Konfliktpotenzial, kleinere Angriffsfläche, übersichtlichere Datenbank. Eine Website mit 15 kuratierten Plugins ist über Jahre günstiger im Betrieb als eine mit 40 zufälligen.
Ein zweiter Effekt zeigt sich direkt in den Core Web Vitals: Weniger eingebundene Skripte und Stylesheets bedeuten weniger Render-Blocking, bessere LCP-Werte und stabilere Interaktionszeiten. Google misst das über echte Nutzerdaten – und Ihre Besucher spüren es lange vorher.
Checkliste für Ihr Plugin-Audit
- Vollständige Plugin-Liste mit Zweck und Verantwortlichem erstellen
- Letztes Entwickler-Update und aktive Installationen jedes Plugins prüfen
- Ladezeit-Kosten mit Query Monitor auf Staging messen
- Doppelte Funktionen identifizieren (Sitemap, Bildoptimierung, Icons, Schriften)
- Jedes Plugin kategorisieren: behalten, ersetzen, löschen
- Ersatz durch Bordmittel oder Code für Kleinst-Plugins umsetzen
- Deaktivierte Plugins vollständig löschen, inklusive Datenbankreste
- Ergebnis dokumentieren und das Audit jährlich wiederholen
Fazit
Jedes Plugin ist ein Mitbewohner in Ihrem WordPress: Es verbraucht Ressourcen, will versorgt werden und kann Ärger machen. Die besten Websites, die ich betreue, kommen mit 10 bis 20 sorgfältig ausgewählten Plugins aus – nicht, weil Askese ein Wert an sich wäre, sondern weil jede einzelne Komponente begründet ist. WordPress Plugins reduzieren heißt nicht verzichten, sondern bewusst entscheiden.
Wenn Sie den Verdacht haben, dass Ihre Website mehr Ballast trägt als nötig: Ich führe Plugin-Audits als Teil meiner Website-Betreuung durch – melden Sie sich, und wir schauen gemeinsam, was Ihre Website wirklich braucht.
