Performance-Guide

WordPress-Backend-
Performance

Sie haben Ihr Frontend optimiert. Caching eingerichtet, Bilder komprimiert, ein CDN konfiguriert. Warum ist die Site immer noch langsam?

Warum Frontend-Optimierung für WordPress-Geschwindigkeit nicht reicht

Die meisten WordPress-Performance-Guides drehen sich um Frontend-Optimierung: Caching, Bildkomprimierung, Minifizierung, CDN. Das ist alles richtig—und Sie sollten es tun.

Aber über eines redet niemand: Backend-Performance.

Das Muster

Die Site hat einen PageSpeed-Score über 95. Die Bilder sind optimiert. Caching ist aktiv. Und Nutzer sagen trotzdem, sie fühlt sich langsam an.

Der Schuldige ist meist die Time to First Byte (TTFB)—die Zeit, die Ihr Server braucht, um überhaupt zu antworten. Wenn Ihr Server 2 Sekunden benötigt, um jede Seite zu bauen, hilft keine Frontend-Optimierung der Welt.

Welches Backend-Problem haben Sie?

Vier Symptome, vier verschiedene Ursachen. Fangen Sie mit dem an, das zu dem passt, was Sie tatsächlich sehen, und überspringen Sie den Rest dieser Seite.

  1. Das Backend ist langsam, das Frontend in Ordnung. Das ist kein Caching-Problem und wird nie eines sein. Es sind admin-ajax, Heartbeat, Plugin-Callbacks auf admin_init oder Autoload. Ein langsames wp-admin diagnostizieren.
  2. Die TTFB ist hoch, obwohl der Cache die Seiten ausliefern sollte. Irgendetwas läuft, bevor der Cache antworten kann. Meist eine langsame Query oder ein Autoload-Set, das zu groß für den Object Cache ist. Zuerst die langsamen Queries finden, dann die Autoload-Größe prüfen.
  3. Ihr Hoster hat „autoloaded data" gemeldet. Messen Sie selbst, bevor Sie handeln – manche Panels zählen unter WordPress 6.6+ zu niedrig. Autoload-Ballast prüfen und beheben.
  4. Sie kennen die Ursache und wollen sie automatisch beheben lassen. Der Autoloader Optimizer kategorisiert jede autoloaded Option und schaltet die unbedenklichen um – mit Wiederherstellung per Klick dahinter.

Frontend- vs. Backend-Performance in WordPress

Frontend (gelöst)
  • Bildoptimierung
  • CSS-/JS-Minifizierung
  • Browser-Caching
  • Auslieferung per CDN
  • Lazy Loading
Backend (oft übersehen)

Caching-Plugins kümmern sich um die Auslieferung im Frontend. Sie fassen weder die PHP-Verarbeitung noch die Datenbank-Queries an, die vorher laufen, bevor überhaupt etwas in den Cache geht.

TTFB-Richtwerte für WordPress: Kennen Sie Ihre Zahlen

TTFB prüfen: Chrome DevTools → Netzwerk → erster Request → „Waiting (TTFB)"

<200ms
Ausgezeichnet
200-500ms
Akzeptabel
>500ms
Nachbesserung nötig

Liegt Ihre TTFB über 500 ms, kümmern Sie sich um das Backend, bevor Sie sonst irgendetwas anfassen. Sonst lösen Sie das falsche Problem.

Typische Backend-Performance-Probleme in WordPress

1. Autoload-Ballast

Bei jedem WordPress-Request läuft diese Query: 

SELECT option_name, option_value FROM wp_options WHERE autoload IN ('yes', 'on')

Wenn Sie 2 MB autoloaded Daten haben, wandern bei jedem einzelnen Seitenaufruf 2 MB von der Datenbank nach PHP. Prüfen Sie Ihre Summe: 

SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes', 'on');

Über 1 MB? Dann haben Sie ein Problem. Oft sind es Reste deaktivierter Plugins. Lesen Sie unseren kompletten Guide zum Beheben von Autoload-Ballast in WordPress.

2. Langsame Datenbank-Queries

Eine einzige Query mit 500 ms verzögert die ganze Seite. Typische Quellen:

  1. Meta-Queries ohne Index (besonders bei WooCommerce-Produkten)
  2. LIKE-Queries auf post_content
  3. Mehrere JOINs auf wp_postmeta
  4. COUNT-Queries mit komplexen WHERE-Bedingungen

So finden und beheben Sie langsame Datenbank-Queries in WordPress.

3. Fehlender Object Cache

Ohne Redis oder Memcached baut WordPress bei jedem Request alles neu aus der Datenbank auf. Object Caching kann die TTFB auf datenbanklastigen Sites um über 50 % senken.

4. N+1-Query-Probleme

20 Beiträge laden und dann für die Metadaten jedes Beitrags eine eigene Query starten = 21 Queries statt 2. Plugins und Themes machen das oft unabsichtlich.

Backend-Performance-Probleme in WordPress diagnostizieren

Die Schritte 02 bis 06 messen jeweils eine Sache von Hand. Schritt 01 misst sie alle in einem Durchgang – fangen Sie also dort an und lassen Sie die sortierte Liste entscheiden, welche der übrigen Sie noch ausführen müssen.

Noch kein Plugin installiert? Die kostenlose /scan/-Seite misst TTFB und Komprimierung von außen – ob der Server schon langsam ist, bevor der Browser ein Byte bekommt. Sie führt die Prüfungen von Site Doctor nicht aus; die brauchen den Server. Sobald Sie die externe Zahl haben, installieren Sie WP Multitool und führen Sie den Scan aus.

  1. Prüfen Sie die ganze Installation mit Site Doctor — Ein Durchlauf durch die Site in WP Multitool: OPcache, das Object-Cache-Drop-in, der Redis-Zustand, eine Page-Cache-Probe, Optimizer-Überschneidungen und Datenbank-Ballast, nach Schwere sortiert und jeder Befund mit dem Modul verlinkt, das ihn behebt. Es steckt in Lite wie in Pro; die Autoload- und Slow-Query-Quellen sind nur in Pro, und ein Lite-Scan nennt sie als übersprungen, statt eine saubere Site zu melden. Redis-Checkliste, WP-CLI-Nutzung und die vollständige Checkliste stehen in der Site Doctor-Doku.
  2. TTFB messen — Chrome DevTools oder WebPageTest. Ist sie schnell, kümmern Sie sich ums Frontend. Ist sie langsam, lesen Sie weiter.
  3. Autoload-Größe prüfen — Führen Sie die SQL-Query oben aus. Über 1 MB = sofort handeln.
  4. SAVEQUERIES aktivieren — Tragen Sie vorübergehend define('SAVEQUERIES', true); in die wp-config.php ein. Prüfen Sie $wpdb->queries auf langsame Einträge.
  5. Query Monitor installieren — Kostenloses Plugin, das zeigt, welche Funktionen welche Queries auslösen. Zum Debuggen unverzichtbar.
  6. Plugins per binärer Suche eingrenzen — Alle deaktivieren, TTFB messen, in Gruppen wieder aktivieren, bis das langsame gefunden ist.

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.

Schnelle Backend-Erfolge für WordPress

Object Caching einrichten

Bietet Ihr Hoster Redis oder Memcached an, schalten Sie es ein. Diese eine Änderung kann die TTFB auf datenbanklastigen Sites drastisch senken.

Fehlenden Index anlegen

Der Standardtabelle postmeta von WordPress fehlt ein nützlicher Index. Das hier hilft: 

ALTER TABLE wp_postmeta ADD INDEX meta_value_index (meta_value(191));

Transients aufräumen

DELETE FROM wp_options WHERE option_name LIKE '%_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Ungenutztes Autoload abschalten

Finden Sie Daten deaktivierter Plugins, die noch auf Autoload stehen, und ändern Sie das: 

UPDATE wp_options SET autoload='no' WHERE option_name = 'old_plugin_data';

Warum Backend-Probleme in WordPress immer wiederkommen

Backend-Probleme sind unsichtbar. WordPress zeigt langsame Queries standardmäßig nicht an. Ihre Site kann Queries mit 2 Sekunden Laufzeit haben, von denen Sie nichts wissen, weil nichts protokolliert wird.

Und es ist keine einmalige Reparatur. Die Performance verschlechtert sich mit der Zeit, weil Sie:

  1. Plugins hinzufügen, die sich in jeden Request einklinken
  2. Inhalte und Metadaten ansammeln
  3. mehr Traffic bekommen (was schlummernde Probleme sichtbar macht)
  4. Plugin-Updates einspielen, die Regressionen mitbringen

Sie brauchen laufende Überwachung, nicht nur gelegentliche Handprüfungen. Wenn Ihr WordPress-Backend bereits langsam ist, summiert sich der Schaden mit jedem Seitenaufruf.

Ihr Backend überwachen

WP Multitool protokolliert langsame Queries automatisch, mit vollständigen Stack Traces, die zeigen, welche Plugin-Funktion sie verursacht hat. So finden Sie Probleme, bevor Nutzer sich beschweren.

WP Multitool kaufen Autoloader Optimizer im Detail