Warum ist mein WordPress-Backend so langsam?

Warum Ihr WordPress-Dashboard langsam ist

Wenn Ihr WordPress-Backend langsam ist – oder sich das WordPress-Dashboard sehr langsam anfühlt, während das Frontend schnell ist –, dann bilden Sie sich das nicht ein. Ein langsames WordPress-Backend gehört zu den häufigsten Beschwerden von Website-Betreibern, nachdem die öffentliche Site optimiert wurde. Caching-Plugins lassen wp-admin aus. Ihr CDN fasst das Backend nicht an. Jeder Klick im WordPress-Backend startet einen frischen PHP-Request, lädt die Admin-Hooks jedes aktiven Plugins und zieht Ihr komplettes autoloaded Daten-Set aus wp_options.

Caching-Plugins helfen hier nicht – sie überspringen Admin-Seiten absichtlich. Das CDN hilft nicht – das Backend ist dynamisch. Die Langsamkeit kommt aus WordPress selbst.

WordPress-Backend langsam, Frontend schnell? Finden Sie Ihr Symptom

„WordPress-Backend sehr langsam" ist nicht ein Problem – es sind fünf oder sechs verschiedene, die sich vom Dashboard aus alle gleich anfühlen. Suchen Sie unten Ihr genaues Symptom: Die Ursachenspalte nennt den Mechanismus, der dahintersteckt, und der nächste Schritt sagt Ihnen, was Sie konkret tun sollen.

Schritt 0: Die ganze Site prüfen, bevor Sie irgendetwas einzeln messen

Alles unterhalb dieses Abschnitts misst jeweils eine Sache. Bevor Sie 15 Minuten damit per Hand verbringen, investieren Sie eine Minute in Site Doctor in WP Multitool: Es führt den ganzen Satz Prüfungen in einem Durchgang aus – OPcache, das Object-Cache-Drop-in, Redis-Zustand, eine Page-Cache-Probe, Optimizer-Überschneidungen, Datenbank-Ballast – und sortiert die Befunde nach Schwere, jeder mit dem Modul verlinkt, das ihn behebt.

Noch kein Plugin installiert? Die kostenlose /scan/-Seite misst TTFB und Komprimierung von außen, was Ihnen sagt, ob der Server schon langsam ist, bevor der Browser ein Byte bekommt. Sie führt keine der obigen Prüfungen aus – die müssen auf dem Server laufen – also: sobald Sie die externe Zahl haben, installieren Sie WP Multitool und führen Sie den Scan aus. Site Doctor steckt in Lite wie in Pro; die Autoload- und Slow-Query-Quellen, die es liest, sind nur in Pro, und ein Lite-Scan nennt diese beiden als übersprungene Quellen, statt eine kurze Liste als saubere Site wirken zu lassen.

Wann Multitool die falsche erste Antwort ist: Wenn Sie einen bestimmten Request debuggen und schon wissen, welchen, öffnen Sie ihn mit Query Monitor; wenn es darum geht, das öffentliche Frontend für abgemeldete Besucher schnell zu machen, ist ein Page-Cache-Plugin gefragt, keine Diagnose-Prüfung.

Der Scan liefert Ihnen die Vorauswahl. Die Tiefe pro Request und pro Callback kommt weiterhin von Query Monitor und dem Slow Callback Finder weiter unten auf dieser Seite – die sortierte Liste sagt Ihnen nur, welches sich zu öffnen lohnt. Die vollständige Checkliste, die Redis-Checkliste und die WP-CLI-Nutzung stehen in der Site Doctor-Doku; wenn Sie es lieber per Hand machen, leistet die 15-Minuten-Checkliste unten dieselbe Arbeit mit DevTools und SQL.

Warum ist mein WordPress-Dashboard langsam? (Dashboard vs. der Rest von wp-admin)

„Langsames Dashboard" und „langsames wp-admin" werden synonym benutzt. Es sind zwei verschiedene Probleme. Die Dashboard-Startseite (/wp-admin/index.php) erledigt Arbeit, die keine andere Admin-Seite erledigt – klären Sie also zuerst, welches der beiden Sie haben.

Der Test dauert eine Minute. Laden Sie /wp-admin/, dann Einstellungen → Allgemein, und vergleichen Sie die Ladezeiten des Dokuments in den DevTools. Ist das Dashboard 2 Sekunden oder mehr langsamer, sind es die Widgets – entfernen Sie die, die Sie nicht täglich brauchen, mit dem wp_dashboard_setup-Snippet aus dem Abschnitt zu den schnellen Erfolgen. Widgets mit externen HTTP-Aufrufen sind die schlimmsten Übeltäter: Die Seite wartet auf den Server von jemand anderem.

Sind beide Seiten gleich langsam, liegt es nicht am Dashboard – dann ist ganz wp-admin betroffen. Das sind die Autoload-Größe und die admin_init-Callbacks, behandelt in den Ursachen weiter unten. Zuerst die Dashboard-Widgets zu reparieren bringt Ihnen in diesem Fall nichts für die anderen 40 Seiten, die Sie täglich benutzen.

4 echte Ursachen für ein langsames WordPress-Backend

1. Engpass admin-ajax.php

WordPress leitet alle AJAX-Requests über eine einzige Datei: admin-ajax.php. Jeder Request startet den kompletten WordPress-Stack. Wenn 5 Plugins auf dem Dashboard AJAX-Aufrufe machen, sind das 5 zusätzliche komplette WordPress-Bootstraps pro Dashboard-Aufruf.

# Check admin-ajax traffic in your browser:
# DevTools → Network → Filter "admin-ajax"
# Look at how many requests fire on a single page load

2. Overhead der Heartbeat-API

Der WordPress-Heartbeat schickt alle 15–60 Sekunden einen AJAX-Request, um auf Autosaves, Post-Locks und Benachrichtigungen zu prüfen. Jeder Request lädt den kompletten WordPress-Stack. Auf Shared Hosting kann das allein Ihre PHP-Worker auslasten.

// Slow down heartbeat to reduce load:
add_filter('heartbeat_settings', function($settings) {
    $settings['interval'] = 120; // seconds (default: 15-60)
    return $settings;
});

3. Langsame Plugin-Callbacks auf admin_init

Plugins hängen sich an admin_init, admin_menu und admin_enqueue_scripts. Diese laufen auf jeder Admin-Seite, nicht nur auf der Einstellungsseite des Plugins. Ein einziger schlecht geschriebener Callback kann jeden Admin-Request um 500 ms und mehr verlängern.

4. Autoload-Ballast

Dieselbe wp_options-Autoload-Query, die Ihr Frontend betrifft, läuft auch auf jeder Admin-Seite. Admin-Seiten werden aber nie gecacht, Sie spüren also jedes Mal die volle Wucht. Zum vollständigen Autoload-Guide.

Schnelle Erfolge, sobald Sie Ihren Fall kennen

Heartbeat-Frequenz senken

Heartbeat von 15 s auf 120 s zu stellen senkt die admin-ajax-Requests im Hintergrund um 87 % (Editor-Tabs, 15 s auf 120 s). Die meisten Sites merken funktional keinen Unterschied.

Dashboard-Widgets abschalten

Jedes Dashboard-Widget führt beim Laden eigene Queries aus. Entfernen Sie Widgets von Plugins, die Sie nicht täglich brauchen:

add_action('wp_dashboard_setup', function() {
    remove_meta_box('dashboard_quick_press', 'dashboard', 'side');
    remove_meta_box('dashboard_primary', 'dashboard', 'side');
    // Remove plugin widgets that make external API calls
});

Object Caching einrichten

Redis oder Memcached verbessern die Backend-Performance, weil Admin-Seiten query-lastig sind und nie im Page Cache landen. Datenbankzugriffe, die auf jeder Admin-Seite laufen, kommen dann aus dem Arbeitsspeicher.

Autoloaded Daten bei Managed Hosting (WP Engine, Flywheel)

Wenn Sie bei WP Engine oder Flywheel sind und das Backend langsam ist, prüfen Sie zuerst Ihre autoloaded Daten. WP Engine empfiehlt, die Summe der autoloaded Optionen unter 800 KB zu halten. Darüber lädt jeder Admin-Request ein übergroßes wp_options-Ergebnis in den Speicher – und weil Admin-Seiten nie gecacht werden, spüren Sie die vollen Kosten bei jedem Klick.

Prüfen Sie Ihre Autoload-Größe mit einer einzigen Query:

-- Total autoloaded data (target: under 800 KB)
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');

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

Typische Übeltäter: alte Transients, Caches der Update-Prüfung und übergroße Theme-/Options-Blobs von Page Buildern. Der sichere Weg ist, Autoload bei einzelnen Optionen abzuschalten – wp option set-autoload OPTION_NAME off – statt Zeilen massenhaft zu löschen. Der Autoloader Optimizer von WP Multitool sortiert die Verursacher und schaltet Autoload gefahrlos ab.

Liegt das Autoload bereits unter 800 KB und Ihr Backend ist immer noch sehr langsam, hat sich der Engpass zu den Hook-Callbacks verschoben – und da setzt der Slow Callback Finder an.

Vorher und nachher: Wie „repariert" aussieht

Ich zeige Ihnen keine erfundenen Kundenzahlen – ein Vorher/Nachher, das Sie nicht selbst gemessen haben, ist Fiktion. Was ich Ihnen geben kann, ist die Tabelle, die ich ausfülle, bevor ich irgendetwas anfasse. Füllen Sie sie zuerst aus, ändern Sie eine Sache nach der anderen und messen Sie nach jeder Änderung neu. Ohne die Vorher-Spalte erfahren Sie nie, welche Maßnahme tatsächlich gewirkt hat.

Zwei Regeln machen die Zahlen ehrlich. Messen Sie auf derselben Seite, im selben Browser, zur selben Tageszeit – die Backend-Last schwankt mit der Aktivität des Teams. Und ändern Sie zwischen zwei Messungen jeweils nur eine Sache, sonst können Sie die Verbesserung niemandem zuschreiben. Die absoluten Werte zählen weniger als die Differenzen: die Backend-TTFB auf billigem Hosting zu halbieren ist mehr wert als eine „schnelle" Zahl, die Sie nicht reproduzieren können.

Verwandte Guides