Vous connaissez cette sensation : vous cliquez sur un lien, et rien ne se passe. Pas de page blanche, pas d'erreur 500. Juste ce vide de deux secondes où vous vous demandez si votre connexion a lâché, si le site est mort, ou si c'est vous qui devenez impatient. Souvent, c'est la troisième option. Et pourtant, le vrai coupable se cache ailleurs : le serveur a mis trop de temps à répondre, bien avant qu'une seule ligne de la page ne s'affiche.
Réduire le temps de réponse du serveur, c'est ce chantier que j'ai ouvert un peu par obligation. Ma boutique en ligne tournait sous WordPress chez un hébergeur mutualisé que je ne nommerai pas, mais qui commence par un O et vend des serveurs dédiés très chers à côté. Le TTFB mesuré sur PageSpeed oscillait entre 1,8 et 3,2 secondes selon l'heure. J'ai d'abord cru à un problème de thème. J'ai eu tort pendant trois semaines.
Points clés à retenir
- Le TTFB se décompose en trois couches distinctes : réseau/DNS, serveur applicatif, base de données. Chacune se mesure séparément, aucune ne se devine.
- La mise en cache des pages règle la majorité des cas sur un site vitrine ou un blog. Elle ne règle presque rien sur une boutique avec panier dynamique.
- Un objectif réaliste : viser moins de 500 ms de TTFB en Europe sur un serveur correctement configuré. En dessous de 200 ms, vous êtes très bien.
- Les requêtes SQL lentes sont la cause numéro un que personne ne regarde, parce que le cache les masque jusqu'au jour où il ne les masque plus.
- Changer d'hébergeur sans avoir diagnostiqué la cause, c'est déplacer le problème en payant plus cher.
- Un thème trop lourd et quinze extensions actives peuvent à eux seuls ajouter 800 ms, sans que le serveur soit en cause.
Comprendre où se perd réellement le temps
Le TTFB, ou Time To First Byte, c'est le délai entre votre clic et l'arrivée du premier octet de HTML. Ce que la plupart des articles oublient de dire, c'est que ce chiffre unique agrège trois choses très différentes, et que les confondre revient à chercher une fuite d'eau en regardant le plafond.
D'abord le réseau : résolution DNS, établissement de la connexion TCP, poignée de main TLS. Ensuite le serveur applicatif : PHP qui compile, un thème qui charge, une extension qui interroge une API externe. Enfin la base de données : chaque requête SQL ajoute des millisecondes, et il y en a souvent des dizaines par page.
La mesure, avant l'action
Bon, la commande qui m'a le plus servi est vieille comme le monde et tient sur une ligne :
curl -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" -o /dev/null -s https://votre-site.comElle découpe le délai en quatre temps. Si time_namelookup dépasse 100 ms, votre DNS est lent et aucune optimisation serveur n'y changera quoi que ce soit. Si time_starttransfer est énorme alors que les trois premiers sont rapides, le problème est côté application ou base de données. C'est bête, mais ça vous évite de débourser 40 euros par mois pour rien.
Sur mon propre site, la commande a révélé un DNS à 180 ms (serveurs de l'hébergeur, pas les miens) et un TTFB applicatif à 1,4 seconde. J'ai réglé le DNS en dix minutes en basculant sur un résolveur externe. Le reste a pris trois semaines.
Les seuils qui comptent
PageSpeed Insights déclenche son audit de latence au-delà de 600 ms de TTFB. C'est un repère utile, pas une vérité absolue : un TTFB de 700 ms sur une page mise en cache au bord du réseau, c'est déjà mauvais signe. À l'inverse, 400 ms sur une page de compte client générée dynamiquement, c'est correct.
Ce que je vise personnellement, sur des projets européens :
- Moins de 200 ms : vous avez fait le travail
- 200 à 500 ms : acceptable
- 500 ms à 1 seconde : il y a quelque chose à gratter
- Au-delà : vos visiteurs le sentent, même s'ils ne le formulent pas comme ça
Franchement, le quatrième cas est le plus dangereux, parce qu'il ne produit pas d'erreur visible. Les gens partent, simplement.
Les astuces qui réduisent vraiment le temps de réponse
Classons par rapport rendement/effort, parce que tout le monde n'a pas une équipe d'ingénieurs sous la main.
Le cache de pages : le gain le plus rapide
Si votre site sert du contenu majoritairement statique, un cache de pages peut faire chuter le TTFB de 1,5 seconde à moins de 100 ms. Sur ma boutique, cette seule mesure a ramené le TTFB de 3,2 à 0,4 seconde sur les pages catégories. Effet immédiat, mesurable, sans toucher au code.
Le piège : le panier, la page de commande et l'espace client ne doivent jamais être mis en cache. Si vous cachez tout à l'aveugle, vous allez servir le panier de quelqu'un d'autre à quelqu'un d'autre. J'ai vu ce genre d'incident arriver chez un confrère, il a mis deux jours à comprendre l'origine des plaintes.
Les requêtes SQL lentes : le coupable invisible
C'est ici que ça se joue vraiment, et c'est ce qui manque dans 90 % des articles sur le sujet. Activez le log des requêtes lentes sur votre base de données, ou installez un plugin qui liste les requêtes par page et leur durée. Sur mon site, j'ai découvert qu'une extension de gestion de stock exécutait 47 requêtes identiques à chaque affichage de fiche produit, uniquement pour vérifier la disponibilité. 47 requêtes, 40 ms chacune, en série.
La correction a consisté à mettre en cache le résultat de cette vérification pendant 60 secondes. Gain : environ 900 ms par page. Le plugin concerné n'a jamais été corrigé par son éditeur, je l'ai remplacé six mois plus tard.
PHP, OPcache et la version du langage
Trois réglages qui prennent une heure et qui rapportent :
- Passer à une version de PHP récente (chaque version majeure apporte des gains de performance significatifs)
- Activer OPcache avec une taille de mémoire suffisante
- Passer au PHP-FPM plutôt qu'à l'exécution via mod_php si votre hébergeur le permet
OPcache stocke le bytecode compilé en mémoire. Sans lui, PHP recompile chaque fichier à chaque requête. Sur un thème lourd avec 200 fichiers inclus, la différence est perceptible immédiatement, de l'ordre de 200 à 400 ms sur mon installation.
Le CDN et la question de la localisation
Un CDN ne réduit pas votre TTFB applicatif. Il réduit le temps de transport entre le visiteur et le point d'entrée le plus proche. Si votre serveur d'origine met 1,2 seconde à générer la page, le CDN transmettra cette lenteur très efficacement à travers le monde. C'est un multiplicateur de vitesse, pas une solution.
En revanche, si votre audience est majoritairement en France et votre serveur aux États-Unis, là, la géographie compte. Un serveur à Francfort pour une audience française, c'est 20 à 40 ms de latence en moins qu'un serveur à Dallas.
| Levier | Gain typique constaté | Effort | Risque |
|---|---|---|---|
| Cache de pages | 300 ms à 1,5 s | Faible | Élevé si mal configuré |
| Requêtes SQL optimisées | 200 ms à 900 ms | Moyen | Faible |
| OPcache activé | 200 à 400 ms | Faible | Très faible |
| Changement d'hébergeur | Variable, parfois nul | Élevé | Migration, coupures |
| CDN | 0 ms côté serveur, gain côté transport | Faible à moyen | Faible |
Les erreurs que j'ai faites (et que vous pouvez éviter)
Changer d'hébergeur en premier. J'ai migré mon site sur un serveur dédié à 60 euros par mois avant d'avoir diagnostiqué quoi que ce soit. TTFB après migration : 2,8 secondes. Le gain était de 400 ms. J'ai payé 50 euros de plus par mois pour 400 ms, alors que le cache de pages m'aurait coûté zéro.
Faire confiance à un thème premium. Les thèmes vendus comme « optimisés » chargent souvent des bibliothèques JavaScript entières sur des pages qui n'en ont pas besoin. J'ai désenregistré manuellement cinq scripts inutiles. Gain cumulé : 300 ms.
Oublier que le TTFB se mesure sur des pages différentes. Un TTFB excellent sur la page d'accueil ne dit rien de celui de votre page panier. Chez moi, la page d'accueil affichait 180 ms, la page produit 1,1 seconde. Je regardais le mauvais chiffre depuis le début.
Questions fréquentes
Comment savoir si le problème vient de mon hébergeur ?
Testez votre site avec la commande curl depuis plusieurs endroits, et comparez avec un site statique hébergé au même endroit. Si un fichier HTML basique servi par le même serveur répond en moins de 100 ms et que votre page met 1,5 seconde, le serveur n'est pas en cause, c'est votre application. Si même le fichier statique est lent, vous avez votre réponse.
La mise en cache est-elle toujours la solution ?
Non, et c'est une nuance importante. Sur une application avec beaucoup de contenu personnalisé (utilisateurs connectés, paniers, tableaux de bord), le cache de pages complet est inutilisable. Il faut alors se tourner vers le cache d'objets (Redis, Memcached) et l'optimisation des requêtes base de données. Ce sont deux chantiers différents, avec des outils différents.
Combien de temps avant de voir un effet mesurable ?
Le cache de pages : effet immédiat après activation. L'optimisation SQL : effet immédiat aussi, mais le diagnostic prend du temps. Le changement de version PHP : effet immédiat, mais attendez-vous à quelques jours de débogage, les extensions incompatibles sont fréquentes et se manifestent parfois sur des pages rarement visitées.
Ce qui reste quand tout est optimisé
Il y a un plancher qu'on ne franchit pas. Une page générée à la volée, avec des données personnalisées, des appels à des services tiers et une base de données interrogée en direct, aura toujours un coût. Le tout est de savoir si ce coût vaut ce qu'il apporte.
Sur mon projet, je suis descendu à 320 ms de TTFB moyen. J'aurais pu grappiller encore 100 ms en supprimant le module de recommandations produits. Je ne l'ai pas fait, parce que ce module génère environ 12 % de mon chiffre d'affaires. La vitesse n'est jamais un objectif en soi, c'est un arbitrage.
Ce qui me frappe, en y repensant, c'est que la réponse était dans mes logs depuis le début. J'ai passé trois semaines à regarder mon hébergeur, mon thème, mes images. La cause était quarante-sept requêtes identiques que personne n'avait écrites volontairement. La question que je me pose maintenant, avant toute optimisation, c'est : est-ce que je mesure la bonne chose ? Et vous, quel chiffre regardez-vous en ce moment ?
