Pourquoi votre site est lent : diagnostiquer avant d'optimiser

« Le site est lent. » C'est souvent la première phrase du brief — et elle ne suffit pas pour agir. Un site peut être lent parce que le serveur met deux secondes à répondre, parce que la page pèse huit mégaoctets, parce qu'un script tiers bloque tout, ou parce que la base de données peine sur une requête. Les remèdes sont différents, parfois opposés. Optimiser sans diagnostic, c'est dépenser au hasard.

Étape 1 — Situer la lenteur : serveur, réseau ou navigateur ?

Le premier réflexe est de découper le temps de chargement en trois blocs :

1. Le temps de réponse du serveur (TTFB) : le délai entre la requête et le premier octet de réponse. Au-delà de ~800 ms, le problème est en amont du navigateur.
2. Le téléchargement des ressources : poids et nombre de fichiers (images, scripts, polices).
3. L'exécution dans le navigateur : JavaScript qui bloque, rendu coûteux.

Un simple curl donne déjà le premier bloc, sans outil ni compte :

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnexion: %{time_connect}s\nTLS: %{time_appconnect}s\nPremier octet: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://www.exemple.fr/

Si le premier octet arrive en 200 ms mais que la page se termine à 6 secondes, inutile de toucher au serveur : le problème est dans ce que la page transporte ou exécute.

Étape 2 — Lire la cascade de chargement

L'onglet Réseau des outils de développement (F12) raconte l'histoire complète : chaque ligne est une ressource, chaque décalage une attente. Ce qu'on y cherche :

• Une longue barre verte au début : le serveur est lent (voir étape 3).
• Des dizaines de requêtes en série : des dépendances en chaîne (un script qui charge un script qui charge une police).
• Quelques ressources énormes : images non compressées, bundle JavaScript obèse, vidéo en autoplay.
• Des domaines tiers qui traînent : widget de chat, tag manager, polices externes — testez la page avec les tiers bloqués, la différence est parfois spectaculaire.

Étape 3 — Si le serveur est lent : instrumenter, pas deviner

Un TTFB élevé a lui-même plusieurs causes possibles : requêtes SQL sans index, absence de cache, hébergement mutualisé saturé, appel à une API externe dans le chemin critique. L'en-tête standard Server-Timing permet d'exposer ce découpage directement dans les outils de développement :

// Exemple avec un serveur Node/Nitro : mesurer la part base de données
const debut = performance.now();
const resultats = await db.select().from(produits).limit(24);
const dureeDb = performance.now() - debut;

setResponseHeader(event, 'Server-Timing', `db;dur=${dureeDb.toFixed(1)};desc="requetes SQL"`);

Avec trois ou quatre segments (base, cache, rendu, appels externes), la répartition du temps serveur devient visible requête par requête — et le débat « c'est la base ou c'est l'hébergeur ? » se règle avec des chiffres.

Étape 4 — Prioriser par l'impact, pas par la facilité

Toutes les lenteurs ne se valent pas. Une image de 3 Mo sur une page de mentions légales est un détail ; 300 ms de TTFB sur la page produit qui reçoit 80 % du trafic est un chantier prioritaire. Croisez toujours le diagnostic technique avec l'audience réelle des pages avant de choisir le premier chantier.

Ordre de grandeur des gains typiques, à titre indicatif :

Ce qu'il faut retenir

La lenteur n'est pas une cause, c'est un symptôme. Quinze minutes de diagnostic — un curl, une cascade réseau, un Server-Timing — évitent des semaines d'optimisations à côté du sujet. Et si le diagnostic désigne un chantier lourd, il fournit aussi le chiffre qui justifie (ou non) l'investissement : c'est une conversation bien plus saine qu'un devis d'optimisation « au forfait ».