Votre PageSpeed Insights affiche un TTFB rouge. Le réflexe immédiat : « il faut plus de CPU » ou « il faut un VPS ». Trois semaines plus tard, la facture a doublé et le délai serveur n''a bougé que de 40 ms. Le scénario est banal : on a traité un symptôme sans identifier le maillon qui retarde la première octet.
Le Time To First Byte mesure le temps entre la requête HTTP et la réception du premier octet de réponse. Il condense DNS, TLS, routage réseau, file d''attente serveur, exécution PHP, requêtes SQL et éventuellement appels API. Acheter du CPU ne raccourcit pas une résolution DNS lente ni une jointure SQL non indexée.
Mesurer correctement — sans se faire piéger par le cache
Un TTFB « labo » et un TTFB « utilisateur réel » racontent deux histoires. PageSpeed et Lighthouse mesurent souvent depuis des datacenters Google, parfois avec cache chaud. WebPageTest, un curl depuis votre machine, ou les rapports RUM (Real User Monitoring) complètent le tableau.
Procédure minimale :
- Tester l''origine — URL directe du serveur ou en-tête
Cache-Control: no-cache. - Comparer cache ON/OFF — une page statique (
/favicon.ico) vs une page PHP dynamique. - Répéter depuis deux régions — latence réseau ≠ lenteur applicative.
- Noter l''heure — un mutualisé lent à 14 h peut être acceptable à 3 h.
| Mesure | Ce qu''elle isole | Limite |
|---|---|---|
TTFB page .html statique | Réseau + web server | Ignore PHP/SQL |
| TTFB page dynamique | Chaîne complète | Mélange plusieurs causes |
curl -w '%{time_starttransfer}' | Serveur brut, reproductible | Pas de rendu navigateur |
Logs PHP-FPM slowlog | Scripts > seuil (ex. 5 s) | Ne voit pas MySQL seul |
Un TTFB excellent sur une page CDN ne prouve pas que votre WordPress est rapide. Il prouve surtout que le cache edge fonctionne.
La chaîne des suspects, dans l''ordre utile
Avant d''ouvrir un ticket « serveur lent », parcourez cette liste. Chaque maillon a des signaux distincts.
DNS. Un TTL mal configuré ou un résolveur lent ajoute 100 à 300 ms avant même que le serveur ne réponde. Vérifiez avec dig ou des outils comme DNSPerf.
TLS et HTTP/2. La négociation SSL sur un certificat mal chaîné ou un cipher obsolète coûte du temps. Rarement le goulot principal, mais mesurable.
File d''attente PHP-FPM. Si tous les workers sont occupés, la requête attend — le TTFB monte sans que le script soit lent. Symptôme : TTFB variable, pics corrélés au trafic.
Script PHP lent. Plugins WordPress, autoload lourd, boucles inutiles. Le slowlog FPM et Blackfire identifient la fonction coupable.
Base de données. Requêtes sans index, tables postmeta surchargées, absence de cache objet (Redis). MySQL slow_query_log est votre allié.
Appels externes. API météo, CRM, paiement synchrones dans le rendu de page bloquent le TTFB entier.
Scénarios typiques : A vs B
| Symptôme | Cause probable | Action avant upgrade |
|---|---|---|
| TTFB stable ~800 ms, trafic faible | Requête SQL ou plugin | Profiler, index, cache objet |
| TTFB 200 ms le matin, 2 s à midi | Workers FPM saturés | Ajuster pm.max_children, pas seulement CPU |
| TTFB OK en France, lent aux US | Géographie, pas serveur | CDN ou région plus proche |
TTFB 50 ms sur .html, 900 ms sur / | Application, pas hébergement | OPcache, cache page, optimiser WP |
Le sommet : le CPU est rarement le premier levier
Voici ce que les pages « offre Premium 8 vCPU » eludent.
L''hébergeur peut fournir un serveur rapide. Il ne réécrit pas votre requête SELECT * FROM wp_postmeta. Confondre les deux retarde la vraie correction et alourdit le budget sans preuve.
Décider et avancer sans angle mort
- Mesurez TTFB origine, avec et sans cache, sur 24 h.
- Isolez le maillon (DNS → FPM → SQL → API).
- Corrigez l''application avant de comparer les offres hébergeur.
- Retestez avec le même scénario ; seulement ensuite, évaluez un plan supérieur ou un comparateur d''hébergements.
Pour les sites WordPress, croisez ce diagnostic avec le guide OPcache et PHP-FPM. Pour filtrer les hébergeurs selon vos contraintes réseau, consultez l''annuaire.
Questions fréquentes
Quel TTFB est acceptable pour un site PHP ?
En dessous de 200 ms côté serveur pour une page dynamique non mise en cache, c''est solide. Entre 200 et 600 ms, creusez la chaîne. Au-delà, mesurez avant d''acheter plus de ressources.
Le TTFB inclut-il le CDN ?
Oui, si la requête passe par un CDN. Testez l''origine avec cache bypass pour voir la vraie performance PHP.
Comment savoir si c''est PHP ou la base de données ?
Comparez une page statique à une dynamique, activez le slow query log MySQL et profilez en staging avec Blackfire ou Xdebug.
Changer d''hébergeur résout-il un TTFB élevé ?
Rarement sans corriger l''application. Un serveur surchargé peut ajouter de la latence ; une requête SQL lente restera lente partout.
La prochaine fois qu''un TTFB rouge s''affiche, posez une question avant d''acheter du CPU : quelle étape de la chaîne a pris combien de temps ? La réponse tient souvent dans un log, pas dans un devis.