Diagnostiquer un site lent

Un site lent n'est pas un diagnostic, c'est un symptôme. La lenteur peut venir du DNS, de la connexion TLS, du serveur, de la base de données, d'une requête applicative ou du réseau de l'utilisateur. Sans mesure initiale, vous modifiez plusieurs paramètres à la fois et vous ne savez plus lequel a aidé.

Mesurer avant de toucher

Décomposez le temps de réponse avec curl :

curl -o /dev/null -sS -w 'dns %{time_namelookup} | connect %{time_connect} | tls %{time_appconnect} | ttfb %{time_starttransfer} | total %{time_total}\n' https://votre-domaine.fr/

Le TTFB (time_starttransfer) sépare le temps réseau du temps de traitement serveur. Si le DNS ou la connexion TLS domine, cherchez côté réseau ou certificat. Si le TTFB domine, le problème est sur le serveur ou dans l'application. Refaites la mesure depuis un autre réseau : votre cache navigateur et votre connexion locale faussent la lecture.

Serveur et base de données

CPU, mémoire, disque.

uptime
free -h
vmstat 1 5
iostat -x 1 5
ss -s

Comparez la charge moyenne au nombre de vCPU (nproc). Une charge durablement supérieure au nombre de cœurs indique une saturation. Un %iowait élevé dans iostat pointe vers le disque ; des colonnes si/so non nulles dans vmstat vers la mémoire. Dans un conteneur système, ces chiffres reflètent votre quota, pas l'ensemble de la plateforme.

Requêtes lentes.

Activez le journal des requêtes lentes côté MariaDB :

sudo mariadb -e "SET GLOBAL slow_query_log=ON; SET GLOBAL long_query_time=1;"

Rendez le réglage permanent dans /etc/mysql/mariadb.conf.d/50-server.cnf, puis relisez le fichier indiqué par SHOW VARIABLES LIKE 'slow_query_log_file';. Sur PostgreSQL, activez pg_stat_statements et triez par total_exec_time.

Pour chaque requête lente, lancez EXPLAIN : un balayage complet de table sur une table volumineuse s'explique souvent par un index manquant. Attention aux SELECT * et aux requêtes exécutées dans une boucle.

Nginx et application

Ajoutez un format de journal qui mesure le temps de traitement et celui de l'amont :

log_format timing '$remote_addr "$request" $status $request_time $upstream_response_time';
access_log /var/log/nginx/timing.log timing;

Après rechargement, triez les URLs les plus lentes pour savoir où chercher. Vérifiez aussi le journal d'erreurs, la saturation du pool PHP-FPM (pm.max_children, file d'attente) et le fait que les fichiers statiques sont servis par Nginx, pas par l'application.

Cache et livraison

Le cache masque la lenteur sans la corriger. Mesurez toujours avec le cache désactivé avant de conclure. Ensuite seulement : OPcache pour PHP, cache de pages, en-têtes Cache-Control, compression, images dimensionnées. Un CDN aide sur les assets et la latence, pas sur une requête SQL lente.

Vérifier après chaque changement

Reprenez exactement la même commande curl, depuis le même endroit, et comparez le TTFB et le total. Ne changez qu'un paramètre à la fois, notez la date et l'effet. Un site qui redevient rapide après un redémarrage n'est pas réparé : cherchez la fuite mémoire ou la connexion qui s'accumule.