Ce qu’il mesure exactement
Le TTFB additionne la résolution DNS, l'établissement de la connexion TCP et TLS, puis le temps que met le serveur à produire la page. Sur un CMS, cette dernière part domine largement : c'est le temps que PHP et la base de données passent à assembler la réponse. Google considère un TTFB correct en dessous de 800 ms, et problématique au-delà de 1,8 s.
Pourquoi il pèse sur tout le reste
Un TTFB de 1,5 s décale mécaniquement le LCP de 1,5 s : aucune optimisation d'images ou de CSS ne rattrape ce retard, puisque le navigateur n'a encore rien reçu. C'est pour cette raison qu'un audit de performance qui commence par les images alors que le TTFB dépasse la seconde s'attaque au mauvais bout du problème.
Causes fréquentes sur PrestaShop et WordPress
Cache désactivé ou vidé en continu, requêtes SQL non indexées sur un catalogue volumineux, module ou extension qui interroge une API externe à chaque chargement, version de PHP ancienne, mutualisé saturé aux heures de pointe. Sur PrestaShop, la reconstruction permanente du cache Smarty est un classique ; sur WordPress, un plugin de statistiques qui écrit en base à chaque visite.
Questions fréquentes
Quel TTFB viser ?
Moins de 800 ms selon les seuils Google. Entre 800 ms et 1,8 s, la marge de progression est réelle ; au-delà, l'expérience se dégrade nettement et le référencement peut en souffrir.
Un CDN améliore-t-il le TTFB ?
Pour les fichiers statiques, nettement. Pour une page générée dynamiquement — panier, compte client, tunnel de commande — le CDN ne change rien : c'est le serveur d'origine qui travaille.