Wie viele WordPress-Plugins sind zu viele? Wir haben 50 installiert und gemessen

Das Ergebnis

Wir haben die 50 beliebtesten Plugins aus dem WordPress-Verzeichnis in derselben Elementor-Seite aktiviert: erst 10, dann 25, dann alle 50. Gemessen haben wir die Zeit, die der Server zum Bauen der Seite braucht, einmal für die Startseite (Besucher) und einmal für das Dashboard (angemeldet). Dazu kamen Lighthouse-Messungen mobil und am Desktop.

Auffällig: Die ersten 10 Plugins kosteten mehr als die nächsten 15 zusammen. Das liegt nicht an der Zahl 10, sondern daran, was darin steckt. Unter den ersten zehn sind WooCommerce, Yoast SEO, WPForms und Site Kit, also vier der schwersten Plugins im ganzen Test.

Bei den Besuchern kam davon weniger an, als die Serverzeit vermuten lässt. Die Wartezeit auf das erste Byte stieg in Lighthouse mobil von 0,66 auf 1,35 Sekunden und der Speed Index von 2,5 auf 4,3 Sekunden. Die Ladezeit des größten Elements (LCP) stieg nur von 4,54 auf 4,83 Sekunden. Die Seite wurde 166 KB schwerer und brauchte 46 Anfragen mehr, weil manche Plugins auch auf Seiten, die sie gar nicht nutzen, eigene Skripte und Styles laden. Menü, Slider, Akkordeon, Formular und Popup funktionierten in jeder Stufe.

Anzahl gegen Gewicht

Um die Frage sauber zu klären, haben wir in einer eigenen Messreihe drei Varianten direkt nacheinander gemessen: die Grundausstattung, die Grundausstattung plus nur WooCommerce und die Grundausstattung plus die 25 Plugins von Platz 26 bis 50.

Auf der Startseite war es praktisch ein Unentschieden: 419 ms mit WooCommerce allein, 424 ms mit 25 anderen Plugins. Auch der Arbeitsspeicher war fast gleich (124 gegen 126 MB). Ein einziges großes Plugin kann also so viel kosten wie zwei Dutzend kleine.

Im Dashboard lagen die 25 Plugins vorne (554 gegen 448 ms). Dort hat die Anzahl mehr Gewicht, denn fast jedes Plugin hängt sich mit eigenen Menüpunkten, Hinweisen und Prüfungen ins Backend.

Die schwersten Plugins

Danach haben wir jedes der 50 Plugins einzeln aktiviert und 20-mal gemessen. Alle fünf Plugins kam eine neue Messung der Grundausstattung dazwischen, damit Schwankungen des Servers nicht als Plugin-Kosten durchgehen.

Was die schweren Plugins gemeinsam haben: Sie bringen viel Code mit und laden ihn bei jedem Aufruf, egal ob die Seite ihn braucht. WooCommerce lädt den ganzen Shop auch auf einer Seite ohne Produkte. Die Addon-Pakete für Elementor und Gutenberg registrieren Dutzende Widgets. Yoast macht kaum Datenbankabfragen, braucht aber 12 MB Arbeitsspeicher für seinen Code.

Am anderen Ende stehen 25 der 50 Plugins, die einzeln weniger als 10 ms kosteten. Das ist weniger, als der Server von Messung zu Messung ohnehin schwankt. Dazu gehören zum Beispiel Classic Editor, Duplicate Page, Regenerate Thumbnails, Better Search Replace, Safe SVG, Flamingo, UpdraftPlus und Mailchimp for WP.

Und die Kosten addieren sich ziemlich ehrlich: Einzeln zusammengezählt kamen die 50 Plugins auf 886 ms, gemeinsam aktiv auf rund 800 ms. Es gibt also keinen geheimnisvollen Effekt ab Plugin Nummer X. Jedes Plugin bringt seinen Anteil mit, und der ist sehr unterschiedlich groß.

Warum das Backend stärker leidet

Wenn dein WordPress-Backend langsam ist, liegt das oft an Plugins. Im Dashboard stieg die Serverzeit mit 50 Plugins von 230 auf 1.299 ms, die Zahl der Datenbankabfragen von 132 auf 546. Für das Backend gibt es keinen Seiten-Cache, der das abfängt. Jeder Klick wird frisch gebaut.

Dazu kommen Verbindungen nach außen. Viele Plugins fragen im Backend bei ihrem Hersteller nach Neuigkeiten, Lizenzen oder Angeboten. Mit allen 50 Plugins zeigte Query Monitor beim ersten Aufruf des Dashboards drei solche Anfragen, die zusammen 0,46 Sekunden dauerten. Während dieser Zeit wartet die Seite. Bei den nächsten Aufrufen waren sie verschwunden, weil die Plugins die Antwort eine Weile zwischenspeichern. Danach kommen sie wieder.

Mit unserem Connection Monitor haben wir mitgeschrieben, wer wohin funkt. Neu gegenüber der Grundausstattung waren unter anderem WooCommerce (woocommerce.com, public-api.wordpress.com), WPForms (wpformsapi.com), Jetpack, MonsterInsights, Duplicator, OptinMonster und XML Sitemaps, das die Seite bei IndexNow angemeldet hat. Am auffälligsten war Starter Templates: Direkt nach der Aktivierung holte es beim ersten Besuch im Backend innerhalb von sechs Sekunden 80-mal Daten von websitedemos.net, zusammen 6,8 MB. Das ist die Vorlagen-Bibliothek. Brauchst du das Plugin nach dem Einrichten nicht mehr, deaktiviere es.

So findest du die Bremsen bei dir

Das kostenlose Plugin Query Monitor zeigt dir für jeden Seitenaufruf, wie lange er gedauert hat und welches Plugin wie viele Datenbankabfragen gemacht hat. So gehst du vor:

1. Installiere Query Monitor unter Plugins → Neues Plugin hinzufügen (Suche nach „Query Monitor“) und aktiviere es.
2. Öffne deine Startseite, während du angemeldet bist. Oben in der Werkzeugleiste stehen jetzt vier Zahlen: Zeit, Arbeitsspeicher, Zeit für die Datenbank und Zahl der Abfragen.
3. Klicke auf diese Zahlen. Unten öffnet sich das Query-Monitor-Fenster mit dem Überblick.
4. Klicke auf Datenbankabfragen → Abfragen nach Komponenten. Dort siehst du, welches Plugin wie viele Abfragen macht.
5. Öffne dasselbe im Dashboard und schau unter HTTP-API-Abrufe, welche Plugins beim Laden nach außen funken.
6. Lade jede Seite fünfmal und merke dir den mittleren Wert. Einzelne Aufrufe schwanken stark.
7. Bist du fertig, deaktiviere Query Monitor wieder. Es kostet selbst ein wenig Zeit.

Schau dir in beiden Screenshots auch die Zeit an: Die Datenbankabfragen brauchten zusammen nur 0,04 bis 0,07 Sekunden von über einer Sekunde. Die meiste Zeit geht also nicht in die Datenbank, sondern ins Laden und Ausführen von Plugin-Code. Darum ist die Zahl der Abfragen nur ein Hinweis, nicht die ganze Wahrheit.

Ob ein bestimmtes Plugin bremst, findest du am sichersten so heraus: Deaktiviere es, lade die Seite wieder fünfmal und vergleiche die Zeit zur Seitenerstellung.

Was du tun kannst

• Ungenutzte Plugins löschen. Inaktive Plugins laden keinen Code. In unserem Test waren in der Ausgangsstufe alle 50 installiert, aber keins aktiv, und die Seite lag bei 237 ms. Löschen solltest du sie trotzdem, weil auch inaktiver Code eine Sicherheitslücke haben kann.
• Schwere Plugins gezielt prüfen. Brauchst du WooCommerce, ein großes Addon-Paket oder ein Formular-Plugin wirklich auf dieser Seite? Ein schweres Plugin weniger bringt mehr als zehn kleine weniger.
• Einrichtungs-Helfer nach dem Einrichten deaktivieren. Starter Templates, Importer und Demo-Importer brauchst du einmal. Danach kosten sie nur noch Zeit und Verbindungen nach außen.
• Für Besucher einen Seiten-Cache nutzen. Ein Cache liefert die fertige Seite aus, ohne dass Plugins jedes Mal neu laufen. Wie das mit Elementor geht, zeigen wir in WP Rocket für Elementor einrichten. Das Backend profitiert davon nicht.
• Addon-Pakete abspecken. Viele Pakete wie Essential Addons oder ElementsKit lassen dich ungenutzte Widgets in den Einstellungen abschalten. Wie viel das spart, haben wir hier nicht gemessen.

Die Frage „Wie viele Plugins sind zu viele?“ lässt sich also nicht mit einer Zahl beantworten. 30 leichte Plugins können harmloser sein als ein einziges schweres. Schau dir an, was deine Plugins kosten, und entscheide dann.

Für Technikinteressierte: Testaufbau und Rohdaten

• Labor: WordPress 7.1.4, PHP 8.4, Hello Elementor 3.5.2, Elementor 4.3.6, Elementor Pro 4.3.2, Shared Hosting bei All-Inkl, kein Cache-Plugin. Grundausstattung mit 4 aktiven Plugins: Elementor, Elementor Pro, Angie (der KI-Assistent von Elementor) und unser Connection Monitor. Referenzseite mit Hero-Bild, Icon-Boxen, Kundenstimmen-Slider, Galerie, Akkordeon, Formular und Popup. Methodik
• Plugin-Liste: die 50 beliebtesten Plugins laut WordPress.org-Verzeichnis (Abfrage „popular“ vom 7. November 2026), jeweils in der aktuellen Version. Alle 50 waren vorher installiert und inaktiv, aktiviert wurden sie in der Reihenfolge der Liste.
• Serverzeit: gemessen mit einem eigenen Messfühler (mu-Plugin), der die Zeit vom Start von PHP bis zum Ende der Seite, die Datenbankabfragen und den Arbeitsspeicher in die Seite schreibt. Startseite ohne Anmeldung, Dashboard angemeldet als Administrator, immer am Cache vorbei. Vor jeder Messung drei Aufwärm-Abrufe und drei Durchläufe von WP-Cron, damit Einrichtungsarbeiten der Plugins nicht mitgemessen werden.
• Stufen: 0, 10, 25, 50 und am Ende wieder 0 als Kontrolle, je 15 Abrufe Startseite und 10 Dashboard, dazu Lighthouse 13.5.0 mit je 5 Läufen mobil und Desktop. Vor jeder Stufe wurde das Labor auf denselben Snapshot zurückgesetzt.
• Einzeln: jedes Plugin allein auf der Grundausstattung, 20 Abrufe Startseite und 6 Dashboard. Nach jeweils 5 Plugins eine neue Messung der Grundausstattung. Die 11 Basismessungen lagen auf der Startseite zwischen 235 und 275 ms (Median 252 ms). Unterschiede unter etwa 30 ms sind deshalb nicht von Rauschen zu trennen. Antispam Bee zeigte einmal +65 ms, ohne zusätzliche Abfragen, Dateien oder Speicher, und in der Wiederholung +4 ms. Das werten wir als Ausreißer. Die Dashboard-Werte beruhen auf nur 6 Abrufen und schwanken stärker.
• Drift: Die Kontrollmessung am Ende lag 44 ms (Startseite) und 38 ms (Dashboard) über der ersten. Die Unterschiede zwischen den Stufen sind 10- bis 25-mal so groß.
• Lighthouse: Die Wartezeit auf das erste Byte in Lighthouse enthält auch den Weg über das Internet und ist deshalb höher als die reine Serverzeit. Bei 10 und 25 Plugins lag sie in umgekehrter Reihenfolge (1,31 und 1,23 s), das ist Schwankung der Verbindung. Die gesamte Blockierzeit (TBT) lag in allen Stufen bei 0.
• Funktionstest in jeder Stufe mit einem automatisierten Browser: Burger-Menü, Slider, Akkordeon, Formular und Popup. Alles bestanden, keine Konsolenfehler.
• Besonderheit: Widgets for Google Reviews (Trustindex) leitet den ersten Aufruf nach der Aktivierung auf seine Einstellungsseite um. Unser Selbsttest prüft deshalb zweimal.
• Transparenz: Den ersten kompletten Durchlauf vom 7. November haben wir verworfen. Unser Werkzeug zum Zurücksetzen hatte nicht alle Datenbanktabellen gelöscht, dadurch stimmten Tabellenzahl und Datenbankgröße nicht. Die Zeitwerte waren ähnlich (50 Plugins: 969 statt 1.048 ms). Alle Werte oben stammen aus der Wiederholung vom 8. November mit korrigiertem Werkzeug.
• Rohdaten: rohdaten.csv mit allen 2.682 Messungen (Stufen, Einzelmessung, Feinmessung, Vergleich WooCommerce gegen 25 Plugins). Gemessen am 7. und 8. November 2026.