WordPress langsam? Ursachen finden und Ladezeit senken

Wenn WordPress langsam ist, liegt die Ursache fast immer auf einer von drei Ebenen: beim Server (PHP, Ressourcen, fehlender Cache), in der Anwendung (Plugins, Datenbank, WP-Cron) oder im Frontend (Bilder, Skripte). Messen Sie deshalb zuerst die Antwortzeit des Servers getrennt von der Ladezeit im Browser und arbeiten Sie sich dann Ebene für Ebene vor. So beheben Sie die tatsächliche Bremse, statt auf Verdacht das nächste Optimierungs-Plugin zu installieren.

Warum ist WordPress langsam? Die drei Ebenen im Überblick

WordPress erzeugt jede Seite dynamisch: PHP lädt den Kern, alle aktiven Plugins und das Theme, fragt die Datenbank ab und baut daraus HTML. Erst danach lädt der Browser Bilder, CSS und JavaScript. Jeder dieser Schritte kann der Engpass sein.

Server-Ebene: veraltete PHP-Version, deaktivierter OPcache, zu wenige PHP-FPM-Prozesse, ausgelastete CPU oder langsamer Speicher.
Anwendungs-Ebene: schwergewichtige Plugins, aufgeblähte Datenbank, langsame externe API-Aufrufe, WP-Cron, das bei Besucheraufrufen startet.
Frontend-Ebene: unkomprimierte Bilder, viele Skripte, Webfonts und Drittanbieter-Einbindungen.

Die meisten Ratgeber springen direkt zu Bildkompression und Caching-Plugins. Das hilft nur, wenn das Problem tatsächlich dort liegt. Ein Server, der zwei Sekunden für das HTML braucht, wird durch kleinere Bilder nicht schneller.

Erst messen: Serverantwortzeit und Ladezeit trennen

Die wichtigste Messgröße ist die Time to First Byte (TTFB): Sie zeigt, wie lange der Server braucht, bis das erste Byte der Seite ankommt, und trennt damit Server- und Anwendungsprobleme sauber von Frontend-Problemen.

Mit curl messen Sie das ohne Browser-Einflüsse direkt von der Kommandozeile:

curl -o /dev/null -s -w "DNS:        %{time_namelookup}\nVerbindung: %{time_connect}\nTLS:        %{time_appconnect}\nTTFB:       %{time_starttransfer}\nGesamt:     %{time_total}\n" https://www.example.de/

Wiederholen Sie die Messung mehrmals und vergleichen Sie drei Fälle:

Startseite als normaler Besucher (vermutlich aus dem Page-Cache).
Dieselbe Seite mit angehängtem Parameter wie ?nocache=1, der den Cache bei vielen Setups umgeht.
Eine Seite im Backend oder eine Warenkorbseite, die nie gecacht wird.

Google stuft eine TTFB bis 800 Millisekunden als gut ein, für den Largest Contentful Paint gelten 2,5 Sekunden als Richtwert. Ist die TTFB ungecacht deutlich höher, liegt das Problem auf dem Server oder in WordPress selbst. Ist die TTFB niedrig, die Seite im Browser aber trotzdem träge, suchen Sie im Frontend weiter.

Server-Ursachen: PHP, OPcache und PHP-FPM prüfen

PHP-Version

Neuere PHP-Versionen arbeiten spürbar effizienter und erhalten Sicherheitsupdates. Läuft Ihre Website noch auf einer Version ohne Support, ist das Update gleich doppelt sinnvoll. Wie Sie dabei Kompatibilität prüfen und ohne Ausfall wechseln, beschreibt der Beitrag PHP-Version aktualisieren und ohne Ausfall umschalten.

OPcache

Ohne OPcache kompiliert PHP bei jedem Aufruf alle Dateien neu. Prüfen Sie die Konfiguration des FPM-Pools, nicht die der Kommandozeile, denn beide können unterschiedlich eingestellt sein:

grep -r "opcache.enable\|opcache.memory_consumption\|opcache.max_accelerated_files" /etc/php/8.3/fpm/

Sinnvolle Ausgangswerte für eine typische WordPress-Installation:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60

PHP-FPM-Prozesse

Reichen die PHP-Worker nicht aus, warten Anfragen in einer Schlange. Das äußert sich in schwankenden, unter Last stark steigenden Antwortzeiten. Ein eindeutiges Indiz steht im FPM-Log:

grep "max_children" /var/log/php8.3-fpm.log
# WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

Den Grenzwert berechnen Sie aus dem Arbeitsspeicher, den Sie PHP zugestehen, geteilt durch den durchschnittlichen Verbrauch eines Prozesses:

ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1} END {print s/NR/1024 " MB pro Prozess"}'

Ein Beispiel für einen Server mit rund 4 GB, von denen etwa 2 GB für PHP vorgesehen sind und jeder Prozess etwa 80 MB belegt:

pm = dynamic
pm.max_children = 24
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 8
pm.max_requests = 500

Setzen Sie den Wert nicht höher, als der Speicher hergibt. Sonst beginnt das System zu swappen, und alles wird langsamer.

CPU, Speicher und I/O

Ein Blick in top oder vmstat 1 10 zeigt, ob die Maschine an ihre Grenzen stößt. Achten Sie auf hohe Werte bei wa (Warten auf Datenträger) und st (Steal Time, also Rechenzeit, die der Virtualisierungsschicht fehlt). Dauerhafte Steal Time deutet auf überbuchte Hardware beim Anbieter hin. Ob mehr Ressourcen tatsächlich nötig sind, klären Sie besser mit Messwerten als mit einem Upgrade auf Verdacht. Hilfreich dafür ist der Beitrag Server richtig dimensionieren.

WordPress-Ursachen: Plugins, Datenbank und WP-Cron

Plugins messen statt zählen

Nicht die Anzahl der Plugins entscheidet, sondern was sie tun. Ein einzelnes Plugin, das bei jedem Seitenaufruf eine externe API abfragt, bremst stärker als zwanzig schlanke. Das Plugin Query Monitor zeigt pro Seitenaufruf langsame Datenbankabfragen, externe HTTP-Anfragen und welches Plugin sie auslöst. Auf der Kommandozeile hilft das WP-CLI-Paket profile-command:

wp package install wp-cli/profile-command
wp profile stage --url=https://www.example.de/
wp profile hook --all --spotlight --url=https://www.example.de/

Testen Sie verdächtige Plugins in einer Testumgebung, indem Sie sie einzeln deaktivieren und die TTFB erneut messen. Auf dem Live-System riskieren Sie sonst Funktionsausfälle.

Autoload-Optionen in der Datenbank

WordPress lädt bei jedem Aufruf alle Einträge aus wp_options, die als Autoload markiert sind. Gelöschte Plugins hinterlassen dort oft große Datenmengen. So prüfen Sie die Größe:

SELECT SUM(LENGTH(option_value)) / 1024 AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

SELECT option_name, LENGTH(option_value) / 1024 AS kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC LIMIT 20;

Die Website-Zustand-Prüfung aktueller WordPress-Versionen warnt ab etwa 800 KB. Große Einträge alter Plugins können Sie nach einem Backup entfernen oder auf Autoload off setzen. Abgelaufene Transients räumen Sie mit wp transient delete --expired auf.

WP-Cron vom Besucher entkoppeln

Standardmäßig startet WordPress geplante Aufgaben, wenn jemand die Seite aufruft. Bei aufwendigen Jobs wartet dann ein Besucher. Besser ist ein echter Cronjob auf dem Server. In der wp-config.php:

define( 'DISABLE_WP_CRON', true );

Und in der Crontab des Webserver-Benutzers:

*/5 * * * * wp cron event run --due-now --path=/var/www/html > /dev/null 2>&1

Caching richtig einsetzen: Page-Cache und Object-Cache

Caching ist wirksam, verdeckt aber Ursachen. Deshalb kommt es in dieser Reihenfolge erst nach der Diagnose.

Page-Cache speichert fertiges HTML und liefert es ohne PHP aus. Das beschleunigt anonyme Besucher stark, hilft aber nicht bei eingeloggten Nutzern, im Backend oder im Warenkorb.
Object-Cache mit Redis hält Ergebnisse von Datenbankabfragen im Arbeitsspeicher. Er wirkt genau dort, wo der Page-Cache nicht greift, etwa im Backend oder bei Shops.
Browser-Cache über passende Cache-Header sorgt dafür, dass wiederkehrende Besucher statische Dateien nicht erneut laden.

Ein häufiger Fehler: zwei Caching-Plugins gleichzeitig oder ein Plugin-Cache zusätzlich zu einem Server-Cache. Das führt zu veralteten Inhalten und schwer nachvollziehbarem Verhalten. Entscheiden Sie sich pro Ebene für genau eine Lösung.

Frontend: wenn die TTFB gut ist, die Seite aber träge wirkt

Liefert der Server schnell, liegt das Problem im Browser. Prüfen Sie im Entwicklerwerkzeug unter Netzwerk, welche Dateien am größten sind und am längsten laden. Typische Hebel sind moderne Bildformate wie WebP oder AVIF, passend skalierte Bilder, Lazy Loading unterhalb des sichtbaren Bereichs und das Entfernen nicht genutzter Skripte. Besonders Drittanbieter-Einbindungen wie Chat-Widgets, Tracking oder eingebettete Karten verlängern die Ladezeit, ohne dass Sie deren Server beeinflussen können.

Checkliste: In dieser Reihenfolge vorgehen

TTFB gecacht und ungecacht mit curl messen und notieren.
PHP-Version und OPcache-Konfiguration des FPM-Pools prüfen.
FPM-Log auf max_children-Warnungen durchsuchen, Worker anhand des Speichers einstellen.
CPU, Arbeitsspeicher, I/O-Wartezeit und Steal Time beobachten.
Mit Query Monitor oder wp profile langsame Plugins und externe Aufrufe identifizieren.
Autoload-Größe und Transients prüfen und aufräumen, vorher sichern.
WP-Cron auf einen System-Cronjob umstellen.
Page-Cache und Object-Cache einrichten, jeweils nur eine Lösung pro Ebene.
Erst dann Bilder, Skripte und Drittanbieter-Einbindungen optimieren.
Nach jeder Änderung erneut messen, damit Sie wissen, was gewirkt hat.

Wann liegt es am Hosting?

Bleibt die ungecachte TTFB hoch, obwohl PHP aktuell ist, OPcache läuft, die Worker passen und kein Plugin auffällt, ist die Plattform selbst ein Kandidat. Hinweise darauf sind dauerhafte Steal Time, hohe I/O-Wartezeiten trotz geringer Last oder fehlende Möglichkeiten, PHP-FPM, OPcache und Redis überhaupt zu konfigurieren. Auf einfachem Shared Hosting haben Sie auf diese Stellschrauben oft keinen Zugriff.

Ob Sie die Optimierung selbst übernehmen oder den Betrieb abgeben, hängt von Ihren internen Kapazitäten ab. Eine Möglichkeit ist das WordPress-Hosting von NETARO in Frankfurt, das PHP-FPM mit OPcache, Redis-Cache, WebP und AVIF, WP-CLI und eine Testumgebung mitbringt. In der Managed-Variante übernimmt NETARO Updates gegen vorheriges Backup, tägliche Sicherungen mit Rückspielprobe und die Überwachung rund um die Uhr. Wer mehr Kontrolle braucht, kann WordPress auch auf einem eigenen Cloud Server mit Root-Zugriff betreiben und die hier beschriebenen Einstellungen selbst vornehmen.

FAQ

Warum ist das WordPress-Backend langsam, das Frontend aber schnell?

Das Frontend wird meist aus dem Page-Cache ausgeliefert, das Backend nie. Dort zeigen sich deshalb die echten Kosten von PHP, Datenbank und Plugins. Typische Ursachen sind große Autoload-Optionen, Plugins mit externen API-Aufrufen im Admin-Bereich und ein fehlender Object-Cache.

Wie viele Plugins sind zu viel?

Eine feste Grenze gibt es nicht. Entscheidend ist, wie viel Rechenzeit und wie viele Datenbankabfragen ein Plugin pro Aufruf verursacht. Messen Sie mit Query Monitor oder wp profile und entfernen Sie Plugins, die viel kosten und wenig Nutzen bringen.

Hilft ein Caching-Plugin immer, wenn WordPress langsam ist?

Nur für anonyme Besucher auf cachebaren Seiten. Bei eingeloggten Nutzern, Shops und im Backend wirkt ein Page-Cache kaum. Außerdem verdeckt er Ursachen auf Server- und Anwendungsebene, die bei jedem ungecachten Aufruf weiter bremsen.

Wie schnell sollte eine WordPress-Seite laden?

Als Orientierung dienen die Richtwerte von Google: eine TTFB bis 800 Millisekunden und ein Largest Contentful Paint bis 2,5 Sekunden gelten als gut. Messen Sie beide Werte getrennt, damit Sie wissen, ob Sie am Server oder im Frontend ansetzen müssen.

WordPress langsam: So finden Sie heraus, ob Server, Plugins oder Datenbank bremsen