Wenn die öffentlichen Seiten schnell und das Backend langsam ist, messen Sie meist nicht zweimal dasselbe. Die öffentlichen Seiten kommen aus einem Cache; das Backend führt Ihre Anwendung bei jedem Klick aus. Die Geschwindigkeit des Backends ist die wirkliche Geschwindigkeit der Website.

Bestätigen, dass der Cache den Unterschied macht

curl -sSI https://yourdomain.com/ | grep -i x-cache
curl -sSI https://yourdomain.com/admin/ -H 'Cookie: session=...' | grep -i x-cache

HIT beim ersten und BYPASS beim zweiten ist schon die ganze Erklärung. Siehe Seiten-Caching, und wann es Sie belügt.

Dann herausfinden, was die Anwendung wirklich tut

  • Abfragen. Eine Listenansicht im Backend lädt je Zeile meist weit mehr als eine öffentliche Seite. Siehe N+1-Abfragen.
  • Ein externer Aufruf beim Seitenaufbau - eine Lizenzprüfung, eine Update-Prüfung, ein Feed -, bei dem das Dashboard auf den Server eines anderen wartet.
  • Eine gewachsene Log- oder Aktivitätstabelle, die jetzt auf jeder Seite gezählt wird.
  • Dutzende Skripte nur fürs Backend - das ist ein Browserproblem, kein Serverproblem.

Die Aufteilung messen

curl -sS -o /dev/null -w 'ttfb %{time_starttransfer}  total %{time_total}\
' \
     -H 'Cookie: session=...' https://yourdomain.com/admin/

Ein hoher TTFB ist der Server; ein niedriger TTFB bei langsamer Gesamtzeit ist der Browser. Diese eine Zeile entscheidet, wo man sucht, und dauert eine Sekunde.

Der übliche Verdächtige

SELECT COUNT(*) FROM wp_options WHERE autoload = 'yes';
SELECT option_name, LENGTH(option_value) FROM wp_options
 WHERE autoload = 'yes' ORDER BY 2 DESC LIMIT 10;

Alles Autogeladene wird bei jeder einzelnen Anfrage gelesen. Mehrere Megabyte davon - Rückstände eines entfernten Plugins - bremsen jede Seite, und es fällt zuerst im Backend auf, weil dort nichts gecacht ist.

Schalten Sie auf dem Staging die Hälfte der Plugins ab und messen Sie. Dann die Hälfte des Rests. Vier Runden finden das eine, Raten nicht.