Warum WordPress-Websites oft langsam sind — und wie man es löst

WordPress ist nicht per se langsam — aber die Kombination aus Themes, Plugins und CMS-Architektur führt fast immer zu Performance-Problemen.

Technik Redaktion Website schnell 5 Min. Lesezeit
Schnecke auf der Straße — Symbol für Langsamkeit
Foto: Krzysztof Niewolny / Unsplash

Wenn Sie eine typische WordPress-Firmenwebsite in PageSpeed Insights testen, bekommen Sie meistens einen Performance-Wert zwischen 30 und 60 auf Mobile. Das ist nicht nur schlecht für Google — es kostet auch konkret Besucher. Warum ist das so? Und vor allem: Was können Sie dagegen tun? Hier kommen die drei Hauptursachen und drei Lösungsansätze.

Warum WordPress technisch oft Performance kostet

WordPress ist kein schlechtes System, aber seine Architektur ist auf Flexibilität optimiert, nicht auf Performance. Wenn ein Besucher eine WordPress-Seite aufruft, läuft im Hintergrund folgender Prozess ab:

  1. Der Browser schickt die Anfrage an den Server
  2. Der Webserver leitet sie an PHP weiter
  3. PHP lädt das WordPress-Core
  4. WordPress verbindet sich mit der MySQL-Datenbank
  5. Mehrere Datenbank-Abfragen werden durchgeführt
  6. Das Theme wird geladen
  7. Alle aktiven Plugins werden initialisiert
  8. Jedes Plugin darf seine Hooks registrieren
  9. Das finale HTML wird zusammengebaut
  10. Die Seite wird an den Browser zurückgeschickt

Das passiert bei jedem Seitenaufruf. Bei jedem Besucher. Selbst wenn sich der Inhalt nicht geändert hat. Dieser Ablauf dauert oft zwischen 500 Millisekunden und mehreren Sekunden — je nachdem, wie viele Plugins aktiv sind und wie komplex das Theme ist.

Zum Vergleich: Eine statische HTML-Datei wird in 10-50 Millisekunden ausgeliefert. Das ist Faktor 10 bis 100 schneller — ohne jede Optimierung.

Plugin-Stack: Der größte Performance-Killer

Der häufigste Grund für langsame WordPress-Sites sind Plugins. Ein durchschnittlicher WordPress-Auftritt hat 15 bis 30 aktive Plugins. Jedes dieser Plugins:

  • Lädt bei jedem Seitenaufruf seinen eigenen Code
  • Fügt oft eigene CSS- und JavaScript-Dateien hinzu
  • Registriert Hooks, die WordPress durchlaufen muss
  • Führt möglicherweise eigene Datenbank-Abfragen durch

Ein Beispiel: Ein Kontaktformular-Plugin bringt in der Regel sein eigenes JavaScript, Styling, Backend-Logik und Spam-Schutz mit. Multipliziert mit zwanzig ähnlichen Plugins kommen so schnell 500 KB bis 2 MB an zusätzlichen Assets zusammen — nur damit die Seite alle Funktionen anbieten kann.

Die Folge: Slow First Contentful Paint, hoher Blocking Time, schlechte Mobile-Performance. Und Sie als Seiteninhaber bemerken das oft nicht, weil Sie Ihre eigene Seite bereits gecached haben.

Theme-Bloat: Warum viele Themes überladen sind

Das zweite Problem sind die populären WordPress-Themes. Themes wie Divi, Avada oder Elementor Pro versprechen „alles in einem Paket" — und liefern genau das, mit allen Performance-Konsequenzen.

Typische Theme-Bloat-Probleme:

  • Eingebaute Page-Builder, die hunderte von JavaScript-Widgets laden
  • Unzählige Customization-Optionen im Backend, die bei jedem Aufruf ausgewertet werden
  • Standard-Icon-Sets mit tausenden Icons, von denen Sie drei nutzen
  • Mehrere Font-Familien, die parallel geladen werden
  • Animation-Libraries, die auch dort laufen, wo keine Animationen sind

Eine schlanke Firmenwebsite braucht kein Divi-Theme. Sie braucht eine schlanke Theme-Struktur oder — besser noch — gar kein Theme, sondern saubere HTML/CSS-Struktur.

Caching als Pflaster, nicht als Lösung

Die übliche Antwort auf WordPress-Performance-Probleme: Caching-Plugins. WP Rocket, W3 Total Cache, WP Super Cache — sie alle versuchen, die langsame WordPress-Generierung zu umgehen, indem sie bereits generierte Seiten zwischenspeichern.

Das funktioniert — teilweise. Caching kann eine WordPress-Site von Lighthouse 40 auf Lighthouse 70-80 heben. Aber es hat Grenzen:

Erstens: Der erste Besucher einer noch nicht gecachten Seite bekommt die langsame Version. Wenn Ihre Seite täglich viele unterschiedliche Unterseiten hat, läuft der Cache-Trick oft leer.

Zweitens: Caching funktioniert nicht gut mit dynamischen Elementen. Wenn Sie Live-Daten oder personalisierte Inhalte zeigen, muss der Cache umgangen werden — und Sie sind zurück bei der langsamen Version.

Drittens: Der Caching-Plugin selbst ist wieder ein Plugin. Noch mehr Code, noch mehr potenzielle Konflikte.

Caching ist ein Pflaster, keine Lösung. Die eigentliche Ursache — die ressourcenintensive Architektur — bleibt.

Wann ein WordPress-Optimierungs-Projekt sich lohnt

Wenn Sie eine bestehende WordPress-Site haben, die funktioniert und Inhalte enthält, kann Optimierung sinnvoll sein. Typische Maßnahmen:

  1. Plugin-Audit: Welche Plugins sind wirklich nötig? Meistens lassen sich 30 bis 50 Prozent deaktivieren.
  2. Theme-Wechsel: Von Divi/Elementor auf ein schlankes Theme wie GeneratePress oder Kadence.
  3. Bilder optimieren: WebP-Format, passende Größen, lazy-loading.
  4. Caching aktivieren: Saubere Caching-Konfiguration, am besten serverseitig.
  5. CDN einsetzen: Content Delivery Network für statische Assets.

Realistisches Ergebnis: Lighthouse von 40 auf 75-85. Das ist eine deutliche Verbesserung, aber immer noch nicht das Niveau einer statischen Site.

Wann eine statische Migration sinnvoller ist

Wenn Ihre WordPress-Site unter folgenden Bedingungen leidet, ist eine statische Migration oft günstiger als eine Optimierung:

  • Inhalte ändern sich selten (ein paar Mal pro Jahr)
  • Sie zahlen monatlich für Wartung und Updates
  • Die Performance liegt unter Lighthouse 60
  • Ein Relaunch steht ohnehin an
  • Sie brauchen keine WordPress-spezifischen Features (Membership-Bereiche, E-Commerce, etc.)

In diesen Fällen sparen Sie mittelfristig durch die Migration: Keine laufenden Plugin-Updates mehr, keine Security-Sorgen, keine Performance-Optimierungs-Runden. Eine statische Site braucht fast keine Wartung.

Unser Angebot

Wir bauen keine WordPress-Sites. Wir bauen statisches HTML mit Lighthouse 90+ von Tag eins an. Wenn Sie eine bestehende WordPress-Site haben, die langsam ist, bieten wir drei Optionen:

  1. Migration zu statischem HTML: Ein Festpreis-Projekt mit unseren Paketen (400–1.200 Euro). Sie bekommen einen sauberen, schnellen Ersatz.
  2. Neuaufbau mit altem Inhalt: Wir übernehmen Ihre Texte und Bilder und bauen eine neue Site mit moderner Technik.
  3. Beratung, bevor Sie eine Entscheidung treffen: 30-Minuten-Call, in dem wir gemeinsam prüfen, ob ein Umzug in Ihrem Fall Sinn macht.

Wenn Sie gar nicht sicher sind, welchen Weg Sie gehen sollen: Testen Sie Ihre aktuelle Site bei PageSpeed Insights. Wenn Sie unter 60 liegen, ist Handeln überfällig — in welche Richtung auch immer.

Festpreis-Webdesign für kleine und mittlere Unternehmen — ohne Stundensatz, ohne Überraschungen. Schauen Sie sich die Pakete an oder rufen Sie kurz an.