Diese 3 WordPress-Plugins legen Ihre Website lahm

Eine WordPress-Seite wird selten von heute auf morgen langsam. Sie verschluckt sich langsam. Ein Plugin hier, ein hübsches Feature da, und nach zwei Jahren lädt die Startseite vier Sekunden, während der Kunde sich fragt, warum die Anfragen weniger werden. Wir betreuen im Münchner Westen einige Betriebe mit genau diesem Muster. Und fast immer sind es dieselben drei Plugin-Kategorien, die den größten Schaden anrichten. Nicht weil sie schlecht programmiert wären, sondern weil sie für einen Zweck geladen werden, den man auch mit einem Bruchteil des Gewichts erreicht.

Ich schreibe hier bewusst von Kategorien, nicht von einzelnen Produktnamen. Der Grund: Die Hersteller ändern ihre Plugins ständig, und ein Name, den ich heute nenne, ist in einem Jahr vielleicht schon deutlich schlanker. Das Muster dahinter bleibt aber gleich.

Warum ein Page-Builder Ihre Ladezeit auffrisst

Die erste und schwerste Kategorie sind die großen Page-Builder. Elementor, Divi, WPBakery. Sie sind beliebt, weil man ohne Code eine Seite zusammenklicken kann. Das ist der Deal. Und für den Deal zahlen Sie mit CSS und JavaScript, das bei jedem Seitenaufruf mitgeladen wird, egal ob Sie die Hälfte der Funktionen nutzen oder nicht.

Bei einer Kundenseite aus Germering haben wir das gemessen. Die Seite lief auf einem verbreiteten Page-Builder. Der Browser lud allein für das Layout rund 380 Kilobyte an zusätzlichem CSS und JavaScript, bevor überhaupt der erste Text sichtbar war. Ein guter Teil davon war Code für Widgets, die auf der Seite gar nicht vorkamen. Karussells, Countdown-Timer, Preistabellen. Alles vorgehalten, nichts genutzt.

Was hilft:

• Global entrümpeln. Viele Page-Builder haben unter den Einstellungen einen Punkt wie "Optimized Asset Loading" oder "Improved Loading". Der ist bei alten Installationen oft aus. Einschalten, dann lädt zumindest nur noch das CSS, das die Seite wirklich braucht.
• Kritische Seiten aus dem Builder lösen. Startseite und die zwei, drei wichtigsten Landingpages als sauberes Template bauen. Den Builder dürfen die selten geänderten Unterseiten behalten.
• Ganz raus, wenn möglich. Wer eine Seite ohnehin überarbeitet, fährt mit einem Block-Theme oder handgebautem HTML fast immer schneller. Das ist mehr Arbeit, hält aber Jahre.

Ehrlich gesagt: Einen Page-Builder komplett zu entfernen ist die aufwändigste der drei Maßnahmen, weil oft die halbe Seite darauf aufbaut. Wenn Zeit und Budget knapp sind, fangen Sie lieber mit den nächsten zwei Punkten an. Die bringen viel bei wenig Risiko.

Das Slider-Plugin, das niemand mehr braucht

Die zweite Kategorie sind die alles-in-einem Slider-Plugins. Revolution Slider, Slider Revolution, LayerSlider und ähnliche. Vor zehn Jahren war so ein Slider ein Statussymbol. Jede zweite Seite hatte oben eine große animierte Bildershow. Heute weiß man aus einigen Nutzungsstudien, dass kaum jemand über das erste Bild hinausklickt. Der Effekt für den Besucher ist gering. Das Gewicht für die Ladezeit ist es nicht.

Hier kam der Fall, der mich selbst überrascht hat. Ein Handwerksbetrieb aus Emmering, direkt neben Fürstenfeldbruck. Die Startseite lud mit einem LCP von 4,1 Sekunden. Der Largest Contentful Paint, also der Moment, in dem der größte sichtbare Inhalt fertig geladen ist, gehört zu den Core Web Vitals, die Google für die Bewertung heranzieht. 4,1 Sekunden sind schlecht. Wir gingen die Plugins durch und fanden ein aktives Slider-Plugin. Das Kuriose: Auf der Seite war gar kein Slider mehr zu sehen. Er war irgendwann aus dem Layout genommen worden, aber das Plugin lief weiter, lud seine Skripte und feuerte seine Datenbankabfragen bei jedem Aufruf.

Wir haben es deaktiviert. Sonst nichts geändert. Der LCP fiel auf 1,8 Sekunden. Optisch hat sich für keinen Besucher irgendetwas verändert, weil der Slider ja ohnehin unsichtbar war. Das ist die Sorte Fund, für die sich ein Blick unter die Haube lohnt.

Was hilft:

• Prüfen, ob der Slider überhaupt noch angezeigt wird. Sie wären nicht der erste Betrieb mit einem toten Plugin im Hintergrund.
• Ein einzelnes Hero-Bild statt Slideshow. Ein gutes, komprimiertes Bild mit klarer Aussage schlägt drei wechselnde Bilder fast immer. Auch bei den Ladezeiten.
• Wenn es wirklich Bewegung sein muss: die native Bildergalerie oder ein winziges Skript reicht. Ein 300-Kilobyte-Plugin für einen Effekt, den kaum jemand sieht, steht in keinem Verhältnis.

Die Security-Suite, die bei jedem Klick nachfragt

Die dritte Kategorie ist heikler, weil hier ein echtes Bedürfnis dahintersteht. Sicherheit. Plugins wie Wordfence oder iThemes Security schützen vor Angriffen, und das ist gut. Das Problem ist nicht die Idee, sondern wie manche dieser Suiten arbeiten. Die schweren Varianten prüfen bei jedem einzelnen Seitenaufruf gegen die Datenbank, protokollieren Zugriffe, gleichen IP-Listen ab. Jede dieser Abfragen kostet Zeit, und zwar genau in dem Moment, in dem der Besucher auf eine Antwort wartet.

Bei einem Onlineshop-Kunden aus Olching haben wir gesehen, dass die Sicherheits-Suite pro Seitenaufruf mehrere zusätzliche Datenbankabfragen auslöste. In der Serverantwortzeit machte das im Schnitt gut 200 Millisekunden aus. Klingt wenig. Bei einem Kunden, der sich durch fünf Produktseiten klickt, summiert sich das. Und die Serverantwortzeit ist die Basis, auf der alles andere aufbaut. Ist die schon langsam, hilft kein noch so schlankes Frontend.

Was hilft:

• Live-Traffic-Logging abschalten. Die Funktion, die jeden Zugriff in Echtzeit mitschreibt, frisst am meisten und braucht kaum jemand dauerhaft. Für eine gezielte Analyse kurz einschalten, danach wieder aus.
• Firewall auf Serverebene statt im Plugin. Viele gute Hoster bieten eine Web Application Firewall an, die vor WordPress greift. Das ist schneller und entlastet die Datenbank.
• Die Grundlagen stimmen lassen. Aktuelle WordPress-Version, aktuelle Plugins, starke Passwörter, Zwei-Faktor am Login. Das deckt einen großen Teil der Angriffe ab, ohne dass ein schweres Plugin ständig mitläuft.

Wie testen Sie das risikofrei?

Der wichtigste Punkt zum Schluss. Deaktivieren Sie kein Plugin blind auf der Live-Seite eines laufenden Betriebs. Das kann schiefgehen, wenn andere Funktionen daran hängen. So gehen wir vor:

• Vorher messen. Ein Werkzeug wie PageSpeed Insights oder ein einfacher Wasserfall-Test zeigt Ihnen den Ausgangswert. Schreiben Sie sich LCP und Serverantwortzeit auf.
• Eine Kopie der Seite als Staging anlegen. Dort probieren, was passiert, wenn ein Plugin aus ist.
• Ein Plugin nach dem anderen deaktivieren, jedes Mal neu messen und die Seite durchklicken. So sehen Sie sofort, was Tempo bringt und was etwas kaputt macht.
• Erst wenn eine Änderung sauber läuft, wandert sie auf die Live-Seite.

Das ist kein Hexenwerk, kostet aber ein paar Stunden Sorgfalt. Genau die investieren viele Betriebe nicht, weil im Alltag anderes drängt. Verständlich. Nur wächst der Ballast dann eben weiter.

Wenn Sie den Verdacht haben, dass Ihre WordPress-Seite unter genau solchem Ballast ächzt, schauen wir uns das gern an. Wir machen einen kostenlosen Website-Check, bei dem wir die größten Bremsen benennen, und zwar konkret mit Messwerten, nicht mit Bauchgefühl. Mehr zu unserer Arbeit finden Sie unter Webdesign, und für den Check melden Sie sich einfach über die Seite Kontakt. Wir sitzen in Fürstenfeldbruck und betreuen Kunden im ganzen Münchner Westen, von Puchheim bis Maisach.