Presque toute tentative de « rendre ça plus rapide » commence par une intuition et une extension. Commencez plutôt par un chiffre : il coupe le problème en deux.
Le temps jusqu'au premier octet
curl -o /dev/null -s -w 'dns %{time_namelookup}s connect %{time_connect}s ttfb %{time_starttransfer}s total %{time_total}s\n' https://yourdomain.com/- TTFB sous 200 ms - le serveur va bien. Tout ce que vous ressentez est dans le navigateur : images, polices, scripts.
- TTFB au-dessus de 800 ms - la page se construit lentement. Rien dans le navigateur n'y changera quoi que ce soit.
- connect bien plus grand que dns - la distance ou une poignée de main TLS lente, pas l'application.
Si le serveur est lent
La page fait trop de travail par requête. Par ordre de fréquence à laquelle c'est la réponse :
- Une requête sans index — Le journal des requêtes lentes la nomme. Un index fait d'ordinaire gagner des secondes.
- La même requête dans une boucle — Vingt produits, vingt requêtes pour leurs catégories. Une jointure les remplace toutes.
- Un appel externe sans délai maximal — Une API morte retient votre page tant que sa socket reste ouverte.
- Pas de cache d'opcode — Sans opcache, PHP recompile chaque fichier à chaque requête.
Si le navigateur est lent
- Les images. D'ordinaire l'essentiel des octets. Servez la taille que la page utilise, pas celle qu'a produite l'appareil photo.
- Les polices. Chaque famille et chaque graisse est un fichier, et une police qui bloque l'affichage retient toute la page.
- Les scripts tiers. La partie la plus lente de la plupart des pages, c'est du code venu du serveur de quelqu'un d'autre.
Une extension de cache sur une page lente vous cache le problème, mais pas au premier visiteur de chaque cycle de cache. Corrigez la page, ensuite mettez-la en cache.
Mesurez la même page trois fois, à la même heure de la journée, avant et après chaque changement. Un changement, une mesure - sinon vous ne saurez pas lequel a marché.