Quand les pages publiques sont rapides et l'administration lente, vous ne mesurez d'ordinaire pas deux fois la même chose. Les pages publiques sortent d'un cache ; l'administration exécute votre application à chaque clic. La vitesse de l'administration est la vraie vitesse du site.

Confirmer que la différence, c'est le cache

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

HIT sur la première et BYPASS sur la seconde, voilà toute l'explication. Voyez le cache de pages, et quand il vous ment.

Puis trouver ce que fait réellement l'application

  • Les requêtes. Une vue en liste d'administration charge d'ordinaire bien plus par ligne qu'une page publique. Voyez les requêtes N+1.
  • Un appel externe au chargement - vérification de licence, de mise à jour, un flux - où le tableau de bord attend le serveur de quelqu'un d'autre.
  • Une table de journal ou d'activité qui a grossi et qu'on compte désormais à chaque page.
  • Des dizaines de scripts réservés à l'administration, ce qui est un problème de navigateur et non de serveur.

Mesurer la répartition

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

Un TTFB élevé, c'est le serveur ; un TTFB faible avec un total lent, c'est le navigateur. Cette seule ligne décide où chercher et prend une seconde.

Le coupable habituel

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;

Tout ce qui est chargé automatiquement est lu à chaque requête. Plusieurs mégaoctets de cela - laissés par une extension supprimée - ralentissent toutes les pages, et cela se voit d'abord dans l'administration parce que rien n'y est mis en cache.

Désactivez la moitié des extensions en préproduction et mesurez. Puis la moitié de ce qui reste. Quatre tours trouvent la bonne ; deviner, non.