TTFB WordPress trop élevé : redonner de la vitesse au serveur

Vous avez compressé les images, différé le JavaScript, et pourtant le site reste lent au premier affichage. Réponse directe : le coupable est souvent le TTFB (Time To First Byte), le temps que met le serveur à *commencer* à répondre — invisible côté navigateur, mais fatal pour le LCP. Sur WordPress, un TTFB élevé vient dans l'ordre d'un cache de page absent, d'une base lente, d'un hébergement sous-dimensionné, d'un PHP dépassé ou d'appels externes bloquants. Aucune optimisation front ne le compense. Voici comment le mesurer et le faire baisser.

Comment mesurer le TTFB ?

Le TTFB se lit dans l'onglet Réseau des DevTools (colonne « Waiting / TTFB ») ou dans WebPageTest, qui le décompose. Repère : viser sous 200 ms, tolérer jusqu'à 500 ms, s'inquiéter au-delà de 800 ms. En ligne de commande, une mesure rapide :

curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://votre-site.fr

Mesurez plusieurs pages : si une seule page est lente, le problème est applicatif ; si tout le site rame, il est plus bas — hébergement ou base.

Pourquoi le cache de page est-il le premier levier ?

Sans cache, WordPress reconstruit chaque page à chaque visite : PHP s'exécute, la base est interrogée, le HTML est assemblé. Un cache de page (WP Super Cache, W3 Total Cache, ou le cache serveur de l'hébergeur) sert un HTML déjà prêt et fait chuter le TTFB d'un facteur énorme sur les pages non personnalisées. C'est de loin le gain le plus puissant — à faire en premier.

La base de données est-elle en cause ?

Sur un site âgé, la table wp_options gonfle d'options « autoloaded » rechargées à chaque requête. Une mesure rapide du poids autoloadé :

SELECT ROUND(SUM(LENGTH(option_value))/1024) AS autoload_kb
FROM wp_options WHERE autoload = 'yes';

Au-delà de quelques centaines de kilo-octets, il y a du ménage : options orphelines, transients expirés, révisions accumulées. Les requêtes non indexées d'extensions mal codées sont l'autre grand suspect.

Hébergement, PHP, appels externes : le reste de l'arbre

1. Hébergement : un mutualisé partage ses ressources ; aux heures de charge, votre TTFB dépend des voisins. Si le cache est en place et la base propre mais que le TTFB reste erratique, l'hébergement est le plafond (passer sur un VPS ou un infogéré WordPress change souvent la donne).
2. Version PHP : passer de PHP 7.x à 8.x apporte un gain de performance gratuit une fois la compatibilité vérifiée.
3. Appels externes bloquants : une page qui interroge une API tierce à chaque chargement attend sa réponse avant d'envoyer le premier octet. Ces appels doivent être mis en cache ou sortis du chemin critique.

Checklist TTFB

• [ ] TTFB mesuré (DevTools / curl) — une page vs tout le site
• [ ] Cache de page actif sur les pages non personnalisées
• [ ] Poids autoload de wp_options vérifié et nettoyé
• [ ] Révisions / transients / options orphelines purgés
• [ ] PHP en 8.x
• [ ] Appels d'API tiers mis en cache / hors chemin critique
• [ ] CDN ajouté après l'optimisation de l'origine

Questions fréquentes

Qu'est-ce qu'un bon TTFB ?

En dessous de 200 ms est excellent, jusqu'à 500 ms acceptable, au-delà de 800 ms problématique. Le TTFB pèse directement sur le LCP : tant qu'il est haut, aucune optimisation d'image ou de JavaScript ne rendra la page rapide.

Un CDN réduit-il le TTFB ?

En partie, en rapprochant le contenu et en absorbant de la charge — mais uniquement après avoir optimisé le serveur d'origine. Mettre un CDN devant un serveur mal configuré ne fait que déplacer le problème.

Le cache suffit-il à régler un TTFB élevé ?

Souvent oui pour les pages publiques identiques pour tous. Mais les pages personnalisées (panier, compte) ne se mettent pas en cache de page : là, il faut agir sur la base, le PHP et l'hébergement.

Comment savoir si c'est l'hébergement ou WordPress ?

Si une seule page est lente, c'est applicatif (extension, requête). Si tout le site rame malgré cache et base propres, c'est l'hébergement. La mesure page par page tranche.

Quand faire appel à HelpApp Pro

Le TTFB a rarement une cause unique : c'est un empilement où l'on gagne en traitant le maillon dominant d'abord. HelpApp Pro fait ce diagnostic — cache, base, hébergement, PHP, appels externes — et applique les correctifs prioritaires, sans vendre une refonte quand un réglage suffit. Décrivez votre site via le devis en ligne, ou consultez notre page diagnostic technique.