WordPress langsam? Die Reihenfolge, in der ich nach der Ursache suche

„Die Seite dreht sich nur noch“, höre ich oft, wenn ein Kunde anruft. Fast immer hat er schon etwas probiert — ein Cache-Plugin installiert, ein Bild verkleinert — und die Seite ist trotzdem zäh. Das liegt daran, dass man ohne Systematik meist am falschen Ende sucht. Ich gehe bei jeder langsamen WordPress-Seite dieselbe Reihenfolge durch, vom Server nach innen, weil jede Stufe die folgende verfälscht, wenn man sie überspringt.

Zuerst: Liegt es überhaupt an WordPress?

Bevor ich ein einziges Plugin anfasse, prüfe ich die Zeit bis zum ersten Byte — wie lange der Server braucht, bevor überhaupt HTML ankommt. Das geht in den Entwicklertools des Browsers unter „Netzwerk“, Spalte „Warten (TTFB)“, oder mit curl -w "%{time_starttransfer}". Liegt dieser Wert schon über einer Sekunde, ist es meist kein WordPress-Problem im engeren Sinn, sondern Hosting: zu wenig PHP-Arbeiter, ein überbuchtes Shared-Paket, oder die Seite läuft noch auf PHP 7.4. Ich habe dazu kürzlich beschrieben, welche PHP-Version im Hosting aktuell sinnvoll ist — ein Wechsel von 7.4 auf 8.3 bringt allein oft spürbar mehr Tempo, weil PHP selbst schneller geworden ist.

Dann: Was lädt die Seite wirklich?

Ist der TTFB in Ordnung, schaue ich mir die Übertragungsgröße an. Eine Startseite mit zehn Megabyte Bildern lädt langsam, ganz gleich wie gut der Server ist. Typische Fundstellen, in der Reihenfolge, in der ich sie abklappere:

• Bilder, die in voller Kameraauflösung hochgeladen und nur per CSS verkleinert wurden, statt sie vorher zuzuschneiden.
• Schriftarten, die als zusätzliche Webfont-Dateien nachgeladen werden, obwohl das Theme schon Systemschriften mitbringt.
• Eingebettete Videos von Drittanbietern, die ihr eigenes Skript laden, auch wenn der Besucher nie auf Play klickt.
• Slider- oder Animations-Plugins, die mehrere JavaScript-Bibliotheken gleichzeitig nachziehen.

Erst danach: Plugins und Datenbank

Wenn Übertragungsgröße und Bilder sauber sind, die Seite aber beim Aufbau trotzdem hängt, geht es an die Datenbank. Das häufigste, was ich dabei finde, sind aufgeblähte Autoload-Optionen: Statistik-, SEO- oder Page-Builder-Plugins, die bei jedem einzelnen Seitenaufruf Megabyte an Einstellungen aus wp_options laden, die für die aktuelle Seite gar nicht gebraucht werden. Ein Blick in ein Datenbank-Werkzeug wie phpMyAdmin oder Adminer zeigt das recht schnell: Ist die Summe der mit „yes“ markierten Autoload-Einträge größer als ein, zwei Megabyte, lohnt sich die Suche nach dem Verursacher — oft ein deinstalliertes Plugin, das seine Tabelle hinterlassen hat. Parallel dazu zähle ich die aktiven Plugins durch und deaktiviere versuchsweise, einzeln und mit Pause dazwischen, alles, was nicht unmittelbar gebraucht wird: alte Backup-Tools, doppelte SEO-Plugins, Social-Share-Buttons mit eigenem Tracking.

Lösung Schritt für Schritt

1. TTFB messen. Über einer Sekunde: zuerst mit dem Hoster klären, nicht am WordPress herumschrauben.
2. Bilder und Schriften prüfen: Originaldateien verkleinern, WebP statt JPEG/PNG, Systemschriften bevorzugen.
3. Autoload-Größe in wp_options kontrollieren, verwaiste Einträge und Tabellen aufräumen.
4. Plugins einzeln deaktivieren und jeweils die Ladezeit neu messen, statt alle auf einmal abzuschalten.
5. Erst zum Schluss ein Seiten-Cache-Plugin einrichten — es verdeckt sonst die eigentliche Ursache.

Was danach zu prüfen ist

Nach jeder Änderung einmal den Seitenaufbau im Inkognito-Fenster testen, damit kein alter Cache ein falsches Ergebnis liefert. Und das Ergebnis mit echten Werten vergleichen, nicht mit Gefühl: TTFB, Gesamtgröße der Startseite, Anzahl der geladenen Dateien. Erst wenn diese drei Zahlen stimmen, würde ich mich an Feinheiten wie weiterführende Themen rund ums Webdesign wagen.

Wie man es künftig vermeidet

Die Ursache liegt fast immer in der Summe kleiner Entscheidungen, nicht in einem einzelnen Fehler: ein Plugin zu viel, ein Bild zu groß hochgeladen, eine Funktion „sicherheitshalber“ aktiv gelassen. Wer bei jeder neuen Erweiterung kurz prüft, was sie wirklich lädt, und zweimal im Jahr die Autoload-Größe kontrolliert, muss selten die ganze Reihenfolge von vorn durchgehen. Bei neuen Projekten baue ich diese Kontrollen von Anfang an ein — Details dazu auf meiner Seite zu WordPress-Websites.

Kurz beantwortet

Welches Cache-Plugin ist das beste gegen eine langsame WordPress-Seite?

Keines, solange die eigentliche Ursache nicht behoben ist. Ein Cache-Plugin verkürzt die Ladezeit für wiederkehrende Besucher, löst aber weder einen langsamen Server noch aufgeblähte Datenbanken oder zu große Bilder.

Wie finde ich heraus, welches Plugin eine WordPress-Seite verlangsamt?

Plugins einzeln deaktivieren und nach jedem Schritt die Ladezeit neu messen, am besten mit denselben Werkzeugen wie vorher (Browser-Entwicklertools oder ein Messdienst). Wer alle auf einmal abschaltet, sieht zwar eine Besserung, aber nicht, welches Plugin dafür verantwortlich war.

Wie groß dürfen die Autoload-Optionen in wp_options sein?

Als grobe Richtschnur gilt: Unter einem Megabyte unauffällig, ab zwei, drei Megabyte lohnt sich die Suche nach dem Verursacher. Entscheidender als eine feste Grenze ist, ob der Wert nach der Installation neuer Plugins sprunghaft gestiegen ist.

Sie möchten das Thema für Ihr Unternehmen umsetzen? Mehr zu unseren Leistungen: Webdesign, SEO, GEO & AEO.