Sommaire
Un site peut sembler rapide sans que son serveur d’hébergement réponde vite : un réseau de diffusion peut rapprocher le contenu du visiteur. Nos relevés de TTFB donnent un point de comparaison concret, mais ne désignent pas automatiquement le meilleur hébergeur.
Ce que mesure le TTFB, et ce que montrent nos relevés
Le TTFB, ou temps de réponse jusqu’au premier octet, correspond au délai avant que le navigateur reçoive le début de la réponse. C’est un indicateur de réactivité utile pour comprendre l’attente initiale, mais il ne résume pas à lui seul la vitesse ressentie sur une page : il ne dit pas combien de temps les images, les scripts ou le reste du contenu mettent à s’afficher.
Les chiffres ci-dessous viennent de nos propres relevés dans Chrome, effectués sur des sites réels. Ils indiquent le TTFB médian observé pour chaque hébergeur et la taille du panel. La médiane donne un repère central plutôt qu’une moyenne tirée par quelques valeurs extrêmes. Les panels ne sont toutefois pas identiques en taille, et leur composition peut peser sur le résultat : ces données décrivent les sites mesurés, pas une garantie de performance pour chaque client.
La réserve à lire avant de comparer les résultats
Chez Shopify, Kinsta, WP Engine, Vercel, Amazon Web Services (AWS), la majorité des sites du panel sont servis depuis un réseau de diffusion : le temps relevé est celui d’un point de présence proche du visiteur, pas celui d’un serveur d’hébergement. Leur avance ne se compare donc pas à celle d’un hébergeur classique, et il faut le dire plutôt que de les couronner.
Ce n’est pas une nuance secondaire : la mesure reste pertinente pour l’attente vécue par le visiteur, mais elle ne permet pas d’attribuer le résultat au seul serveur d’hébergement. Dans le panel Shopify, 100 % des sites sont servis depuis un réseau de diffusion ; pour AWS, la proportion est de 69 %. Une partie de l’écart observé peut donc tenir à l’emplacement du point de présence qui répond. Les données disponibles ne précisent pas la part correspondante pour Kinsta, WP Engine ou Vercel : cette réserve ne doit pas être transformée en score ou en classement pour ces services.
Les TTFB médians relevés, hébergeur par hébergeur
- Shopify : 531 ms, sur 20 sites réels ; 100 % du panel est servi depuis un réseau de diffusion.
- Amazon Web Services (AWS) : 601 ms, sur 20 sites réels ; 69 % du panel est servi depuis un réseau de diffusion.
- Squarespace : 607 ms, sur 20 sites réels.
- Railway : 694 ms, sur 9 sites réels.
- Gandi : 698 ms, sur 20 sites réels.
- one.com : 726 ms, sur 20 sites réels.
- o2switch : 765 ms, sur 20 sites réels.
- AlwaysData : 781 ms, sur 20 sites réels.
- LWS : 802 ms, sur 20 sites réels.
- Google Cloud Platform : 819 ms, sur 20 sites réels.
- Azure : 835 ms, sur 20 sites réels.
- WordPress.com : 858 ms, sur 20 sites réels.
Quel verdict tirer de l’écart entre les hébergeurs ?
Shopify affiche le TTFB médian le plus bas de cette série, suivi par AWS et Squarespace. Ce constat vaut pour les sites mesurés. Il ne suffit pas à placer ces offres en tête d’un palmarès général : la réserve sur les réseaux de diffusion change le sens de la comparaison. Pour un lecteur qui hésite entre un service de boutique et un hébergement classique, le résultat de Shopify répond à une question de réactivité vécue, mais ne mesure pas à lui seul la performance du serveur d’hébergement. Le guide pour choisir entre WooCommerce, PrestaShop et Shopify aide à remettre cette donnée dans le contexte du projet.
Les résultats de Squarespace, Railway et Gandi se situent dans une zone assez rapprochée au regard des relevés : 607 ms, 694 ms et 698 ms. Cela ne prouve pas que ces services se comporteront de la même façon sur votre site. Le panel de Railway compte 9 sites réels, contre 20 pour les autres fournisseurs cités dans cette comparaison ; sa médiane repose donc sur un échantillon plus réduit. La mesure permet de repérer un signal, pas d’effacer cette limite.
Plus loin dans la série, o2switch et AlwaysData sont mesurés à 765 ms et 781 ms. L’écart avec LWS, à 802 ms, ou Google Cloud Platform, à 819 ms, ne permet pas à lui seul de trancher un achat. Pour les sites construits sur WordPress, le choix d’une offre adaptée, la configuration du site et les fonctionnalités incluses comptent aussi. Comparez par exemple les offres d’hébergement WordPress en gardant le TTFB comme un critère parmi d’autres.
Choisir selon votre usage, pas selon une seule mesure
Un TTFB bas peut être un avantage si la réactivité initiale est une priorité, mais il ne remplace pas une comparaison des services rendus. Un site marchand, un blog et une application ne sollicitent pas nécessairement les mêmes ressources. Vérifiez donc que l’offre correspond à votre usage, puis examinez les autres critères importants pour vous, comme la facilité de gestion, les possibilités d’évolution et le type d’assistance proposé. Ces relevés ne fournissent pas de données sur ces aspects : ils ne permettent pas de les départager.
Il faut également distinguer un hébergement mutualisé d’une infrastructure cloud ou d’une offre destinée à des usages plus techniques. Les catégories ne recouvrent pas les mêmes besoins, et la médiane mesurée sur des sites existants ne prédit pas la réponse de votre futur projet. Pour clarifier ce que recouvre le cloud et les situations où il peut être utile, examinez les caractéristiques de l’offre plutôt que son seul nom commercial. Le comparatif d’hébergement mutualisé peut aussi servir de repère si vous recherchez une formule classique.
En pratique, retenez le TTFB comme une observation de la réponse initiale des sites du panel, mesurée dans Chrome. Les résultats signalent des écarts, mais le recours aux réseaux de diffusion chez Shopify et AWS — et la réserve concernant Kinsta, WP Engine et Vercel — interdit de confondre ces valeurs avec un test isolé des serveurs. Pour départager deux offres adaptées à votre projet, ce relevé apporte un indice utile, pas un verdict universel.
Pour aller plus loin
