WordPress langsam durch Plugins: drei Verdächtige prüfen

Wird Ihr Webauftritt träge, ist WordPress langsam durch Plugins eine der ersten Vermutungen, die sich lohnt. Drei Arten von Plugins verdienen dabei einen genauen Blick: große Page-Builder, Slider-Plugins und schwere Sicherheits-Suiten. Alle drei laden bei jedem Seitenaufruf Code oder lösen Datenbankabfragen aus, und alle drei lassen sich mit Bordmitteln messen und gefahrlos auf einer Testkopie prüfen. Wie das geht und welche Kontrolle Sie dauerhaft automatisieren können, steht in diesem Beitrag.

Eine WordPress-Seite wird selten von heute auf morgen langsam. Sie wird es nach und nach: ein Plugin hier, ein hübsches Feature da, und nach zwei Jahren wartet man auf der Startseite deutlich länger als am Anfang. Ich schreibe hier bewusst von Plugin-Arten, nicht von einzelnen Produkten. Die Hersteller ändern ihre Plugins ständig, und was heute schwer ist, kann in einem Jahr deutlich schlanker sein. Das Muster dahinter bleibt aber gleich: Ein Plugin wird für einen Zweck geladen, den man oft mit einem Bruchteil des Gewichts erreicht. Ich finde, bei jedem Plugin lohnt deshalb die Frage: Wofür wurde es installiert, und wird das noch gebraucht?

Wie messe ich, ob Plugins meine Seite bremsen?

Mit PageSpeed Insights von Google und dem Netzwerk-Tab Ihres Browsers, beides kostenlos. Schreiben Sie sich vor jeder Änderung zwei Werte auf: den Largest Contentful Paint, kurz LCP, also den Moment, in dem der größte sichtbare Inhalt fertig ist, und die Antwortzeit des Servers. Google empfiehlt für den LCP 2,5 Sekunden oder weniger (web.dev zu den Core Web Vitals, abgerufen am 25.09.2026). Was der Wert genau misst, erklärt unser Glossar unter LCP. Liegt Ihr Wert darüber, suchen Sie die Ursache, bevor Sie irgendetwas deinstallieren.

Im Netzwerk-Tab (F12, dann "Netzwerk" wählen und die Seite neu laden) sehen Sie jede Datei, die beim Aufruf übertragen wird. Sortieren Sie nach Größe. Tauchen dort Dateien mit dem Namen eines Plugins auf, dessen Funktion nirgends zu sehen ist, haben Sie einen ersten Verdächtigen.

Warum kostet ein Page-Builder Ladezeit?

Weil er Code für seine Funktionen mitbringt, oft auch für die, die Sie gar nicht nutzen. Page-Builder wie Elementor, Divi oder WPBakery sind beliebt, weil man ohne Programmierkenntnisse eine Seite zusammenklicken kann. Das ist der Deal. Bezahlt wird mit zusätzlichem CSS und JavaScript, das der Browser laden muss, bevor der erste Text erscheint. Wie viel das bei Ihnen ausmacht, zeigt nur Ihre eigene Messung. Angenommen, im Netzwerk-Tab stammen mehrere hundert Kilobyte von einem Page-Builder: Dann lohnt der Blick, ob Code für Karussells, Countdown-Timer oder Preistabellen geladen wird, die im Layout gar nicht vorkommen.

Was hilft:

• Suchen Sie in den Einstellungen des Builders nach Optionen, die nur das tatsächlich genutzte CSS und JavaScript laden. Bei älteren Installationen sind solche Optionen oft noch aus; wie sie heißen, hängt von Produkt und Version ab.
• Bauen Sie die Startseite und die zwei, drei wichtigsten Seiten als schlankes Template ohne Builder. Selten geänderte Unterseiten dürfen ihn behalten.
• Wer die Seite ohnehin überarbeitet, kann den Builder ganz ablösen, etwa durch ein Block-Theme oder handgeschriebenes HTML. Das ist mehr Arbeit, hält aber lange.

Einen Page-Builder komplett zu entfernen ist die aufwendigste der drei Maßnahmen, weil oft die halbe Seite darauf aufbaut. Bei knappem Budget fangen Sie lieber mit den nächsten beiden Plugin-Arten an. Dort ist das Risiko kleiner.

Braucht meine Seite das Slider-Plugin noch?

Das prüfen Sie in einer Minute: Zeigt Ihre Startseite überhaupt noch einen Slider? Große Slider-Plugins waren lange ein beliebtes Statussymbol, oben eine animierte Bildershow über die ganze Breite. Wird die Startseite später umgebaut, verschwindet der Slider oft aus dem Layout. Das Plugin bleibt dabei leicht aktiv, lädt weiter seine Skripte und fragt bei jedem Aufruf die Datenbank ab, ohne dass irgendein Besucher etwas davon sieht.

Ein Rechenbeispiel ohne echten Fall dahinter: Lädt ein ungenutztes Plugin 300 Kilobyte Skripte, sind das bei einer angenommenen Mobilverbindung von 10 Megabit pro Sekunde rund eine Viertelsekunde nur für die Übertragung, noch ohne die Zeit, die das Handy zum Ausführen braucht.

Was hilft:

• Prüfen Sie im Backend unter "Plugins", ob ein Slider-Plugin aktiv ist, und im Frontend, ob man es irgendwo sieht.
• Ersetzen Sie die Slideshow durch ein einzelnes, gut komprimiertes Bild mit klarer Aussage. Ob Besucher auf Ihrer Seite überhaupt durch mehrere Bilder klicken, zeigt Ihnen Ihre eigene Statistik.
• Muss es Bewegung sein, reicht oft die Galerie von WordPress oder ein kleines Skript statt eines großen Plugins.

Wann bremst ein Sicherheits-Plugin?

Wenn es bei jedem Seitenaufruf arbeitet, während der Besucher auf die Antwort wartet. Das Bedürfnis dahinter ist berechtigt, niemand will eine gehackte Website. Manche Sicherheits-Suiten prüfen aber jeden Aufruf gegen die Datenbank, schreiben jeden Zugriff in ein Protokoll und gleichen IP-Listen ab. Jede dieser Abfragen kostet Zeit, und die Antwortzeit des Servers ist die Basis, auf der alles andere aufbaut. Ist die schon langsam, hilft auch das schlankeste Frontend wenig.

Was hilft:

• Schalten Sie eine Echtzeit-Protokollierung aller Zugriffe nur für eine gezielte Analyse ein und danach wieder aus.
• Fragen Sie Ihren Hoster nach einer Firewall auf Serverebene, die vor WordPress greift. Sie entlastet die Datenbank.
• Halten Sie die Grundlagen sauber: aktuelle WordPress-Version, aktuelle Plugins, starke Passwörter, Anmeldung mit zweitem Faktor. Das nimmt einem Sicherheits-Plugin viel Arbeit ab.

Wie testen Sie das gefahrlos?

Auf einer Kopie, nie direkt auf der Live-Seite. Deaktivieren Sie kein Plugin blind im laufenden Betrieb, denn manchmal hängen andere Funktionen daran, etwa ein Formular oder der Cookie-Hinweis. So gehen Sie vor:

1. Vorher messen und LCP sowie Antwortzeit des Servers notieren.
2. Eine Kopie der Seite als Testumgebung anlegen, oft Staging genannt. Viele Hoster bieten das per Klick an.
3. Ein Plugin nach dem anderen deaktivieren, jedes Mal neu messen und die Seite durchklicken: Formular, Menü, Cookie-Hinweis.
4. Nur was sauber läuft, auf die Live-Seite übernehmen, mit einer frischen Sicherung davor.

Das kostet ein paar Stunden Sorgfalt. Im Alltag drängt oft anderes, und so wächst der Ballast weiter. Genau deshalb lohnt es sich, das regelmäßige Nachsehen einer Maschine zu überlassen.

WordPress-Wartung automatisieren: was geht, was nicht?

WordPress-Wartung automatisieren heißt vor allem Messen, Sichern und Melden; die Entscheidung über ein Plugin bleibt bei Ihnen. Eine automatische Kontrolle sagt Ihnen, wann die Seite langsamer wird und welches Plugin ein Update braucht, bevor ein Kunde es merkt.

• Ladezeit regelmäßig messen: Die PageSpeed Insights API misst die Leistung einer Seite, gibt Labordaten aus Lighthouse zurück und lässt sich per Skript abfragen, zum Beispiel einmal pro Woche. Für Daten echter Besuche empfiehlt Google inzwischen die CrUX API (Google for Developers, abgerufen am 25.09.2026). Steigt der LCP über Ihren Grenzwert, kommt eine Nachricht.
• Plugin-Liste als Bericht: Das Kommandozeilenwerkzeug WP-CLI gibt mit wp plugin list jedes Plugin mit Status, Version und verfügbarem Update aus, auf Wunsch als CSV oder JSON (WP-CLI-Dokumentation, abgerufen am 25.09.2026). Einmal im Monat als Tabelle verschickt, sehen Sie inaktive Plugins und offene Updates auf einen Blick.
• Updates mit Sicherung: Seit WordPress 5.5 lassen sich automatische Updates für einzelne Plugins und Themes einschalten, und die WordPress-Dokumentation rät zu regelmäßigen automatischen Sicherungen (WordPress-Dokumentation, abgerufen am 25.09.2026).
• Nach jedem Update ein kurzer automatischer Test: Startseite, Kontaktformular und Impressum aufrufen und prüfen, ob sie antworten.

Angenommen, die Schreinerei Muster betreibt ihre Seite mit WordPress. Jeden Montag kommt eine kurze Mail mit drei Angaben: Ladezeit der Startseite, Zahl der offenen Updates, inaktive Plugins. Ist alles im grünen Bereich, reicht ein Blick. Fällt ein Wert aus dem Rahmen, entscheidet ein Mensch, ob und wann auf der Testkopie gearbeitet wird. Automatisch löschen oder deaktivieren sollte so ein Ablauf nichts.

Wir bei bytebrise bauen solche Kontrollabläufe für Betriebe in der Region. Die Automatisierung ist neu bei uns und läuft noch bei keinem Betrieb dauerhaft. Jeder Ablauf beginnt als Prototyp zum Festpreis ab 1.500 € mit vier Wochen Test in Ihrem Betrieb, danach folgt eine Monatspauschale, monatlich kündbar (KI für Unternehmen). Wer die Pflege ganz abgeben will, mietet die Website bei uns für 490 € zum Start und 149 € im Monat, Hosting, Pflege und Updates inklusive, kündbar zum Ende jedes Kalendermonats ohne Vorlauffrist (Preise). Fragen zu Ihrer WordPress-Seite schreiben Sie uns über das Kontaktformular.