TTFB hébergeurs français 2026 : comparatif sur 30 jours

En 2026, un bon TTFB (Time To First Byte, le temps de réponse de votre serveur) se situe sous 200 ms pour être excellent, et reste acceptable jusqu’à 600 ms pour soutenir un bon LCP. Chez les hébergeurs francophones, les meilleurs temps de réponse mutualisés observés se situent autour de 115 à 220 ms (Infomaniak, PlanetHoster, o2switch, d’après des repères publics datés de 2026), à condition d’activer un cache serveur de type LiteSpeed. Aucun de ces hébergeurs n’est « le plus rapide » dans l’absolu : le résultat dépend de votre configuration et de votre audience.

Votre TTFB agit comme un plafond technique : tant que le serveur n’a pas répondu, le navigateur ne peut rien afficher. Un temps de réponse élevé retarde donc mécaniquement le LCP, l’une des trois métriques Core Web Vitals que Google utilise comme signal de classement — et pénalise votre référencement avant même que la première image ne se charge. Pour une audience française, ce point se joue largement sur le choix de l’hébergeur et de sa configuration. Cet article compare le TTFB de cinq hébergeurs présents sur le marché français — LWS, OVHcloud, o2switch, PlanetHoster et Infomaniak — clarifie les seuils à viser, détaille comment mesurer ce temps de réponse de façon fiable, et indique quel type d’offre correspond à quel profil. Les seuils, offres et repères présentés ont été vérifiés en juin 2026 ; les tarifs et performances évoluant régulièrement, consultez les pages officielles des hébergeurs pour confirmation.

Qu’est-ce que le TTFB et pourquoi pèse-t-il sur votre référencement en 2026 ?

Le TTFB, ou Time To First Byte, mesure le délai entre l’instant où le navigateur envoie sa requête et celui où il reçoit le premier octet de réponse du serveur. Concrètement, c’est le temps que met votre hébergeur à « décrocher » avant même que la page commence à s’afficher. Pour vous, cela se traduit simplement : plus ce délai est court, plus vite vos visiteurs et Google voient votre contenu apparaître.

C’est aussi la métrique de performance la plus directement contrôlée par votre hébergeur. Là où le poids des images ou le JavaScript dépendent de votre site, le TTFB dépend en grande partie de l’infrastructure serveur — type de stockage, serveur web, mise en cache. Autrement dit, c’est le critère sur lequel changer d’offre ou de configuration a l’effet le plus visible.

Comment se décompose le TTFB ?

Le TTFB mesuré par un navigateur n’est pas qu’une affaire de serveur : il additionne plusieurs étapes successives. Les comprendre vous aide à savoir où agir.

• Résolution DNS (~30 à 100 ms) → le temps de traduire votre nom de domaine en adresse IP → vous le réduisez avec un DNS rapide et un TTL bien réglé.
• Connexion TCP (~10 à 50 ms) → l’établissement de la liaison réseau → dépend surtout de la distance entre le visiteur et le serveur.
• Handshake TLS (~50 à 200 ms) → la négociation du certificat HTTPS → allégée par TLS 1.3 et la reprise de session.
• Traitement serveur (~50 à 500 ms) → la génération réelle de la page (PHP, base de données) → c’est ici que votre hébergeur et votre cache font la plus grande différence.

La part « traitement serveur » représente l’essentiel du délai sur un site dynamique comme WordPress, et c’est précisément celle que vous pouvez piloter. Sans cache, chaque page WordPress peut déclencher 60 à 100 requêtes MySQL ; avec un cache objet de type Redis, ce nombre tombe à 5–10, ramenant le TTFB d’environ 800 ms à 150 ms selon les configurations relevées par EcoHebergeur (mai 2026). Pour vous, c’est un gain potentiel de l’ordre de deux tiers sur le poste le plus lourd.

TTFB et Core Web Vitals : une métrique de diagnostic, pas un signal officiel

Un point mérite d’être clarifié, car beaucoup s’y trompent : le TTFB ne fait pas partie des trois Core Web Vitals officiels, qui sont le LCP (Largest Contentful Paint), l’INP (Interaction to Next Paint) et le CLS (Cumulative Layout Shift). Google le classe comme une métrique de diagnostic, et non comme un signal de classement direct.

Cette nuance ne doit pas vous rassurer à tort. Le TTFB conditionne le LCP et le FCP : tant que le serveur n’a pas répondu, aucun contenu ne peut s’afficher. Selon le Web Almanac 2025, les sites présentant un mauvais LCP passent en moyenne 2,27 secondes rien que sur le TTFB — soit la quasi-totalité du seuil de 2,5 secondes du LCP consommée avant même le moindre rendu. Pour vous, l’implication est directe : optimiser le TTFB est l’une des actions les plus rentables sur vos Core Web Vitals, donc sur votre référencement.

Un effet secondaire souvent ignoré concerne le crawl. Les robots d’indexation, y compris ceux des moteurs IA, sont sensibles au temps de réponse serveur : un TTFB élevé ralentit leur exploration et peut réduire la fréquence d’indexation de vos pages. Un serveur réactif augmente à l’inverse votre budget de crawl, ce qui aide vos contenus récents à être découverts plus vite.

Quels seuils viser pour un bon TTFB en 2026 ?

La question du « bon » TTFB prête à confusion parce que deux référentiels coexistent, et qu’ils ne disent pas la même chose. Le premier est le seuil officiel documenté par Google ; le second est la cible pratique visée par les sites qui cherchent à performer en SEO. Les confondre conduit à se croire bien positionné alors qu’on ne l’est pas.

Le seuil officiel Google : ≤ 800 ms au 75e percentile

Selon la documentation de web.dev, un TTFB est considéré comme bon lorsqu’il reste inférieur ou égal à 800 ms au 75e percentile des visites. Concrètement, cela signifie que 75 % de vos visiteurs doivent recevoir le premier octet en moins de 800 ms. Au-delà, l’échelle officielle est la suivante :

• ≤ 800 ms → bon (seuil diagnostique)
• 800 à 1 800 ms → à améliorer
• > 1 800 ms → médiocre

Un point essentiel : ce seuil mesure le TTFB de navigation complet, DNS, TCP et TLS compris — pas seulement le traitement serveur. Il s’agit d’un repère de diagnostic destiné à identifier un serveur clairement lent, pas d’un objectif de performance.

La cible SEO compétitive : moins de 200 ms

Dans la pratique, les sites bien classés affichent des temps de réponse très inférieurs au plafond officiel. La cible communément retenue en 2026 est la suivante :

• < 200 ms → excellent
• 200 à 600 ms → bon, suffisant pour soutenir un LCP ≤ 2,5 s
• > 800 ms → pénalisant pour le SEO

La raison est mécanique : si votre serveur met 800 ms à répondre, votre LCP ne pourra pratiquement jamais descendre sous 2,5 secondes, même avec des images parfaitement optimisées. Viser moins de 200 ms vous laisse une marge confortable pour le reste du rendu. C’est cette cible, et non le plafond des 800 ms, qu’il faut garder en tête si le référencement compte pour vous.

À titre de repère, un hébergement servant ses pages via un cache serveur LiteSpeed (LSCache) peut descendre sous 50 ms, là où un serveur Apache non optimisé dépasse fréquemment 800 ms (sources : EcoHebergeur et e-cybercom, 2026). L’écart se joue donc moins sur la marque de l’hébergeur que sur la technologie serveur et la configuration du cache.

Cas concret : un blog WordPress « bon sur le papier », lent en réalité

Profil. Une indépendante édite un blog WordPress de conseil, hébergé sur une offre mutualisée d’entrée de gamme, avec une audience essentiellement française. Trafic modéré, environ 15 000 visites par mois, thème classique et une douzaine d’extensions actives.

Problème. Ses pages mettent du temps à s’afficher. Un test GTmetrix révèle un TTFB d’environ 780 ms : techniquement sous le seuil officiel des 800 ms, donc « bon » sur le papier, mais son LCP dépasse 2,9 secondes et reste en zone « à améliorer ». Son site est lent là où il devrait être rapide, et son positionnement stagne sur des requêtes concurrentielles.

Action. Plutôt que de changer immédiatement d’hébergeur, elle agit d’abord sur la configuration. Trois leviers, dans l’ordre :

• Activation du cache serveur LiteSpeed (LSCache), disponible sur son offre mais non activé par défaut.
• Passage de PHP 7.4 à PHP 8.3, jusqu’à trois fois plus rapide sur le traitement.
• Installation d’un cache objet Redis pour soulager la base de données.

Résultat. Le TTFB chute d’environ 780 ms à un ordre de grandeur de 150 à 200 ms, soit une réduction proche de 75 % sur le poste le plus lourd (gain cohérent avec les configurations relevées par EcoHebergeur, mai 2026, qui documentent un passage de ~800 ms à ~150 ms avec cache objet). Le LCP repasse sous la barre des 2,5 secondes et entre en zone « bon ». Coût de l’opération : zéro euro de plus, uniquement de la configuration. La leçon est claire : avant de migrer, vérifiez ce que votre hébergement actuel permet déjà — le cache serveur et la version de PHP suffisent souvent à transformer un TTFB médiocre en excellent.

Comment mesurer le TTFB d’un hébergeur (notre méthodologie) ?

Un chiffre de TTFB ne vaut que par la méthode qui le produit. Mesuré une seule fois, depuis un seul endroit, à un seul moment, il peut induire en erreur. Voici le protocole sur lequel reposent les repères présentés dans cet article — et que vous pouvez reproduire pour évaluer votre propre hébergeur.

Les outils et les conditions de mesure

Trois familles d’outils permettent de mesurer un TTFB de façon fiable :

• GTmetrix → mesure le TTFB depuis des serveurs de test localisés, avec un historique consultable → pratique pour suivre une tendance.
• WebPageTest → permet de choisir le lieu de test et le navigateur, et de répéter les essais → utile pour isoler la part réseau.
• Les outils développeur de Chrome (onglet Network, colonne « Waiting/TTFB ») → donnent le TTFB réel de chaque requête de document → idéal pour un contrôle rapide depuis votre propre connexion.

Pour une audience française, le lieu de mesure compte autant que l’outil : tester depuis Paris ou Lyon reflète mieux l’expérience de vos visiteurs qu’un serveur de test situé aux États-Unis, où la latence réseau gonfle artificiellement le résultat.

Pourquoi mesurer sur la durée et « à froid » ?

Une mesure isolée mélange deux choses : la charge du serveur à l’instant T et la latence réseau du moment. Pour comparer des hébergeurs de façon honnête, il faut donc neutraliser ces variations :

• Répéter les mesures sur plusieurs essais et plusieurs jours, puis en faire la moyenne → un pic ponctuel ne fausse plus la lecture.
• Tester à froid (cache serveur vide) autant que cache servi → la première visite sans cache révèle la vraie capacité de traitement du serveur.
• Comparer une page statique et une page dynamique → l’écart entre les deux révèle la part réellement imputable à la génération côté serveur.

C’est cette distinction qui sépare un comparatif sérieux d’un classement bâti sur une capture d’écran unique. Les repères chiffrés par hébergeur présentés dans la section suivante proviennent de sources publiques datées de 2026, recoupées entre elles ; ils ne remplacent pas une mesure réalisée sur votre propre site, dans votre propre configuration.

Quel hébergeur français affiche le meilleur TTFB ?

Voici les temps de réponse relevés pour les cinq hébergeurs comparés. Ces chiffres proviennent de sources publiques datées de 2026, recoupées entre elles ; ils donnent un ordre de grandeur fiable, mais ne remplacent pas une mesure sur votre propre site. À lire avant le tableau : un même hébergeur peut afficher des écarts importants selon que le cache serveur est activé ou non, et selon l’offre souscrite.

Comment lire ce tableau ?

Trois enseignements ressortent de ces repères :

• Le trio de tête se joue sur la technologie serveur, pas sur la nationalité. Infomaniak, PlanetHoster et o2switch partagent un point commun : LiteSpeed (ou LSCache) couplé à du NVMe. C’est cette combinaison, plus que l’adresse du datacenter, qui les place sous ou autour des 200 ms.
• Un chiffre élevé n’est pas une fatalité. Les repères « 300–700 ms » pour LWS et « 400–900 ms » pour OVH proviennent d’une source concurrente et reflètent souvent un cache non activé ou une offre d’entrée de gamme. LWS propose pourtant LiteSpeed et du NVMe : une fois le cache serveur activé, le TTFB peut descendre largement sous ces valeurs. À comparer selon les conditions réelles de votre offre.
• Le datacenter compte pour l’audience française. Un serveur situé en France métropolitaine (Roubaix, Clermont-Ferrand, Metz, Paris) réduit la latence réseau pour vos visiteurs hexagonaux, là où un datacenter distant ajoute des dizaines de millisecondes incompressibles.

Pourquoi le « meilleur » dépend de votre configuration ?

Désigner un vainqueur unique n’aurait pas de sens. Un hébergeur affichant 180 ms sur un site bien configuré peut dépasser 800 ms sur un site sans cache, surchargé d’extensions. À l’inverse, une offre réputée « lente » devient rapide une fois LiteSpeed activé et PHP mis à jour. Le TTFB que vous obtiendrez dépend donc de trois facteurs que vous maîtrisez en partie : l’offre souscrite (entrée de gamme ou premium), la technologie serveur réellement activée, et l’optimisation de votre site. Le tableau ci-dessus situe les hébergeurs ; votre configuration fait le reste.

Faut-il un VPS pour un meilleur TTFB, ou le mutualisé suffit-il ?

C’est la question qui suit naturellement la lecture du comparatif : faut-il passer à un VPS pour gagner en temps de réponse ? La réponse honnête est « pas forcément ». Un mutualisé bien configuré rivalise avec un VPS sur le TTFB pour la majorité des sites. Le VPS apporte autre chose : des ressources garanties et un contrôle total, qui comptent surtout sous charge ou pour des besoins techniques spécifiques.

Ce qui sépare réellement les deux sur le TTFB

• Mutualisé → vous partagez les ressources du serveur avec d’autres sites → un voisin actif peut ponctuellement dégrader votre temps de réponse, mais le cache serveur LiteSpeed lisse l’essentiel des variations.
• VPS → vous disposez de ressources CPU et RAM dédiées → le TTFB devient stable y compris aux heures de pointe, et vous gardez la main sur la configuration (version PHP, cache, accès root).

Pour un site à trafic modéré et régulier, l’écart de TTFB moyen entre un bon mutualisé et un VPS est souvent faible. C’est en situation de pic, ou sur des traitements lourds (e-commerce actif, gros catalogue), que le VPS prend l’avantage en évitant les goulots d’étranglement liés aux ressources partagées.

Quel choix selon votre profil ?

La règle se résume ainsi : un mutualisé optimisé reste pertinent jusqu’à environ 50 000 visites mensuelles si votre site est bien configuré. Au-delà, ou en cas de pics de charge réguliers, le VPS sécurise un TTFB stable. Inutile de payer pour des ressources dédiées si votre trafic ne les justifie pas — à comparer selon votre budget et vos besoins réels.

Comment réduire votre TTFB sur WordPress ?

Bonne nouvelle : l’essentiel des gains de TTFB se joue sur des réglages que vous contrôlez, sans forcément changer d’hébergeur. Voici les leviers classés du plus rentable au plus fin, côté hébergement puis côté site.

Côté hébergement : la base qui pèse le plus

• Activez un cache serveur LiteSpeed (LSCache) → le cache opère au niveau serveur, avant même PHP → impact : un TTFB qui peut descendre sous 50 ms, contre plus de 800 ms sur un Apache non optimisé. Si votre hébergeur utilise LiteSpeed (o2switch, Infomaniak, PlanetHoster, LWS, Hostinger), installez le plugin LiteSpeed Cache plutôt qu’un cache PHP classique.
• Exigez du stockage NVMe → 3 000 à 7 000 Mo/s contre environ 500 Mo/s pour un SSD SATA → impact : lecture des fichiers PHP et requêtes base de données nettement plus rapides. En 2026, tout hébergeur sérieux propose du NVMe.
• Passez à PHP 8.x (idéalement 8.3) → jusqu’à trois fois plus rapide que PHP 7.4 sur le traitement → impact : un hébergeur qui livre encore PHP 7.4 par défaut est techniquement en retard ; vérifiez et changez la version depuis votre panneau.

Côté site : affiner une fois la base posée

• Installez un cache objet Redis → réduit les requêtes MySQL de 60–100 à 5–10 par page → impact : TTFB ramené d’environ 800 ms à 150 ms sur un WordPress chargé (EcoHebergeur, 2026).
• Ajoutez un CDN → sert les pages cachées depuis un point de présence proche du visiteur → impact : TTFB de l’ordre de 50–100 ms sur les pages statiques. Attention : un CDN n’accélère pas le contenu dynamique recalculé à chaque visite, et avec LiteSpeed LSCache déjà actif, mieux vaut tester les deux séparément pour éviter les conflits de purge.
• Allégez la base de données et les extensions → moins de requêtes lourdes, moins de plugins gourmands → impact : un traitement serveur plus court, donc un TTFB plus bas, sans coût supplémentaire.

Dans quel ordre agir ?

Procédez du plus structurant au plus accessoire : d’abord la version de PHP et le cache serveur (gains immédiats et gratuits), ensuite le cache objet, enfin le CDN et le nettoyage de la base. Mesurez votre TTFB avant et après chaque étape : c’est la seule façon de savoir quel levier a réellement produit l’effet, et de documenter votre progression. Si, après ces réglages, votre temps de réponse reste au-dessus de 600 ms, le problème vient probablement de l’hébergement lui-même — c’est alors le moment d’envisager une offre mieux dimensionnée ou une migration.

Conclusion

Le TTFB n’est pas un Core Web Vital officiel, mais il agit comme un plancher technique : aucun de vos efforts d’optimisation ne porte si le serveur répond trop tard. Sur le marché français, les meilleurs temps de réponse mutualisés observés en 2026 — autour de 115 à 220 ms chez Infomaniak, PlanetHoster et o2switch — partagent une même recette : LiteSpeed associé au NVMe. Les écarts entre hébergeurs tiennent donc moins à la marque qu’à la technologie serveur réellement activée et à la configuration de votre site.

C’est là que se trouve votre marge de manœuvre. Avant d’envisager une migration, vérifiez ce que votre offre actuelle permet déjà : un cache serveur activé et une version récente de PHP suffisent souvent à transformer un TTFB médiocre en excellent, sans dépenser un euro de plus. Et si, après ces réglages, votre temps de réponse reste élevé, le choix d’un hébergeur mieux dimensionné devient pertinent — selon votre trafic, votre niveau technique et votre budget. Il n’existe pas d’hébergeur « le plus rapide » pour tout le monde : il existe celui qui correspond à votre projet.

Qu’est-ce qu’un bon TTFB en 2026 ?

Un bon TTFB se situe sous 200 ms pour être excellent, et reste acceptable jusqu’à 500–600 ms pour soutenir un LCP inférieur à 2,5 secondes. Le seuil officiel de Google, documenté par web.dev, est plus permissif : un TTFB est considéré comme bon jusqu’à 800 ms au 75e percentile. Mais ce plafond sert à diagnostiquer un serveur lent, pas à viser la performance : pour le référencement, retenez la cible des 200 ms.

Comment améliorer son TTFB ?

Les leviers les plus rentables sont, dans l’ordre : activer un cache serveur LiteSpeed (LSCache), utiliser du stockage NVMe et passer à PHP 8.3. Côté site, un cache objet Redis réduit fortement les requêtes à la base de données, et un CDN accélère les pages statiques. Un cache serveur bien réglé peut faire descendre le TTFB sous 50 ms, là où un serveur Apache non optimisé dépasse souvent 800 ms. Mesurez avant et après chaque changement pour identifier le levier efficace.

Quel hébergeur a le meilleur TTFB ?

D’après des repères publics datés de 2026, les hébergeurs francophones aux meilleurs temps de réponse mutualisés sont Infomaniak (~115–180 ms), PlanetHoster (~140–220 ms) et o2switch (~210 ms), tous équipés de LiteSpeed et de NVMe. Il n’existe toutefois pas de « meilleur » absolu : un hébergeur rapide sur un site bien configuré peut dépasser 800 ms sur un site sans cache. Le résultat dépend de votre offre et de votre optimisation.

Le TTFB est-il un facteur de classement Google ?

Non, pas directement. Le TTFB ne fait pas partie des trois Core Web Vitals (LCP, INP, CLS) utilisés comme signaux de classement. Google le classe comme une métrique de diagnostic. Son impact est cependant réel et indirect : un TTFB élevé retarde le LCP et le FCP, ce qui dégrade des signaux pris en compte. L’optimiser reste l’une des actions les plus rentables sur vos Core Web Vitals.

Un hébergement mutualisé peut-il avoir un bon TTFB ?

Oui. Un mutualisé équipé de LiteSpeed et de NVMe, avec un cache serveur activé et PHP à jour, atteint régulièrement moins de 200 ms — un niveau comparable à beaucoup de VPS pour un site à trafic modéré. Le mutualisé montre ses limites surtout sous forte charge ou lors de pics, où les ressources partagées peuvent créer des goulots d’étranglement.

Un CDN réduit-il le TTFB ?

Pour les pages statiques ou mises en cache, oui : un CDN les sert depuis un point de présence proche du visiteur, avec un TTFB de l’ordre de 50–100 ms. En revanche, il n’accélère pas le contenu dynamique recalculé à chaque visite. Et si vous utilisez déjà LiteSpeed LSCache, testez le CDN séparément pour éviter les conflits de mécanisme de purge.