Warum ist meine WordPress-Seite so langsam?

Eine langsame WordPress-Seite hat fast immer eine von drei Ursachen: träges Hosting, zu viele oder schlecht gebaute Plugins – oder ein strukturelles Problem im Theme beziehungsweise Page-Builder. Die ersten beiden lassen sich oft günstig beheben, das dritte nicht: Wenn das Fundament zu schwer ist, hilft auch das zehnte Optimierungs-Plugin nichts mehr. Bevor Sie Geld ausgeben, sollten Sie deshalb herausfinden, in welche Kategorie Ihr Problem fällt. Das geht in etwa 30 Minuten und kostet nichts.

Warum „besseres Hosting“ selten die ganze Antwort ist

Wer diese Frage googelt, landet meist bei Hosting-Anbietern und Plugin-Herstellern – und deren Antwort ist vorhersehbar: schnelleres Hosting, ein weiteres Caching-Plugin. Beides kann helfen, aber nur, wenn das Problem tatsächlich dort liegt. Ein Caching-Plugin beschleunigt die Auslieferung einer Seite; es macht die Seite selbst nicht leichter. Wenn Ihr Theme mehrere Megabyte CSS und JavaScript lädt, kommt dieses Gewicht auch aus dem schnellsten Cache beim Besucher an und muss dort verarbeitet werden. Genau deshalb fühlen sich viele Seiten trotz „grünem“ Caching-Setup weiterhin zäh an – besonders am Smartphone.

Schritt 1: Messen statt raten – PageSpeed Insights

Öffnen Sie PageSpeed Insights und testen Sie Ihre Startseite sowie eine wichtige Unterseite. Achten Sie auf die mobilen Werte, nicht auf die Desktop-Werte: Google bewertet mobil, und dort zeigen sich Probleme zuerst. Der wichtigste Einzelwert ist der Largest Contentful Paint (LCP) – laut Google gilt ein LCP bis 2,5 Sekunden als gut. Notieren Sie außerdem, was unter den Empfehlungen steht: Einträge wie „Nicht verwendetes CSS reduzieren“ oder „JavaScript-Ausführungszeit verkürzen“ deuten auf strukturelle Probleme hin, nicht auf das Hosting. Was die einzelnen Metriken bedeuten, erklären wir ausführlich im Beitrag zu den Core Web Vitals.

Schritt 2: TTFB prüfen – der Hosting-Indikator

Die Time to First Byte (TTFB) misst, wie lange Ihr Server braucht, bis das erste Byte der Antwort beim Browser ankommt – als Richtwert für einen guten Wert nennt Google unter 0,8 Sekunden (web.dev). Sie finden die TTFB in den Chrome DevTools im Netzwerk-Tab oder in den Diagnosedaten von PageSpeed Insights. Liegt Ihre TTFB deutlich darüber, ist tatsächlich das Hosting oder die serverseitige Verarbeitung das Problem: Hier helfen serverseitiges Caching, ein besserer Tarif oder ein Anbieterwechsel. Liegt die TTFB im grünen Bereich und die Seite lädt trotzdem langsam, liegt das Problem im Frontend – und kein Hosting-Upgrade der Welt wird daran etwas ändern.

Schritt 3: Plugins zählen und ehrlich aussortieren

Öffnen Sie Ihre Plugin-Liste. Eine magische Grenze gibt es nicht, aber jedes aktive Plugin kann eigenes CSS und JavaScript in jede Seite laden und eigene Datenbankabfragen auslösen. Wichtiger als die reine Zahl ist die Art der Plugins: Slider, Page-Builder-Add-ons und ironischerweise auch manche „Optimierungs“-Plugins gehören zu den häufigsten Bremsen, die wir in Audits sehen. Der ehrliche Test: Legen Sie eine Staging-Kopie an, deaktivieren Sie Plugins gruppenweise und messen Sie nach jeder Gruppe neu. Wenn sich die Ladezeit dabei deutlich verbessert, haben Sie Ihre Ursache gefunden – und können gezielt ersetzen oder streichen.

Schritt 4: Das strukturelle Problem – Theme und Page-Builder

Multipurpose-Themes und Page-Builder wie Elementor oder Divi sind für maximale Flexibilität gebaut, nicht für Geschwindigkeit. Sie laden Code für hunderte Funktionen, von denen Ihre Seite nur einen Bruchteil nutzt, und erzeugen tief verschachteltes HTML, das der Browser aufwendig verarbeiten muss. Die Erkennungszeichen in PageSpeed Insights: große Mengen an ungenutztem CSS und JavaScript, hohe JavaScript-Ausführungszeit und Warnungen zur DOM-Größe. Das ist die Kategorie, in der Optimierungs-Plugins nur Symptome kaschieren – die eigentliche Last steckt im Fundament der Seite.

Wann ein weiteres Plugin Sie nicht mehr rettet

Ist die Diagnose strukturell, lohnt sich eine ehrliche Rechnung. Gegen das eigene Theme zu optimieren ist ein Dauerlauf: Jedes Theme- oder Builder-Update kann mühsam erreichte Fortschritte zunichtemachen, Performance-Plugins kosten laufend Lizenzgebühren, und die Wartungsstunden summieren sich Jahr für Jahr. Geschwindigkeit ist dabei kein Selbstzweck – schon eine Verlängerung der Ladezeit von einer auf drei Sekunden erhöht die Absprungwahrscheinlichkeit um 32 Prozent (Google/SOASTA-Studie, 2017). Ab einem gewissen Punkt ist ein sauberer Neubau – etwa mit Next.js, wo nur der Code ausgeliefert wird, den die Seite wirklich braucht – schlicht die wirtschaftlichere Lösung. Wie ein solcher Wechsel ohne SEO-Schaden gelingt, beantworten wir unter Kann ich von WordPress zu Next.js wechseln, ohne Rankings zu verlieren?

Genauso ehrlich gilt aber die Umkehrung: War die TTFB das Problem oder haben drei überflüssige Plugins gebremst, dann beheben Sie genau das und bleiben Sie bei WordPress. Nicht jede langsame WordPress-Seite braucht eine Migration – und wer Ihnen eine verkaufen will, ohne vorher zu messen, arbeitet nicht in Ihrem Interesse.

Das Fazit für Ihre Entscheidung

• Hohe TTFB (über etwa 0,8 Sekunden): Hosting oder serverseitiges Caching verbessern – günstig und schnell erledigt.
• Wenige auffällige Plugins: gezielt ersetzen oder streichen, danach neu messen.
• Viel ungenutztes CSS/JS, hohe Skript-Laufzeiten, Page-Builder im Einsatz: strukturelles Problem – Optimierung wirkt hier nur begrenzt, ein Neubau ist meist wirtschaftlicher.

Wenn Sie unsicher sind, in welche Kategorie Ihre Seite fällt: Schicken Sie uns Ihre PageSpeed-Werte. Wir sehen sie uns im kostenlosen Erstgespräch an und sagen Ihnen ehrlich, ob Optimierung reicht oder ein Neubau wirtschaftlicher ist – unsere Festpreis-Pakete kalkulieren wir erst danach.

Häufige Fragen