Une page lente est lente à l'un de trois endroits : le serveur avant qu'il n'envoie un octet, le réseau entre les deux, ou le navigateur une fois la page arrivée. Chacun a un remède différent, et aucun n'aide les deux autres. Se tromper de diagnostic coûte un week-end et ne change rien.

1. Combien de temps avant le premier octet

curl -sS -o /dev/null -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\
' https://yourdomain.com/

Un TTFB au-delà d'environ 600 ms avec un temps de connexion faible, c'est le serveur qui réfléchit. En dessous de 200 ms, le serveur n'est pas votre problème, quelle que soit l'impression que donne la page.

2. Est-ce l'application ou la base de données

# is anything slow enough to be logged
sudo tail -f /var/log/mysql/mysql-slow.log

Voir Le journal des requêtes lentes. Une seule requête à 900 ms explique bien plus de sites que n'importe quelle dose de cache.

3. Ce que la page pèse réellement

Ouvrez le panneau réseau, triez par taille et lisez les cinq premières lignes. Sur la plupart des sites, ce sont toutes des images — voir Des images plus lourdes que toute la page. Lire correctement un diagramme en cascade est traité dans un article à part.

4. Ce que reçoit un vrai visiteur

La connexion de votre bureau n'est pas la mesure. Testez depuis là où sont vos clients, sur une connexion bridée, sur un téléphone de milieu de gamme.

Changez une chose, puis mesurez de nouveau. Trois changements d'un coup et vous ne saurez jamais lequel a aidé — ni lequel a aggravé les choses pendant qu'un autre le masquait.
Notez les chiffres avant de commencer. Une impression de rapidité n'est pas une preuve, et après un après-midi de travail tout le monde trouve le site plus rapide.