WordPress langsam? Frontend & Backend wieder schnell machen

Jeder Klick im Backend dauert mehrere Sekunden. Der Elementor-Editor lädt gefühlt ewig, das Speichern bricht ab. Und die Website selbst baut sich bei Besuchern Stück für Stück auf. Meistens wird es nicht über Nacht so schlimm, sondern schleichend, bis irgendwann jemand sagt: So geht das nicht weiter.

Der typische Reflex ist, ein weiteres Plugin zu installieren, das alles schneller machen soll. Das hilft manchmal, oft verschiebt es das Problem nur – oder verschärft es. Gehen Sie stattdessen in dieser Reihenfolge vor.

Schritt 1: Messen, wo die Zeit verloren geht

Langsam ist nicht gleich langsam. Es gibt zwei grundverschiedene Fälle:

• Der Server antwortet spät. Der Browser wartet, bevor überhaupt etwas kommt. Das betrifft Frontend und Backend gleichermaßen und liegt an PHP, Datenbank, Plugins oder dem Hosting.
• Der Server antwortet schnell, aber die Seite lädt lange. Dann liegt es an dem, was ausgeliefert wird: Bilder, Schriften, Skripte, Page-Builder-Ballast.

So unterscheiden Sie die beiden:

1. Öffnen Sie Ihre Seite in Chrome oder Edge, drücken Sie F12 und wechseln Sie auf den Reiter Netzwerk.
2. Laden Sie die Seite neu und klicken Sie auf den ersten Eintrag (das HTML-Dokument).
3. Unter Timing steht „Warten auf Serverantwort” – das ist die Server-Antwortzeit, auch TTFB genannt.

Ergänzend liefert PageSpeed Insights eine Auswertung mit konkreten Hinweisen, etwa zu Bildgrößen und blockierenden Skripten. Testen Sie Startseite und eine Unterseite, und messen Sie mehrmals – ein einzelner Wert sagt wenig.

Ist die Wartezeit auf den Server lang, lesen Sie bei Schritt 3 weiter. Ist sie kurz, die Seite aber trotzdem träge, springen Sie zu Schritt 6.

Schritt 2: Sichern, bevor Sie etwas ändern

Plugins abschalten, Datenbank aufräumen, Einstellungen ändern – all das kann Nebenwirkungen haben. Legen Sie vorher eine Sicherung von Dateien und Datenbank an. Die meisten Hoster bieten das im Kundenbereich an. Wer eine große Seite hat, testet Änderungen am besten auf einer Staging-Kopie.

Schritt 3: Den Verursacher im Backend finden

Das kostenlose Plugin Query Monitor zeigt nach der Aktivierung in der oberen Admin-Leiste, wie lange eine Seite gebraucht hat, wie viele Datenbankabfragen sie ausgelöst hat und welche davon langsam waren – inklusive des Plugins, von dem sie stammen. Unter „Queries by Component” sehen Sie, welches Plugin die meiste Last erzeugt. Unter „HTTP API Calls” steht, ob ein Plugin bei jedem Aufruf externe Server anfragt, etwa für Lizenzprüfungen oder Statistiken. Antwortet dieser Server langsam, wartet Ihr Backend mit.

Ohne Query Monitor geht es auch klassisch: Plugins einzeln deaktivieren und nach jedem Schritt messen. Fangen Sie bei denen an, die viel im Hintergrund tun – Statistik, Sicherheit, Backup, Social-Media-Feeds, Builder-Erweiterungen.

Deaktivieren Sie Query Monitor wieder, wenn Sie fertig sind.

Schritt 4: Die üblichen Bremsen auf dem Server

PHP-Version. Unter Werkzeuge → Website-Zustand → Bericht → Server steht, mit welcher PHP-Version Ihre Seite läuft. Aktuelle Versionen sind deutlich schneller als alte und bekommen Sicherheitsupdates. Läuft die Seite noch auf PHP 7.x oder 8.0/8.1, ist ein Umstieg fällig – vorher prüfen, ob Theme und Plugins damit laufen.

Speichergrenze. Page-Builder brauchen im Editor viel Arbeitsspeicher. In der wp-config.php lässt sich das Limit anheben, oberhalb von /* That's all, stop editing! */:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Die zweite Zeile gilt für den Admin-Bereich. Setzt der Server ein niedrigeres Limit, wirken die Zeilen nicht – dann muss der Tarif oder die PHP-Einstellung beim Hoster angepasst werden.

Heartbeat. WordPress fragt im geöffneten Backend regelmäßig beim Server nach, etwa für automatisches Speichern und Sperrhinweise bei gleichzeitigem Bearbeiten. Bei mehreren offenen Tabs oder Redakteuren summiert sich das. Viele Performance-Plugins können das Intervall verlängern oder Heartbeat außerhalb des Editors abschalten.

WP-Cron. Geplante Aufgaben startet WordPress standardmäßig bei Seitenaufrufen. Bei vielen oder hängenden Aufgaben bremst das. Besser ist ein echter Cronjob beim Hoster plus diese Zeile in der wp-config.php:

define( 'DISABLE_WP_CRON', true );

Wichtig: nur zusammen mit dem Cronjob, sonst laufen geplante Beiträge, Backups und E-Mails nicht mehr.

Schritt 5: Die Datenbank entrümpeln

Über die Jahre sammelt sich einiges an: Hunderte Revisionen pro Seite, abgelaufene temporäre Daten (Transients), Spam-Kommentare, Reste gelöschter Plugins. Besonders bremsend sind automatisch geladene Optionen in der Tabelle wp_options – sie werden bei jedem einzelnen Seitenaufruf geladen. Neuere WordPress-Versionen weisen im Website-Zustand darauf hin, wenn diese Menge zu groß wird.

Aufräum-Plugins wie WP-Optimize oder Advanced Database Cleaner erledigen den Großteil. Die Zahl künftiger Revisionen begrenzen Sie in der wp-config.php:

define( 'WP_POST_REVISIONS', 10 );

Löschen Sie keine Tabellen, deren Herkunft Sie nicht sicher kennen, und nur mit frischer Sicherung.

Schritt 6: Das Frontend verschlanken

Antwortet der Server schnell, liegt die Bremse in dem, was der Browser laden muss.

Bilder. Der häufigste Einzelposten. Fotos direkt aus Kamera oder Smartphone sind oft mehrere Megabyte groß und viel breiter als nötig. Bilder vor dem Hochladen verkleinern oder ein Plugin nutzen, das sie komprimiert und in WebP oder AVIF umwandelt.

Elementor und andere Page-Builder. In den Einstellungen des Builders gibt es Optionen, die die Ausgabe verschlanken und Dateien nur dort laden, wo sie gebraucht werden – prüfen Sie diese nach jedem größeren Update. Unter Elementor → Werkzeuge lassen sich CSS und Daten neu generieren, wenn nach einem Update Darstellungsfehler auftauchen. Verzichten Sie auf Zusatzpakete, aus denen Sie nur ein, zwei Widgets nutzen: Jedes Paket lädt eigene Skripte und Stile.

Externe Einbindungen. Schriften von Google-Servern, Karten, Videos, Chat-Widgets, Tracking. Jede davon kostet Ladezeit – Schriften lokal einbinden, Videos und Karten erst nach Klick laden.

Cache. Ein Seiten-Cache liefert fertige Seiten aus, statt sie jedes Mal neu zu berechnen. Welches Plugin zu welchem Hosting passt, steht im Beitrag Welches Cache-Plugin für WordPress?. Aber erst cachen, wenn die Ursachen oben geklärt sind – sonst kaschiert der Cache nur für Besucher, was im Backend weiter bremst.

Schritt 7: Wenn es am Hosting liegt

Bleibt die Server-Antwortzeit hoch, obwohl Plugins, Datenbank und PHP-Version in Ordnung sind, ist der Server das Problem. Bei günstigem Shared Hosting teilen sich viele Websites dieselbe Maschine, und Tarife begrenzen häufig Rechenzeit, Arbeitsspeicher und die Zahl gleichzeitiger PHP-Prozesse. Wird das Limit erreicht, warten Anfragen in der Schlange – Ihr Backend fühlt sich dann zu Stoßzeiten zäh an und abends wieder normal.

Prüfen Sie im Kundenbereich, ob Ihr Tarif Ressourcenwerte oder Auslastungsgrafiken zeigt. Werfen Sie außerdem einen Blick ins Zugriffsprotokoll: Massenhafte Aufrufe von wp-login.php oder xmlrpc.php stammen meist von automatisierten Anmeldeversuchen und belasten den Server unnötig. Ein Sicherheits-Plugin oder eine Sperre auf Serverebene schafft hier Ruhe.

Reicht der Tarif nicht mehr, ist ein Wechsel auf einen Server mit garantierten Ressourcen, aktuellem PHP, OPcache und Objekt-Cache (etwa Redis) der nachhaltigere Weg als jedes weitere Optimierungs-Plugin. Das ist der Kern unseres Managed Hostings.

Umsetzungsplan

Sofort

1. Server-Antwortzeit messen (F12 → Netzwerk → Timing) und PageSpeed Insights für Startseite und eine Unterseite laufen lassen.
2. Vollständige Sicherung von Dateien und Datenbank anlegen.
3. Query Monitor aktivieren und das Plugin mit der meisten Last bzw. langsamen externen Aufrufen ermitteln.

Danach

4. PHP-Version prüfen und auf eine aktuelle Version umstellen, nach Kompatibilitätstest.
5. Speichergrenze anheben, Heartbeat drosseln, WP-Cron auf einen echten Cronjob umstellen.
6. Datenbank aufräumen: Revisionen, Transients, Spam, verwaiste Optionen; Revisionen künftig begrenzen.
7. Bilder verkleinern und in moderne Formate umwandeln, unnötige Builder-Erweiterungen entfernen.
8. Seiten-Cache einrichten und die Messung aus Schritt 1 wiederholen.

Vorbeugen

9. Neue Plugins vor der Installation kritisch prüfen – jedes zusätzliche Plugin ist potenzielle Last.
10. Updates regelmäßig einspielen und die Ladezeit nach größeren Änderungen erneut messen.
11. Reicht das Hosting dauerhaft nicht, auf einen Tarif mit garantierten Ressourcen wechseln.

Wer die Geschwindigkeit nicht nur reparieren, sondern gezielt verbessern will – etwa für bessere Werte bei Google –, findet den Weg unter Ladezeit-Optimierung.

Wenn Sie nicht weiterkommen

Oft ist es nicht eine Ursache, sondern mehrere, die sich gegenseitig verstärken: ein knapper Tarif, ein schwerer Page-Builder und ein Plugin, das im Hintergrund ständig fremde Server anfragt. Dann bringt jede einzelne Maßnahme wenig, und erst die Kombination wirkt.

Die WordPress-Notfall-Diagnose kostet 99 € – mit Sicherung, Auslesen der Fehlerprotokolle und einem Festpreis-Angebot für die Reparatur; bei Beauftragung wird der Betrag angerechnet. Oder rufen Sie direkt an: 0 33 41 - 35 66 146.

Häufige Fragen

Warum ist mein WordPress-Backend so langsam, obwohl die Website schnell lädt?

Besucher bekommen meist eine zwischengespeicherte Fassung der Seite ausgeliefert, das Backend dagegen wird bei jedem Klick neu berechnet. Ein Cache-Plugin verdeckt also Probleme, die im Admin-Bereich voll durchschlagen. Typische Ursachen sind Plugins, die bei jedem Seitenaufruf im Backend Abfragen oder externe Verbindungen ausführen, eine überladene Datenbank, die Heartbeat-Funktion, eine zu knappe Speichergrenze oder ein ausgelasteter Server.

Macht Elementor WordPress langsam?

Page-Builder wie Elementor, Divi oder WPBakery erzeugen mehr HTML, CSS und JavaScript als ein schlankes Theme und brauchen im Editor deutlich mehr Arbeitsspeicher. Langsam wird es vor allem, wenn viele Zusatz-Plugins für den Builder installiert sind, Abschnitte tief verschachtelt sind und die Optimierungsoptionen des Builders nicht genutzt werden. Mit sauberem Aufbau, ausreichendem Speicher und einem Cache lässt sich auch eine Elementor-Seite schnell betreiben.

Liegt es an meinem Hosting?

Das zeigt die Server-Antwortzeit (TTFB). Ist sie schon bei einer einfachen Seite hoch, obwohl kaum Plugins aktiv sind, oder schwankt sie stark je nach Tageszeit, deutet das auf einen ausgelasteten oder zu knapp bemessenen Server hin. Bei günstigem Shared Hosting teilen sich viele Websites dieselben Ressourcen, und Tarife begrenzen oft Rechenzeit, Arbeitsspeicher und gleichzeitige PHP-Prozesse.

Reicht ein Cache-Plugin, um WordPress schnell zu machen?

Ein Cache-Plugin beschleunigt die Auslieferung fertiger Seiten an Besucher und ist fast immer sinnvoll. Es behebt aber nicht die Ursache, wenn der Server selbst langsam rechnet, ein Plugin Last erzeugt oder Bilder viel zu groß sind. Außerdem bleiben das Backend, der Warenkorb und eingeloggte Nutzer meist ungecacht. Erst die Ursache finden, dann cachen.

Was kostet es, wenn Sie das für mich übernehmen?

Den Einstieg bildet die WordPress-Notfall-Diagnose für 99 €: Wir sichern die Website, lesen die Protokolle aus, messen, wo die Zeit verloren geht, und schicken Ihnen ein verbindliches Festpreis-Angebot für die Behebung. Beauftragen Sie diese, werden die 99 € voll angerechnet.