Comment réduire le TTFB et accélérer la réponse de votre site web

Pour réduire le TTFB, commencez par séparer le temps DNS et de connexion du temps CDN et origine. Servez ensuite les réponses sûres depuis un edge proche, supprimez les redirections et traitements backend inutiles, optimisez les requêtes et dépendances lentes, et validez le résultat avec des mesures depuis de vraies régions. Le TTFB n'est pas un Core Web Vital, mais c'est un signal de diagnostic précieux car un premier octet tardif retarde l'analyse du HTML et peut repousser le LCP.

Ce que comprend le TTFB

Le temps jusqu'au premier octet est le délai entre le début d'une requête et la réception du premier octet de réponse. La décomposition exacte dépend du navigateur et de l'outil de mesure, mais le chemin de requête comprend couramment :

• La résolution DNS du nom d'hôte.
• La connexion TCP et la négociation TLS, sauf si une connexion existante est réutilisée.
• Le transit réseau du visiteur vers l'edge ou l'origine.
• La recherche CDN, le traitement d'un succès ou manque de cache et toute logique edge.
• La mise en file et le travail applicatif à l'origine.
• Les appels de base de données et requêtes vers d'autres services.
• Le trajet des premiers octets de réponse vers le client.

Le nombre affiché dans un waterfall est donc un symptôme, pas un diagnostic. Un site mondial peut avoir une bonne réponse d'origine mais un TTFB médiocre pour les utilisateurs éloignés du réseau de diffusion. Un site local peut avoir un DNS rapide et rester lent parce que chaque requête attend une base de données.

Étape 1 : mesurer la décomposition

Utilisez les DevTools du navigateur, curl -w, les en-têtes de timing serveur, les journaux CDN et vos données de surveillance utilisateurs réels. Une commande générique pour une première comparaison est :

curl -sS -o /dev/null -w \
  'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}\n' \
  https://www.example.com/page

Exécutez-la plusieurs fois et gardez l'état de cache visible. Inspectez Age, ETag, les en-têtes de statut de cache, le statut de réponse, les redirections et Server-Timing. Un succès CDN et un manque à l'origine sont des tests différents. Si la réponse varie selon le cookie, l'autorisation, la langue ou l'appareil, consignez également ces en-têtes de requête.

Les données terrain sont essentielles pour connaître la distribution des expériences réelles. Les données de laboratoire conviennent mieux aux comparaisons contrôlées et tests de régression. Suivez le TTFB par route, région, appareil et statut de cache plutôt que de publier une moyenne unique pour tout le site.

Étape 2 : améliorer le DNS et l'établissement de connexion

Utilisez un DNS faisant autorité qui répond de manière fiable depuis un réseau approprié et gardez la chaîne DNS courte. Un fournisseur DNS lent ou défaillant retarde chaque visite avant que le navigateur puisse se connecter. Le guide DNS managé d'Optimi explique le DNS Anycast et la redondance comme des enjeux de diffusion, pas seulement d'administration de domaine.

Réduisez les redirections. Une redirection HTTP vers HTTPS est souvent nécessaire à l'edge, mais une chaîne de redirections d'hôte, locale, suivi et applicatives ajoute des allers-retours. Normalisez une fois l'URL canonique et redirigez directement. Utilisez HTTP/2 ou HTTP/3 lorsque vos clients et votre pile de diffusion les prennent en charge, gardez les connexions réutilisables et évitez de forcer des négociations inter-origines inutiles pour les ressources critiques.

N'ajoutez pas de hints preconnect pour chaque origine tierce. Un preconnect peut faire gagner du temps pour une connexion réellement critique, mais trop d'indices concurrencent les sockets et le travail. Mesurez d'abord le chemin critique.

Étape 3 : retirer de l'origine le travail cachable

L'amélioration TTFB la plus directe est un succès de cache qui répond près de l'utilisateur. Mettez longtemps en cache les CSS, JavaScript, polices, images et autres ressources immuables versionnés. Envisagez de mettre en cache les réponses HTML ou API publiques uniquement lorsque la réponse est identique pour toutes les requêtes partageant la clé de cache et que sa politique de fraîcheur est acceptable.

Pour une réponse publique dont la durée de cache partagé diffère de celle du navigateur, utilisez des directives explicites :

Cache-Control: public, max-age=60, s-maxage=600
ETag: "catalog-2026-07-14-42"

Le navigateur peut réutiliser la réponse pendant 60 secondes tandis qu'un cache partagé peut la réutiliser pendant 10 minutes. C'est un choix de politique, pas une recommandation universelle. Confirmez que Cloudflare, Fastly ou un CDN équivalent respecte la politique d'origine, ou documentez la règle edge qui la remplace. Consultez Le cache CDN expliqué pour les décisions de mise en cache.

Évitez de mettre en cache les réponses contenant les détails de compte d'un utilisateur, l'état du panier, le paiement ou des données sensibles. Set-Cookie, Authorization et une politique Vary large peuvent provoquer des contournements ou une fragmentation du cache. Pour le contenu personnalisé, mettez en cache un shell public et récupérez séparément les données privées lorsque cette architecture est sûre et utile.

Étape 4 : réduire le calcul à l'origine

Analysez les transactions serveur lentes au lieu d'augmenter les délais d'attente. Les causes courantes comprennent :

• Des requêtes de base de données sans les bons index ou avec des jointures inutiles.
• Des requêtes N+1 générées par un template ou un résolveur API.
• Des appels synchrones à des services de paiement, recherche, recommandation ou inventaire.
• Des démarrages à froid, l'épuisement du pool de threads, l'attente du pool de connexions ou la contention de verrous.
• Le rendu d'une page entière alors qu'un petit fragment seulement a changé.
• Des manques de cache qui font converger le même travail coûteux.

Définissez des budgets pour les dépendances et dégradez-vous avec élégance lorsqu'un service non critique est lent. Réutilisez les connexions à la base de données et en amont. Pré-calculez le contenu qui ne nécessite pas de calcul au moment de la requête. Utilisez des tâches d'arrière-plan pour le travail qui n'a pas sa place avant le premier octet. Ajoutez un identifiant de requête afin de pouvoir joindre un journal edge, une trace applicative, une trace de base de données et un timing navigateur.

Étape 5 : protéger l'origine de la charge évitable

Le shielding d'origine, le regroupement de requêtes et des clés de cache soigneusement conçues peuvent éviter que de nombreux emplacements edge demandent le même objet simultanément. Préchauffez les objets critiques après un déploiement uniquement lorsque vous comprenez les implications de charge et de fraîcheur. Limitez le débit du trafic abusif et séparez les contrôles de santé des routes applicatives coûteuses.

Le cache ne remplace pas la planification de capacité. Un site peut sembler rapide lors de tests à cache chaud et échouer pendant une purge, une nouvelle version ou un pic de trafic. Testez le comportement en cas de manque et observez la saturation de l'origine pendant les tests.

Erreurs TTFB courantes

N'interprétez pas le TTFB comme du pur temps de traitement serveur. Ne rapprochez pas l'origine d'un seul emplacement de test en supposant que les utilisateurs mondiaux ont progressé. Ne mettez pas tout le HTML en cache pour améliorer un score synthétique. N'ajoutez pas un second CDN sans plan de routage et de cohérence du cache. N'utilisez pas un TTL long sans versionnage ni processus de purge testé. N'optimisez pas le DNS lorsqu'une application attend des secondes après une API distante.

Checklist de validation

Après un changement, comparez la même URL avec une requête froide et une requête chaude depuis les mêmes régions. Vérifiez DNS, connexion, TLS, TTFB, temps total, statut, redirections, Age, statut de cache, ETag et Server-Timing. Confirmez que les requêtes anonymes, authentifiées, localisées et avec cookie reçoivent la bonne représentation. Surveillez le CPU de l'origine, la mise en file, la latence de base de données, les taux d'erreur et le taux de succès du cache pendant le déploiement.

Pour les métriques navigateur influencées par le TTFB, lisez Les Core Web Vitals expliqués. Pour une séquence plus large de travail de performance, utilisez la checklist 2026 pour accélérer un site lent et le guide SEO technique et GEO.

Il n'y a que deux choses difficiles en informatique : l'invalidation du cache et le choix des noms.