210 millisecondes contre 18. Voilà l’écart brut relevé entre le temps de première réponse d’un même site WordPress ouvert dans Studio, l’application de développement local publiée par WordPress.com en 2024, et celui du même site déployé chez Kinsta. Un chiffre qui, pris tel quel, ne veut strictement rien dire.
Cette comparaison revient pourtant régulièrement dans les échanges entre développeurs qui cherchent à choisir un hébergeur : ils testent leur projet en local, constatent une rapidité déconcertante, puis s’étonnent du ralentissement une fois le site mis en ligne. Le raisonnement mérite d’être posé avec plus de rigueur.
Ce que Studio mesure réellement
Studio fait tourner WordPress dans un conteneur local, sans connexion réseau externe, sans autre visiteur simultané, et généralement sur un poste équipé d’un SSD rapide et de plusieurs cœurs disponibles pour la seule requête en cours. Le temps de première réponse y est donc presque exclusivement celui de l’exécution PHP et des requêtes à la base de données, sans latence de transport ni file d’attente serveur.
C’est un excellent outil pour repérer une requête SQL anormalement lente ou un plugin qui alourdit le chargement, précisément parce que le bruit du réseau est éliminé. Mais cette absence de bruit devient un piège dès qu’on veut en tirer une conclusion sur l’expérience réelle des visiteurs.
Ce que Kinsta ajoute à la mesure
Chez un hébergeur infogéré comme Kinsta, la requête traverse un équilibrage de charge, potentiellement un cache Edge basé sur Cloudflare, avant d’atteindre le conteneur applicatif. Cette couche supplémentaire peut aussi bien accélérer une page déjà en cache que ralentir une page dynamique dont le cache vient d’être purgé.
| Facteur | Studio (local) | Hébergement infogéré |
|---|---|---|
| Latence réseau | quasi nulle | dépend de la localisation du visiteur |
| Charge concurrente | aucune | variable selon le trafic réel |
| Cache de page | généralement absent | souvent actif par défaut |
| Ressources serveur | celles du poste local | partagées ou dédiées selon l’offre |
Comment rendre la comparaison utile malgré tout
Comparer un TTFB local et un TTFB hébergé n’a de sens que si l’on précise ce que l’on veut vérifier. Trois usages restent légitimes :
- Vérifier qu’une régression vient bien du code et non de l’hébergement, en comparant les deux avant et après une modification
- Isoler l’effet du cache de page en désactivant volontairement les couches de cache côté hébergeur pour une mesure à froid
- Suivre l’évolution du TTFB local dans le temps, comme indicateur relatif de la charge ajoutée par de nouvelles extensions
En revanche, annoncer un TTFB de production simplement en extrapolant une mesure locale reste une erreur méthodologique. Pour obtenir un chiffre représentatif, il faut mesurer depuis un point du réseau proche des visiteurs réels, avec l’outil curl et son format de sortie détaillé :
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://exemple.fr/Une méthode de test à froid reproductible
Pour comparer deux hébergeurs entre eux, la seule mesure qui tienne consiste à désactiver temporairement tout cache de page, purger l’objet cache, puis relancer la même requête plusieurs fois de suite depuis un même point de mesure externe, en ne gardant que la médiane des résultats. Une seule mesure isolée reste toujours suspecte, qu’elle vienne de Studio ou d’un hébergeur.
Un TTFB flatteur en local ne prouve rien d’autre que l’absence de bruit ; c’est en production, sous charge réelle, que se joue la vraie partie.
Notre verdict
Studio reste un outil précieux pour développer et déboguer, pas pour évaluer un hébergeur. La comparaison brute entre un TTFB local et un TTFB de production relève du contresens statistique : les deux environnements ne mesurent pas la même chose. Ce billet ne traite pas du coût des différentes offres d’hébergement, qui mériterait son propre comparatif indépendant du seul TTFB.
