WordPress-Backend langsam: Ursachen finden

Q: Warum ist das WordPress-Backend langsam, die Website aber schnell?

Weil der Admin-Bereich nicht aus dem Seiten-Cache kommt. Besucher bekommen fertige Seiten aus dem Cache. Im Backend baut der Server jede Seite neu, mit allen Plugins und Datenbankabfragen. Bremsen dort fallen deshalb nur angemeldeten Nutzern auf.

Q: Hilft ein Cache-Plugin gegen ein langsames Backend?

Ein Seiten-Cache kaum, ein Objekt-Cache schon. Seiten-Caches greifen nur für nicht angemeldete Besucher. Ein persistenter Objekt-Cache mit Redis oder Memcached beschleunigt dagegen auch das Backend, wenn der Hoster ihn anbietet.

Q: Wie finde ich heraus, welches Plugin das Backend bremst?

Mit dem Plugin Query Monitor. Es zeigt Datenbankabfragen und externe Anfragen je Plugin samt Dauer. Bleibt es unklar, deaktivieren Sie auf einer Kopie der Website ein Plugin nach dem anderen und messen jedes Mal.

Q: Kann ich die Heartbeat-API ganz abschalten?

Besser nicht, vergrößern Sie lieber den Abstand. Die Heartbeat-API verhindert, dass zwei Personen denselben Beitrag gleichzeitig bearbeiten, und hält die Anmeldung aktiv. Ein Abstand von zwei Minuten entlastet den Server, ohne diese Funktionen zu verlieren.

Das Dashboard braucht Sekunden, der Editor hängt, jede Liste lädt zäh. Die Website draußen ist dabei oft schnell. Hier sehen Sie, warum der Admin-Bereich eigene Bremsen hat, wie Sie die Ursache messen und was wirklich hilft.

Erst messenQuery Monitor und Website-Zustand zeigen die Bremse
Admin ohne Seiten-CacheJeder Klick startet WordPress komplett
Gezielt behebenPlugins, autoload, Heartbeat, Cron, Server

Symptom und wahrscheinliche UrsacheSchnelldiagnose

Jede Admin-Seite langsamautoload-Daten, fehlender Objekt-Cache, Server am Limit. ÜBERALL
Nur bestimmte SeitenEin Plugin rechnet dort Statistiken oder fragt fremde Server ab. PLUGIN
Nur der EditorPage-Builder, sehr lange Seiten, Browser-Erweiterungen. EDITOR
Mal schnell, mal trägeGeplante Aufgaben oder belegte PHP-Worker. ZEITWEISE

Wo es langsam ist, verrät meist schon, woran es liegt.

Warum das Backend eigene Bremsen hat

Besucher bekommen meist eine fertige Kopie der Seite aus dem Seiten-Cache. Angemeldete Nutzer nicht. Im Admin-Bereich baut der Server jede Seite neu: PHP startet, alle aktiven Plugins laden, die Datenbank antwortet auf Dutzende bis Hunderte Abfragen. Dazu kommen Anfragen im Hintergrund. Der Editor spricht laufend mit der REST-API, die Heartbeat-API meldet sich regelmäßig über admin-ajax.php. Ein Cache-Plugin hilft hier deshalb kaum. Tipps für das Tempo der öffentlichen Seiten finden Sie unter WordPress schneller machen.

Frontend und Backend im Vergleich

BesucherFertige Seite aus dem Cache, wenig Serverarbeit. CACHE
Angemeldet im AdminJede Seite frisch aus PHP und Datenbank. LIVE
HintergrundHeartbeat, REST-API, geplante Aufgaben. ZUSATZ

Was im Backend bremst, zeigt nur eine Messung im Backend.

Die Ursache finden in fünf Schritten

Raten kostet Zeit. Gehen Sie in dieser Reihenfolge vor und notieren Sie, was sich ändert.

1
Eingrenzen
Ist jede Admin-Seite langsam oder nur eine? Öffnen Sie das Backend zum Vergleich in einem privaten Fenster ohne Browser-Erweiterungen. Wird es dort schnell, liegt die Bremse im Browser, nicht auf dem Server.
2
Website-Zustand prüfen
Unter Werkzeuge → Website-Zustand meldet WordPress eine veraltete PHP-Version, zu große automatisch geladene Optionen, fehlgeschlagene geplante Ereignisse und einen fehlenden Objekt-Cache. Diese Hinweise sind ein guter Start.
3
Query Monitor einsetzen
Das kostenlose Plugin zeigt in der Admin-Leiste Ladezeit, Speicher und Zahl der Datenbankabfragen. Öffnen Sie damit die langsame Seite. Die Ansicht Queries by Component zeigt, welches Plugin die meisten und langsamsten Abfragen erzeugt.
Unter HTTP API Calls sehen Sie Anfragen an fremde Server mit ihrer Dauer. Ein Lizenz- oder Statistikabruf, der jedes Mal zwei Sekunden wartet, fällt dort sofort auf. Deaktivieren Sie Query Monitor nach der Analyse wieder.
4
Im Browser messen
Öffnen Sie die Entwicklertools mit F12 und dort den Tab Netzwerk. Laden Sie die Admin-Seite neu. Braucht schon die erste Anfrage lange, bis der Server antwortet, arbeitet der Server. Hängen danach viele Anfragen an admin-ajax.php oder /wp-json/, liegt es an Hintergrundanfragen.
5
Plugins auf einer Kopie abschalten
Bleibt die Ursache offen, deaktivieren Sie auf einer Kopie ein Plugin nach dem anderen und messen jedes Mal. So finden Sie den Auslöser, ohne die echte Website zu gefährden. Wie das sauber geht, zeigt Plugins deaktivieren.
Was ist ein Staging?

Die sechs häufigsten Ursachen

Fast jedes träge Backend lässt sich auf eine dieser Stellen zurückführen. Oft sind es zwei zugleich.

Plugins mit Admin-Last

Manche Plugins bauen bei jedem Aufruf Dashboard-Widgets mit Statistiken, prüfen Lizenzen oder laden Neuigkeiten vom Hersteller. Antwortet dessen Server langsam, wartet Ihr Backend mit. Schalten Sie solche Funktionen in den Plugin-Einstellungen ab oder ersetzen Sie das Plugin. Nur ausblenden reicht oft nicht.

Zu viele autoload-Daten

Einträge in wp_options mit Autoload lädt WordPress bei jedem Aufruf. Ab etwa 800 KB warnt der Website-Zustand. Oft stammen große Einträge von längst gelöschten Plugins.

Kein Objekt-Cache

Ohne persistenten Objekt-Cache stellt WordPress dieselben Datenbankabfragen bei jedem Klick neu. Redis oder Memcached halten die Ergebnisse im Arbeitsspeicher. Das hilft vor allem Shops und großen Websites. Der Hoster muss den Dienst anbieten.

Server am Limit

Die PHP-Worker bestimmen, wie viele Anfragen gleichzeitig laufen. Sind alle belegt, wartet jeder weitere Klick. Eine alte PHP-Version und zu wenig Speicher bremsen zusätzlich.

PHP-Version prüfen

Geplante Aufgaben

WP-Cron startet Sicherungen, Importe und Newsletter bei Seitenaufrufen. WooCommerce arbeitet zusätzlich eine eigene Warteschlange ab und stößt sie auch aus dem Admin-Bereich an. Hängen dort Tausende Aufgaben, bremst das jeden Klick.

Heartbeat-API

Jeder offene Admin-Tab fragt den Server im Standard einmal pro Minute ab, jede Abfrage startet WordPress komplett. Fünf offene Tabs heißen fünf Anfragen pro Minute. Tabs im Hintergrund drosselt WordPress selbst auf zwei Minuten.

Heartbeat, Cron und Warteschlange entlasten

Diese Eingriffe erfordern Zugriff auf Dateien oder das Hosting-Panel. Legen Sie vorher eine Sicherung an.

1
Heartbeat drosseln, nicht abschalten
Die Heartbeat-API sperrt Beiträge gegen gleichzeitiges Bearbeiten und hält die Anmeldung aktiv. Schalten Sie sie deshalb nicht ganz ab. Den Abstand vergrößern Sie mit diesem Filter, etwa in einem kleinen eigenen Plugin oder im Child-Theme:
```
add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 120; // Sekunden
    return $settings;
} );
```
Ältere Anleitungen nennen dafür ein Plugin, das seit Langem nicht mehr gepflegt wird. Prüfen Sie bei jedem Plugin „Zuletzt aktualisiert“ auf wordpress.org.
2
WP-Cron durch einen echten Cronjob ersetzen
Setzen Sie in der wp-config.php diese Zeile. Legen Sie dann beim Hoster einen Cronjob an, der alle fünf Minuten https://ihre-domain.de/wp-cron.php aufruft. Wie Sie die Datei sicher ändern, zeigt wp-config.php bearbeiten.
```
define( 'DISABLE_WP_CRON', true );
```
Ohne den Cronjob beim Hoster laufen danach keine Sicherungen und keine geplanten Beiträge mehr.
3
Die WooCommerce-Warteschlange prüfen
Sie finden sie unter WooCommerce → Status → Geplante Aktionen. Viele Einträge mit dem Status „Ausstehend“ oder „Überfällig“ deuten auf einen hängenden Prozess hin. Klären Sie zuerst, welches Plugin sie erzeugt, bevor Sie etwas löschen.

Wenn nur Editor oder Listen hängen

Ist nur eine Stelle im Backend langsam, liegt die Ursache meist genau dort.

Beitrags- und Produktlisten: Stellen Sie unter Ansicht anpassen die Einträge pro Seite zurück auf 20. Hunderte Zeilen auf einmal kosten viele Abfragen.
Block-Editor: Sehr lange Seiten mit Hunderten Blöcken laden spürbar langsamer. Teilen Sie solche Inhalte auf mehrere Seiten auf.
Page-Builder: Elementor und ähnliche Editoren brauchen viel Speicher im Browser und auf dem Server. Hilfe bei Ladeproblemen bietet Elementor lädt nicht.
Speichern dauert lange: Tausende alte Revisionen blähen die Datenbank auf. Wie Sie sie begrenzen, zeigt Revisionen löschen.

Wann Sie besser Hilfe holen

Ein Dashboard-Widget schließen oder ein Plugin ersetzen schaffen Sie selbst. Eingriffe in Datenbank, Server und Cron brauchen Erfahrung und eine Sicherung, sonst steht schnell die ganze Website.

Query Monitor zeigt langsame Abfragen, aber Sie wissen nicht, was Sie damit tun sollen.
Die Warteschlange oder die autoload-Daten sind stark gewachsen.
Das Backend bleibt trotz aller Schritte langsam und der Hoster sieht kein Problem.

WordPress-Hilfe auch für Nicht-Kunden

Wir messen Ihr Backend, räumen Plugins und Datenbank auf und halten die Website danach schnell. Das gehört zu unserer Website-Betreuung.

Nachricht oder Termin WordPress-Hilfe im Notfall

Fragen zum langsamen Backend

Warum ist das WordPress-Backend langsam, die Website aber schnell?

Weil der Admin-Bereich nicht aus dem Seiten-Cache kommt. Besucher bekommen fertige Seiten aus dem Cache. Im Backend baut der Server jede Seite neu, mit allen Plugins und Datenbankabfragen. Bremsen dort fallen deshalb nur angemeldeten Nutzern auf.

Hilft ein Cache-Plugin gegen ein langsames Backend?

Ein Seiten-Cache kaum, ein Objekt-Cache schon. Seiten-Caches greifen nur für nicht angemeldete Besucher. Ein persistenter Objekt-Cache mit Redis oder Memcached beschleunigt dagegen auch das Backend, wenn der Hoster ihn anbietet.

Wie finde ich heraus, welches Plugin das Backend bremst?

Mit dem Plugin Query Monitor. Es zeigt Datenbankabfragen und externe Anfragen je Plugin samt Dauer. Bleibt es unklar, deaktivieren Sie auf einer Kopie der Website ein Plugin nach dem anderen und messen jedes Mal.

Kann ich die Heartbeat-API ganz abschalten?

Besser nicht, vergrößern Sie lieber den Abstand. Die Heartbeat-API verhindert, dass zwei Personen denselben Beitrag gleichzeitig bearbeiten, und hält die Anmeldung aktiv. Ein Abstand von zwei Minuten entlastet den Server, ohne diese Funktionen zu verlieren.

Backend zu langsam? Wir finden die Ursache

Termin vereinbaren

30 Minuten am Telefon oder per Video. Sie wählen einen freien Termin im Kalender.

Termin wählen

Nachricht schicken

Schildern Sie kurz, worum es geht. Sie bekommen innerhalb von 24 Stunden an Werktagen eine Antwort.

Zum Formular

WordPress-Backend langsam: Ursachen finden

Warum das Backend eigene Bremsen hat

Die Ursache finden in fünf Schritten

Eingrenzen

Website-Zustand prüfen

Query Monitor einsetzen

Im Browser messen

Plugins auf einer Kopie abschalten

Die sechs häufigsten Ursachen

Plugins mit Admin-Last

Zu viele autoload-Daten

Kein Objekt-Cache

Server am Limit

Geplante Aufgaben

Heartbeat-API

Heartbeat, Cron und Warteschlange entlasten

Heartbeat drosseln, nicht abschalten

WP-Cron durch einen echten Cronjob ersetzen

Die WooCommerce-Warteschlange prüfen

Wenn nur Editor oder Listen hängen

Wann Sie besser Hilfe holen

Fragen zum langsamen Backend

Warum ist das WordPress-Backend langsam, die Website aber schnell?

Hilft ein Cache-Plugin gegen ein langsames Backend?

Wie finde ich heraus, welches Plugin das Backend bremst?

Kann ich die Heartbeat-API ganz abschalten?

Verwandte Themen

WordPress-Caching: welches Cache-Plugin passt?

WordPress-Plugins deaktivieren: auch ohne Backend

WordPress schneller machen: Ursachen und Lösungen

WordPress PHP-Version: Welche? Prüfen und ändern

WordPress-Hosting, PHP-Update und Cache

Backend zu langsam? Wir finden die Ursache