Comment réduire le TTFB (Time to First Byte)

Réduire le TTFB, c’est raccourcir le délai entre le moment où un navigateur demande une page et celui où il reçoit le premier octet de la réponse. En pratique, cela passe par trois leviers : faire générer le HTML plus vite par le serveur et l’application, servir du HTML en cache pour que la plupart des requêtes évitent complètement ce travail, et rapprocher la réponse de vos visiteurs. Ce guide montre comment identifier lequel des trois vous freine et que faire pour chacun.

Ce que mesure le TTFB

Le Time to First Byte n’est pas une valeur unique. C’est la somme de plusieurs phases qui se déroulent avant l’arrivée du moindre contenu :

1. Les redirections, si l’URL demandée renvoie d’abord ailleurs.
2. La résolution DNS, qui transforme votre nom de domaine en adresse IP.
3. L’établissement de la connexion, la poignée de main TCP plus la négociation TLS pour le HTTPS.
4. La requête et le traitement serveur, le temps que votre serveur passe à construire la réponse (exécuter PHP, interroger la base de données, rendre les templates).
5. Le retour du premier octet vers le navigateur.

C’est pourquoi deux sites hébergés sur des serveurs identiques peuvent avoir des TTFB très différents : l’un est peut-être proche de ses visiteurs et sert des pages en cache, tandis que l’autre se trouve sur un autre continent et génère chaque requête de zéro.

Le TTFB ne fait pas partie des trois Core Web Vitals, mais il se trouve sous chacun d’eux. Rien ne peut s’afficher avant l’arrivée du premier octet : un TTFB lent retarde donc directement le Largest Contentful Paint. Si votre LCP est mauvais, le TTFB fait partie des premières choses à vérifier. Le guide sur les Core Web Vitals explique comment ces métriques sont liées.

Qu’est-ce qu’un bon TTFB ?

Les recommandations de web.dev sur le TTFB (en anglais) conseillent à la plupart des sites de viser un TTFB de 0,8 seconde ou moins, mesuré au 75e percentile des chargements de pages réels. Au-delà de 1,8 seconde, la valeur est jugée mauvaise.

Deux points méritent d’être gardés en tête. D’abord, ces chiffres décrivent de vrais utilisateurs sur de vrais réseaux, y compris des connexions mobiles lentes loin de votre serveur. Un test lancé depuis votre bureau, à côté du centre de données, paraîtra bien meilleur que ce que vit un visiteur sur un autre continent. Ensuite, 0,8 s est un repère indicatif, pas une note de passage stricte. Les sites entièrement rendus côté client peuvent tolérer un peu plus ; les sites rendus côté serveur, ce qui couvre la plupart des installations WordPress et des boutiques, ont intérêt à descendre bien en dessous.

Mesurer le TTFB et trouver la phase lente

Avant de changer quoi que ce soit, mesurez où part le temps. Une vérification rapide en ligne de commande :

curl -o /dev/null -s -w "dns:      %{time_namelookup}\nconnect:  %{time_connect}\ntls:      %{time_appconnect}\nttfb:     %{time_starttransfer}\ntotal:    %{time_total}\n" https://example.com/

Chaque valeur est cumulée, en secondes. Faites les soustractions pour obtenir les phases :

• connect - dns correspond à l’aller-retour réseau jusqu’au serveur.
• tls - connect correspond à la négociation HTTPS.
• ttfb - tls correspond à peu près au temps de traitement serveur plus un aller-retour.

Lancez la commande plusieurs fois, car la première requête paie souvent un cache froid ou une nouvelle résolution DNS. Si ttfb - tls reste élevé (plusieurs centaines de millisecondes ou plus, par exemple) alors que les phases réseau sont courtes, votre serveur est le goulot d’étranglement. Si les phases réseau sont longues, le problème vient de la distance et du coût des connexions.

Pour obtenir des chiffres d’utilisateurs réels, testez la page sur corewebvitals.page et regardez les données terrain des utilisateurs de Chrome, disponibles quand votre site a assez de trafic. Dans les Chrome DevTools, l’onglet Réseau affiche le détail des délais de chaque requête : l’attente de la réponse du serveur correspond à la partie serveur du TTFB. Le guide pour mesurer la vitesse d’un site explique comment combiner ces sources sans vous tromper vous-même.

Accélérer le serveur et l’application

Si le temps de traitement domine, la correction se fait sur l’origine. Procédez dans cet ordre, du moins coûteux au plus lourd :

Mettre à jour l’environnement d’exécution

Les versions récentes de PHP, Node.js ou Python sont souvent nettement plus rapides pour le même travail. Vérifiez quelle version fait tourner votre hébergeur et si votre CMS et vos extensions en supportent une plus récente.

Ajouter un cache d’objets

WordPress, WooCommerce, Shopware, Magento et Drupal exécutent tous de nombreuses requêtes répétées en base de données. Un cache d’objets persistant comme Redis ou Memcached conserve ces résultats en mémoire d’une requête à l’autre. De nombreux hébergeurs infogérés le proposent sous forme d’option à activer.

Repérer les requêtes et extensions lentes

Une seule extension qui lance une requête coûteuse à chaque chargement de page peut dominer le TTFB. Utilisez un profileur ou un outil de suivi des requêtes sur une copie de préproduction, désactivez les suspects un par un et mesurez à nouveau. Sur les boutiques, les filtres à facettes, les widgets de produits associés et les consultations de stock en temps réel sont des coupables fréquents.

Vérifier les ressources du serveur

Si le TTFB est correct la nuit mais mauvais aux heures de pointe, le serveur manque de CPU, de mémoire ou de workers PHP. Plus de ressources ou une meilleure offre d’hébergement peuvent alors être la bonne décision, et aucune optimisation front-end n’y changera rien.

Mettre en cache les pages HTML complètes

La plupart des requêtes adressées à un site classique portent sur des pages identiques pour tous les visiteurs anonymes. Les générer de zéro à chaque fois est du travail gaspillé. Un cache de pages complètes stocke le HTML final et le renvoie sans solliciter PHP ni la base de données, ce qui a généralement l’effet le plus important sur le TTFB.

Vous pouvez mettre en cache à différents niveaux :

• Dans l’application, avec une extension de cache ou un cache HTTP intégré (Shopware et Drupal en embarquent un). La documentation de WordPress sur le cache (en anglais) donne une bonne vue d’ensemble des options.
• Sur le serveur, avec un reverse proxy comme Varnish ou un cache Nginx.
• En edge, sur un CDN ou un réseau edge, pour que les pages en cache soient servies depuis un lieu proche du visiteur.

Quel que soit le niveau choisi, soyez strict sur ce qui ne doit pas être mis en cache : paniers, commande, pages de compte, sessions connectées et tout contenu personnalisé. Ces requêtes doivent contourner le cache et atteindre l’origine à chaque fois. Si vos pages envoient des en-têtes Cache-Control cohérents, chaque niveau peut s’y conformer.

Pour savoir si une page provient réellement du cache, regardez les en-têtes de réponse :

curl -sI https://example.com/ | grep -i -E "cache|age"

Un cache qui existe mais qui produit rarement des hits ne sert pas à grand-chose. Un faible taux de hits vient généralement de cookies ou de paramètres d’URL qui rendent chaque requête unique, ou de durées de cache trop courtes.

Réduire la distance avec les visiteurs

Chaque aller-retour entre navigateur et serveur prend du temps, et une nouvelle connexion HTTPS en nécessite plusieurs avant que le premier octet puisse circuler. Si votre serveur est à Francfort et un visiteur à Sydney, la physique seule ajoute un délai sensible à chacun de ces allers-retours, aussi rapide que soit le serveur.

Il existe deux façons de réduire cette distance :

• Héberger près de votre audience. Si presque tous vos visiteurs sont dans un seul pays, un serveur dans ce pays ou à proximité est le gain le plus simple.
• Servir depuis un réseau edge. Un CDN termine les connexions dans un lieu proche du visiteur et, quand la page y est en cache, répond sans contacter votre origine. Le guide Qu’est-ce qu’un CDN explique ce que cela peut corriger et ce que cela ne peut pas corriger.

Un réseau edge aide aussi un peu les requêtes non mises en cache, car la négociation TLS a lieu à proximité et l’edge peut réutiliser une connexion déjà ouverte vers l’origine. Le gros du gain vient toutefois des cache hits.

Supprimer les redirections et le coût des connexions

Les petits détails s’additionnent, surtout sur les réseaux mobiles :

• Évitez les chaînes de redirections. Passer de http://example.com à https://example.com, puis à https://www.example.com et enfin à https://www.example.com/en/, c’est trois allers-retours supplémentaires avant que quoi que ce soit d’utile ne se produise. Créez vos liens directement vers l’URL finale et limitez-vous à une redirection au maximum.
• Utilisez HTTP/2 ou HTTP/3 et TLS 1.3. Ils réduisent le nombre d’allers-retours pour établir la connexion et permettent au navigateur de récupérer de nombreuses ressources sur une seule connexion.
• Choisissez un fournisseur DNS rapide. Le DNS fait partie du TTFB pour les nouveaux visiteurs. Les fournisseurs en anycast ou en GeoDNS répondent depuis des lieux proches.
• Activez la compression. Brotli ou gzip pour le HTML ne change pas grand-chose au premier octet, mais raccourcit le reste du téléchargement qui suit.

Comment fast.site vous aide

fast.site se place devant votre hébergement existant et agit sur les parties réseau et cache du TTFB. Vous gardez votre hébergeur ; vous faites pointer les serveurs de noms de votre domaine vers fast.site, et après vérification votre trafic passe par son réseau edge.

Fast Edge Cache™ stocke les pages pouvant être mises en cache sur l’edge. En cas de cache HIT, la réponse vient directement de l’edge sans contacter votre origine ; en cas de MISS, la page est récupérée une fois puis stockée. L’expiration suit les en-têtes Cache-Control de votre origine ou vos propres règles, et un cache warmer garde les pages importantes à jour dans le cache. Les paniers, la commande et les sessions connectées contournent le cache, ce que l’en-tête fs-cache signale par BYPASS. Vous pouvez vérifier n’importe quelle URL comme décrit dans l’article vérifier le cache, et la documentation sur le cache explique les règles.

Le GeoDNS dirige les visiteurs vers l’edge disponible le plus proche, avec des régions en Amérique du Nord, en Europe, en Asie-Pacifique et en Amérique du Sud selon votre offre (voir les régions). Les certificats sont émis et renouvelés automatiquement.

fast.site n’accélère pas une requête lente en base de données : les corrections sur l’origine restent donc importantes pour les pages non mises en cache. Les statistiques du tableau de bord affichent le TTFB et le taux de cache hit, pour que vous puissiez mesurer l’effet sur votre propre site. Vous pouvez par exemple le faire pendant un essai gratuit de 7 jours.

Questions fréquentes

Le TTFB a-t-il un impact sur le SEO ?

Le TTFB ne fait pas partie des Core Web Vitals que Google utilise comme signal d’expérience de page. Il retarde en revanche le Largest Contentful Paint, qui en fait partie. Améliorer le TTFB sert surtout à obtenir un meilleur LCP et un site qui paraît plus rapide, pas un gain direct de classement.

Pourquoi mon TTFB est-il élevé uniquement lors de la première visite ?

La première requête inclut souvent une résolution DNS, une nouvelle négociation TLS et un cache froid sur le serveur ou l’edge. Les requêtes suivantes réutilisent les connexions et tombent sur un cache déjà rempli. Si le TTFB de la première visite compte pour vous (c’est le cas pour la plupart des landing pages), regardez la vitesse du DNS, les redirections et le préchauffage du cache.

Pourquoi mon TTFB est-il bon dans mes tests mais mauvais pour les vrais utilisateurs ?

Votre propre test tourne généralement sur une connexion rapide proche du serveur, avec un cache déjà rempli. Les données terrain, comme celles affichées sur corewebvitals.page ou dans la Search Console, proviennent de vrais utilisateurs de Chrome sur toutes sortes de réseaux et de lieux, mesurées au 75e percentile. L’écart pointe souvent vers la distance ou vers des pages rarement en cache.

Un CDN corrige-t-il un TTFB lent ?

Il corrige la part due à la distance et à la génération répétée des pages, à condition que vos pages puissent réellement être mises en cache. Il n’accélère pas les requêtes qui doivent atteindre l’origine, comme la commande ou les pages connectées. Pour celles-ci, l’optimisation du serveur et de l’application reste nécessaire.