WordPress Performance: Warum zu viele Plugins deine Seite ausbremsen

Was WordPress „von Natur aus“ mitbringt

Zugegeben: WordPress bringt schon einiges mit. Technisch gesehen startet man mit rund zehn Datenbanktabellen und einem System, das auf fast jedem Server läuft, der halbwegs mit PHP und MySQL/MariaDB umgehen kann.
Fachlich ist WordPress erstaunlich flexibel: Man kann statische Seiten bauen, dynamische Inhalte ausgeben, Galerien einfügen oder Abfrageloops erstellen, die nur bestimmte Beiträge oder Kategorien anzeigen. Und natürlich gibt es Beiträge – das ist das Erbe aus der Zeit, als WordPress noch reine Blogsoftware war.
Bilder, Dokumente und andere Medien lassen sich bequem über die Mediathek verwalten. Für viele Websites reicht das schon völlig aus.

Wozu es dann Plugins braucht!?

Natürlich kann man sich jetzt fragen, wozu man überhaupt noch Plugins braucht. Die Frage ist nicht ganz unberechtigt – vieles, was man von modernen Websites erwartet, ist ja bereits im Core vorhanden.
Schwierig wird’s aber bei Dingen wie Kontaktformularen. Oder wenn man aus WordPress einen Shop machen möchte. Das geht dann erst richtig mit Erweiterungen wie WooCommerce.

Und manche Dinge sind einfach praktisch:
Wer heute etwas schreibt und erst morgen veröffentlichen möchte, braucht entweder ein Zeitfenster, um sich nochmal einzuloggen – oder ein Plugin, das den Beitrag automatisch vom Entwurf zur Veröffentlichung schiebt. Und im Zweifel auch wieder zurück, wenn er nicht länger online sein soll.

Kurzum:
Plugins braucht man immer dann, wenn man etwas tun möchte, was WordPress von Haus aus nicht kann.

WordPress Plugins – vom angenehmen Helfer zum Problem

Jetzt beginnt ein Balanceakt. Selten wird gefragt: Was brauche ich wirklich – und welches Tool ist das richtige für mich? Noch seltener wird etwas erst einmal in Ruhe getestet. Viel häufiger passiert Folgendes:
Es wird installiert, ausprobiert, noch etwas installiert, vielleicht deaktiviert und ganz eventuell auch wieder deinstalliert. Und genau da beginnen die Probleme.

Da es unzählige Plugin‑Kombinationen gibt, kann kein Plugin mit allem gut. Ein Satz wie „Wir machen X für Sie“ kann schnell scheitern, weil ein anderes Plugin WordPress bereits so verändert hat, dass es nicht mehr dem „WordPress‑Standard“ entspricht.

Was ich oft beobachte: Ein Plugin wird mit einem weiteren Plugin ergänzt. Aus „Ich brauche ein Plugin, das X kann“ wird plötzlich „Wir nutzen jetzt drei Plugins, um X hinzubekommen“.
Und spätestens dann wird’s stressig für WordPress.

Warum?

Weil WordPress bei jedem Seitenaufruf alles lädt – wirklich alles – was an Plugins vorhanden ist. Es gibt keine Möglichkeit zu sagen: „Dieses Plugin ist nur fürs Backend, bitte nur dort laden.“
Natürlich kann ein Entwickler intern prüfen „Wenn nicht admin, dann überspringe den Rest“, aber da ist es schon zu spät. Die Datei – oder mehrere Dateien – wurden bereits geladen.

Man kann sich das so vorstellen:
Ein großes Regal voller Aktenordner. Jeder Ordner ist ein Plugin. Beim Start muss jeder Ordner einmal aus dem Regal genommen, aufgeklappt und kurz geprüft werden. Erst danach kann entschieden werden: „Brauche ich gerade nicht.“

Aber da ist der Aufwand längst passiert.

Und dann gibt es noch die Grundstruktur von WordPress selbst. Ein kleiner Abstecher in die Untiefen: WordPress speichert Einstellungen als „Optionen“. Viele davon sind autoloaded, also werden automatisch geladen – auch wenn sie gerade gar nicht gebraucht werden.
Wenn jetzt 20 Plugins jeweils nur fünf Optionen mitbringen und alle autoload = yes sind… du kannst dir vorstellen, was passiert (Spoiler: Die wenigsten Plugins kommen „nur“ mit 5 Optionen).

How to met your Plugin – ein paar Anregungen für Webseitenbetreiber (und Pluginentwickler)

Was kann man also tun gegen solche „Monster“?
Zunächst lohnt sich die Frage: Brauche ich das wirklich?
Muss es wirklich ein Pagebuilder sein, der zwar alles hübsch anordnet, aber auch jede Menge zusätzliche Skripte und Funktionen mitbringt, die man vielleicht gar nicht braucht – oder die WordPress längst selbst kann?

Nicht falsch verstehen: Pagebuilder sind nicht grundsätzlich schlecht. Es kommt nur darauf an, wofür man sie einsetzt.
Ein kleines Bild dazu: Wenn ich nur mich und meinen Rucksack transportieren will, miete ich keinen Transporter. Und wenn ich einen Termin im Ort habe, gehe ich vielleicht einfach zu Fuß. Nur weil es große Werkzeuge gibt, heißt das nicht, dass man sie immer braucht.

Was Entwickler tun können:
Klar kommunizieren, was das Plugin kann, womit es kompatibel ist und wo die Grenzen liegen. Nicht nur „Getestet mit WordPress Version X“.
Optionen sparsam einsetzen – und gern explizit auf autoload = no setzen, wenn sie nicht ständig gebraucht werden. Für eine einzelne Option ist das ein kleiner Schritt, aber wenn das viele Entwickler tun, merkt man das deutlich in der Performance.

Was Betreiber tun können:
Eine Entwicklungs‑ oder Testumgebung einrichten und dort ausprobieren, wie sich ein Plugin verhält.
Verlangsamt es die Seite?
Bringt es uns wirklich weiter?
Oder brauchen wir plötzlich zwei weitere Plugins, um das ursprüngliche Ziel zu erreichen?
Solche Fragen gehören eigentlich in jedes kleine „Testprotokoll“.

Und was nie schadet:
Eine gute Webagentur – oder, wer keine Agenturen mag, ein guter Webentwickler. Jemand, der nicht nur weiß, wie man WordPress im Frontend bedient, sondern auch versteht, wie die technischen Strukturen dahinter funktionieren.

Deswegen unser Tipp:
Gern Kontakt aufnehmen – wir helfen bei wirklich performanten WordPress‑Webseiten.