Lass uns zusammen starten
Von der Idee zur Umsetzung – gemeinsam, effizient, individuell.
Einleitung
„Weniger Plugins“ ist schnell gesagt – und wird oft als Universal-Lösung für Performance, Stabilität und Sicherheit verkauft. In realen WordPress-Projekten führt dieser Ansatz jedoch häufig zu Frust: Funktionen fehlen, der Aufwand steigt – und die Messwerte bleiben trotzdem gleich.
In diesem Artikel geht es nicht darum zu sagen: Plugins sind immer schlecht oder Plugins sind immer gut. Sondern darum zu zeigen, warum „weniger“ in vielen Fällen nicht der beste erste Hebel ist – und was stattdessen deutlich mehr bringt.
Der Tipp
„Deaktiviere ein paar Plugins, dann wird die Seite schneller.“
Warum das plausibel klingt
Mehr Plugins wirken wie mehr Code – und mehr Code wirkt wie mehr Ladezeit. Zusätzlich gibt es echte Fälle, in denen Plugins unsauber programmiert sind, zu Konflikten führen oder unnötig viele Assets laden. Deshalb hat sich der Tipp „weniger Plugins“ so festgesetzt.
Das Problem: Er ist zu pauschal. Er hilft selten dabei zu erkennen, welches Plugin konkret bremst – und warum.
Hinweis aus der Praxis
Natürlich kann ein „Plugin-Zoo“ Probleme verursachen. Und manchmal ist Ausmisten genau richtig. Aber oft ist die bessere Frage nicht „Wie viele Plugins?“, sondern: Welche Assets werden wann und wo geladen?
Was wirklich passiert ist
- PageSpeed/LCP haben sich kaum verbessert
- Funktionen fehlten (oder mussten nachgebaut werden)
- Interne Abläufe wurden komplizierter („Wo ist Feature X hin?“)
- Neue Fehler durch Ersatzlösungen / Workarounds
Am Ende war die Seite nicht wirklich schneller – aber weniger komfortabel zu betreiben.
Warum das so ist
Für Performance ist selten entscheidend, wie viele Plugins installiert sind, sondern wie sich einzelne Plugins verhalten:
- Globales Laden: CSS/JS wird auf jeder Seite geladen, obwohl es nur auf einer Unterseite gebraucht wird
- Render-Blocking: Assets liegen im Head und blockieren den ersten Paint
- Third-Party: Cookie-Banner, Fonts oder Tracking dominieren die Ladezeit
- Doppelte Features: Theme + Builder + Plugin laden ähnliche Komponenten mehrfach
Deshalb kann eine Website mit 5 „schweren“ Plugins langsamer sein als eine mit 25 „sauberen“ Plugins. Die Anzahl ist kein verlässlicher Indikator.
Was stattdessen geholfen hat
- „Was bremst wirklich?“ messen statt raten
PageSpeed/DevTools nutzen, um LCP-Element und render-blocking Ressourcen zu identifizieren - Problem-Plugins finden (nicht „irgendwelche“)
Häufige Kandidaten: Cookie-Banner, Slider, externe Fonts, Tracking, schwere Builder-Widgets - Assets gezielt begrenzen
CSS/JS nur dort laden, wo es gebraucht wird (statt global) - Doppelte Funktionen vermeiden
Nicht 3 Komponenten für das gleiche Ziel (Slider + Theme-Slider + Gallery-Plugin) - Erst dann ausmisten
Wenn klar ist, was ersetzt werden kann – ohne Wartungsaufwand zu erhöhen
Das Ergebnis: spürbare Verbesserungen bei LCP/Startzeit – ohne dass die Website in Funktionen „auseinanderfällt“.
Kurzfazit
- Die Plugin-Anzahl ist kein verlässlicher Performance-Indikator.
- Entscheidend ist, welche CSS/JS/Third-Party-Assets wann geladen werden.
- Gezieltes Asset-Management bringt meist mehr als pauschales Ausmisten.
„Weniger Plugins“ ist kein Allheilmittel – wichtiger ist, wie Plugins laden.
FAQ
Nein. Entscheidend ist die Qualität und das Ladeverhalten. Viele saubere Plugins können unproblematisch sein, während ein einzelnes Plugin mit globalen Assets oder Third-Party-Skripten stark bremsen kann.
Oft sind es Cookie-Banner, Slider, externe Fonts/Tracking und Plugins, die CSS/JS auf allen Seiten laden, obwohl sie nur punktuell genutzt werden.
Messen statt raten: LCP-Element und render-blocking Ressourcen identifizieren und dann gezielt die wirklich schweren Assets reduzieren oder Ladeorte einschränken.
