Quando le pagine pubbliche sono veloci e l'amministrazione è lenta, di solito non sta misurando due volte la stessa cosa. Le pagine pubbliche arrivano da una cache; l'amministrazione esegue la sua applicazione a ogni clic. La velocità dell'amministrazione è la vera velocità del sito.

Confermi che la differenza è la cache

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

HIT sulla prima e BYPASS sulla seconda: la spiegazione è tutta lì. Veda la cache di pagina, e quando le mente.

Poi scopra che cosa sta facendo davvero l'applicazione

  • Le query. Una vista a elenco in amministrazione di solito carica per riga molto più di una pagina pubblica. Veda le query N+1.
  • Una chiamata esterna al caricamento della pagina - un controllo di licenza, un controllo aggiornamenti, un feed - in cui la dashboard aspetta il server di qualcun altro.
  • Una tabella di log o di attività che è cresciuta e che ora viene contata a ogni pagina.
  • Decine di script riservati all'amministrazione, che è un problema di browser e non di server.

Misuri la ripartizione

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

Un TTFB alto è il server; un TTFB basso con un totale lento è il browser. Quella sola riga decide dove guardare e richiede un secondo.

Il solito colpevole

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;

Tutto ciò che viene caricato in automatico si legge a ogni singola richiesta. Diversi megabyte di quella roba - lasciati da un plugin rimosso - rallentano ogni pagina, e si vedono prima in amministrazione perché lì non c'è nulla in cache.

Disattivi metà dei plugin sullo staging e misuri. Poi metà di quel che resta. Quattro giri trovano il colpevole; tirare a indovinare no.