TTFB : qu'est-ce que le Time to First Byte et comment l'optimiser ?

TTFB : définition et seuils Google

Le TTFB mesure le temps écoulé entre le moment où le navigateur envoie une requête HTTP et celui où il reçoit le premier octet de la réponse du serveur. Ce délai comprend trois composantes : la latence réseau (aller-retour DNS + TCP + TLS), le temps de traitement serveur (exécution applicative, requêtes BDD, rendu de la réponse), et la mise en file d'attente éventuelle côté serveur.

Google définit trois niveaux de performance pour le TTFB :

Ces seuils s'appliquent aux données terrain au 75e percentile (P75) : 75 % des visites réelles doivent passer sous 800 ms pour être considérées bonnes.

La place du TTFB dans le waterfall réseau

Le TTFB est la première phase du chargement d'une page. Dans le waterfall de navigation, il précède tout le reste : le parser HTML ne peut pas commencer avant que le premier octet soit arrivé, les ressources critiques (CSS, polices, image LCP) ne peuvent pas être découvertes avant le parsing, et le LCP ne peut pas se déclencher avant que l'élément visuel soit rendu. Un TTFB de 800 ms consomme 800 ms du budget LCP avant même que le navigateur ait commencé à travailler. Si le LCP cible est 2,5 s, un TTFB à 1,2 s ne laisse que 1,3 s pour tout le reste.

Comment mesurer le TTFB

Chrome DevTools (diagnostic ponctuel)

Ouvrez DevTools (F12), onglet Network, cliquez sur la première requête HTML, puis consultez le panneau Timing. La ligne "Waiting for server response" isole le temps de traitement serveur pur. C'est le premier réflexe pour trancher entre un problème réseau (DNS/TCP/TLS élevés) et un problème applicatif : un "Waiting" à 900 ms avec DNS/TCP/TLS normaux pointe directement le back-end, pas l'infrastructure.

WebPageTest (benchmark contrôlé)

WebPageTest mesure le TTFB depuis des agents localisés dans des villes précises, sur des conditions réseau simulées (Moto G4, 4G). L'intérêt : reproduire les mêmes conditions d'un run à l'autre pour benchmarker fiablement. Pour un site e-commerce français, lancer depuis "Paris, France" en profil mobile donne la lecture qui compte. Et lancer en parallèle depuis Singapour ou São Paulo révèle en une minute si votre CDN couvre vraiment le monde : 1,2 s à Paris et 3,8 s à Singapour, c'est un CDN absent ou mal configuré.

Google Search Console (données terrain P75)

La Search Console rapporte le TTFB via CrUX, agrégé sur 28 jours glissants au P75. C'est la seule vue qui compte pour les décisions SEO : ce que vivent réellement vos utilisateurs, tous réseaux et localisations confondus. Si WebPageTest annonce bon et que la Search Console annonce mauvais, la cause est presque toujours l'une des deux : un CDN mal couvrant sur les régions où vit votre audience, ou un serveur qui se dégrade sous la charge du trafic réel. Faites confiance au terrain.

Les données de la search console sont également accessibles publiquement sur CrUXvis, un outil gratuit de Google. CrUXvis donne une vue plus détaillée que la search console et permet de vérifier les données de sites concurrents.

Les 5 causes principales d'un TTFB élevé

1. Absence de cache de page

C'est la cause la plus fréquente et la plus impactante. Sans cache, chaque requête déclenche l'intégralité de la chaîne applicative : routing, authentification, requêtes BDD, rendu du template, sérialisation de la réponse. Sur un CMS ou un e-commerce standard, cela représente 300 ms à 2 s selon la complexité. Avec un cache de page complet, la même réponse est servie depuis la mémoire en 5-50 ms.

2. Dilution du cache par des query parameters

Le cache est en place, mais le taux de cache hit est effondré. En cause, chaque combinaison de paramètres d'URL (?color=red&size=L&sort=price_asc) qui génère une clé de cache distincte. Sur un catalogue e-commerce avec 20 filtres de 5 valeurs chacun, on obtient plusieurs milliers de combinaisons, dont l'écrasante majorité ne sera jamais réchauffée. La majorité des requêtes finit en cache miss et le TTFB reste élevé malgré un cache pourtant "en place".

3. Requêtes BDD lentes ou non indexées

Une page produit qui charge 5 blocs de contenu dynamiques (recommandations, stock, avis, prix personnalisés, navigation facettée) peut déclencher 20 à 50 requêtes SQL. Sans index adapté sur les colonnes filtrées, chaque requête fait un full table scan. Sur un catalogue de 500 000 produits, une requête non indexée sur product_category_id peut prendre 800 ms à elle seule.

4. Absence de CDN ou CDN non configuré pour le caching

Même avec un cache serveur parfait, la latence réseau est incompressible. Entre un serveur en France et un utilisateur à Singapour, l'aller-retour réseau seul ajoute 150-200 ms. Avec 3-4 aller-retours pour DNS + TCP + TLS + requête, le TTFB mécanique atteint 600-800 ms avant même que le serveur traite quoi que ce soit. Un CDN avec edge caching élimine ce problème en servant la réponse depuis un noeud local.

5. Calculs lourds bloquants en synchrone

Certains traitements s'exécutent en synchrone dans le chemin critique : calcul de prix personnalisés, appels à des APIs tierces bloquants (traduction, personnalisation, recommandations en temps réel). Un appel API tiers avec un timeout de 2 s dans le chemin synchrone fixe le TTFB minimum à 2 s en cas de défaillance. La solution est la mise en cache de ces résultats ou leur déplacement en asynchrone.

Optimiser le TTFB côté serveur

Cache de page complet

Le cache de page complet (full-page cache) sérialise la réponse HTML finale et la stocke en mémoire (Redis, Memcached) ou sur disque. Les requêtes suivantes sur la même URL sont servies depuis le cache, sans toucher la BDD ni l'applicatif. Gain typique : de 800 ms-2 s sans cache à 20-80 ms avec cache Redis. Sur Laravel, Nginx FastCGI Cache ou Varnish, la mise en place est immédiate pour les pages publiques sans personnalisation.

// Laravel : cache de page simple avec Redis
Route::get('/produit/{slug}', function ($slug) {
    return Cache::remember("page:produit:{$slug}", 3600, function () use ($slug) {
        $produit = Product::with(['images', 'variants', 'category'])
            ->where('slug', $slug)->firstOrFail();
        return view('produit', compact('produit'))->render();
    });
});

Normalisation des clés de cache (anti-dilution)

L'objectif est de réduire le nombre de clés de cache distinctes en excluant les paramètres qui ne changent pas le contenu servi. Un filtre de couleur sélectionné en JavaScript ne modifie pas le HTML brut de la page ; seule la sélection UI côté client change.

// Construire une clé de cache normalisée : exclure les paramètres non structurants
function buildCacheKey(Request $request): string {
    $structuralParams = ['page', 'category', 'brand']; // influencent le contenu
    // Paramètres exclus : color, size, sort, utm_source, ref...
    $params = $request->only($structuralParams);
    ksort($params); // ordre alphabétique pour éviter les doublons
    return 'page:' . $request->path() . ':' . md5(serialize($params));
}

Optimisation BDD

Deux actions à fort impact : l'indexation des colonnes de filtrage et la réduction du nombre de requêtes par page.

-- Index composite pour les listes produits filtrées par catégorie et prix
CREATE INDEX idx_products_category_price
    ON products (category_id, price, status)
    WHERE status = 'active'; -- index partiel : ignore les produits inactifs

Utiliser EXPLAIN ANALYZE (PostgreSQL) ou EXPLAIN (MySQL/MariaDB) pour identifier les full table scans avant d'indexer. Un full scan sur une table de 500 000 lignes coûte systématiquement plus de 200 ms.

PHP et SFCC : réduire le temps de traitement applicatif

Sur PHP natif, activer OPcache élimine la recompilation des scripts à chaque requête (gain de 60-80 % sur le temps d'exécution PHP). Sur SFCC, la mise en cache des pipelines via Business Manager permet de contrôler quelles routes utilisent le cache applicatif et avec quelle TTL. Les cartridges personnalisés avec des appels API synchrones dans le pipeline de rendu sont la cause n°1 des TTFB élevés côté SFCC.

◆Retour terrain·8 ans · 35+ clients

Le cache SFCC qui ne cachait rien.

Sur une maison de luxe, catalogue de plusieurs milliers de SKUs, leur Server Response oscillait entre 0,7 et 0,9 s en field data. Le cache applicatif SFCC était pourtant activé, configuré, monitoré : sur le papier, tout allait bien. J'ouvre les logs cache : taux de hit proche de zéro. La cause tenait dans trois paramètres d'URL (color, size, sort) qui généraient chacun une clé distincte. Sur un catalogue avec 30 filtres possibles, cela multiplie le nombre de pages "uniques" à mettre en cache par 30, dont 95 % ne sont jamais visitées : autant d'entrées qui ne se réchauffent jamais. J'ai exclu ces paramètres du calcul de clé via les directives SFCC, ajusté les TTL par type de page, et lancé un warmup ciblé sur les combinaisons les plus consultées. Sur deux mois de mesure, la dilution est tombée de 80 %, et le Server Response moyen est passé de 0,74 s à 0,63 s en field data. Une perte de 15 % au passage, sans toucher à l'infra. Le réflexe à retenir : un cache "en place" ne dit rien tant qu'on n'a pas regardé son taux de hit réel, un cache mal calibré coûte autant qu'un cache absent.

Réduire le TTFB avec un CDN

Edge caching

Un CDN avec edge caching stocke la réponse HTML au plus près des utilisateurs. Quand un utilisateur à Tokyo charge une page, la réponse est servie depuis un noeud Tokyo, pas depuis un serveur à Paris : la latence réseau tombe de 150-200 ms à 5-20 ms. La condition pour que ça fonctionne : la réponse doit être cacheable (Cache-Control: public, max-age=3600). Une réponse avec Set-Cookie ou Cache-Control: private ne sera pas mise en cache edge et atteindra systématiquement l'origine.

# Nginx : headers pour activer l'edge caching CDN sur les pages produit
location ~* ^/produit/ {
    add_header Cache-Control "public, max-age=3600, stale-while-revalidate=300";
    add_header Vary "Accept-Language"; # varier par langue uniquement
    proxy_hide_header Set-Cookie;      # éviter que les cookies bloquent le cache CDN
    proxy_pass http://backend;
}

Cloudflare et Akamai : configuration avancée

La normalisation des query parameters est aussi configurable directement au niveau du CDN. Les Cache Rules de Cloudflare permettent de définir précisément quels paramètres entrent dans la clé de cache edge : ignorer les paramètres de tri et de filtrage UI réduit drastiquement le nombre d'entrées distinctes, exactement comme la normalisation côté applicatif.

Sur les infrastructures à fort trafic, la configuration de Akamai offre un contrôle fin : SureRoute optimise le chemin réseau vers le serveur d'origine, Property Manager gère la clé de cache edge, et le Cache-Control Modification Behavior surcharge les headers de l'origine sans toucher au code applicatif. Un cache hit ratio inférieur à 85 % sur les pages produit est le premier signal d'une dilution ou d'un TTL trop court.

Early Hints HTTP 103

HTTP 103 Early Hints permet au serveur d'envoyer des directives Link: rel=preload avant que la réponse 200 complète soit prête. Le navigateur précharge les ressources critiques (CSS, polices, image LCP) pendant que le serveur génère encore la page. Sur un TTFB de 600 ms, Early Hints peut précharger le CSS critique et la police de marque en parallèle, réduisant le LCP de 200-400 ms sans toucher au TTFB lui-même. Nginx supporte HTTP 103 depuis la version 1.25.1 ; Cloudflare et Akamai le transmettent nativement depuis leurs edges sans configuration serveur.

Un cache hit ratio inférieur à 85 % mérite un audit web performance dédié pour distinguer dilution, TTL trop court et headers mal configurés. Si le TTFB n'est qu'un symptôme d'une performance serveur globalement fragile, l'optimisation des performances serveur couvre la priorisation des axes d'amélioration sur l'ensemble de la stack.

Sur un site à fort trafic, la stabilisation durable du TTFB dépasse rarement une intervention ponctuelle : elle demande un accompagnement continu de type agence web performance qui couvre back-end, CDN et monitoring en parallèle.

Sources

• Web Vitals : Time to First Byte (TTFB) · Google web.dev
• Optimize TTFB · Google web.dev
• HTTP 103 Early Hints · MDN Web Docs
• CrUX Dashboard · Chrome Developers