Qu'est-ce qu'un bon Time to First Byte (TTFB) ?

Google recommande un TTFB inférieur à 800 ms. Un TTFB en dessous de 200 ms est considéré comme excellent, entre 200 et 500 ms comme correct, et au-delà de 600 ms comme problématique. Pour les sites e-commerce ou à fort trafic, viser moins de 300 ms est idéal pour garantir une bonne expérience utilisateur et un impact SEO positif.

Le TTFB a-t-il un impact direct sur le référencement Google ?

Oui. Le TTFB fait partie des métriques qui influencent les Core Web Vitals, notamment le Largest Contentful Paint (LCP). Un serveur lent retarde le LCP, ce qui peut dégrader votre classement dans les résultats de recherche. Google a confirmé que la vitesse de réponse du serveur est un facteur pris en compte dans son algorithme de classement.

Optimiser le Time to First Byte : diagnostic complet et solutions

Qu’est-ce que le Time to First Byte et pourquoi est-il crucial ?

Le Time to First Byte (TTFB) correspond au temps écoulé entre le moment où le navigateur de l’utilisateur envoie une requête HTTP et celui où il reçoit le tout premier octet de la réponse du serveur. En d’autres termes, c’est le délai incompressible avant que quoi que ce soit ne commence à s’afficher à l’écran.

Cette métrique englobe trois phases distinctes :

La résolution DNS : traduire le nom de domaine en adresse IP
La connexion TCP/TLS : établir la liaison sécurisée avec le serveur
Le temps de traitement serveur : exécution du code backend, requêtes base de données, génération de la réponse HTML

Un TTFB élevé agit comme un goulot d’étranglement. Même si votre frontend est parfaitement optimisé — images compressées, CSS minifié, lazy loading activé — tout est bloqué en attendant cette première réponse du serveur.

L’impact concret sur le SEO et l’expérience utilisateur

Google a intégré le TTFB comme composante clé de ses Core Web Vitals depuis 2021. Un TTFB lent retarde mécaniquement le Largest Contentful Paint (LCP), l’une des trois métriques principales évaluées pour le classement.

Quelques chiffres pour mesurer l’enjeu :

53 % des visiteurs mobiles quittent un site qui met plus de 3 secondes à charger (source : Google)
Chaque 100 ms de latence supplémentaire coûte à Amazon environ 1 % de chiffre d’affaires
Un TTFB passant de 600 ms à 200 ms peut améliorer le LCP de 400 ms ou plus, suffisamment pour changer de catégorie dans le rapport Core Web Vitals

Comment mesurer votre TTFB : les outils indispensables

Avant d’optimiser, il faut diagnostiquer. Voici les outils les plus fiables pour mesurer votre Time to First Byte.

Outils gratuits en ligne

Outil	Type de mesure	Avantage principal
Google PageSpeed Insights	Données terrain (CrUX) + labo	Données réelles des utilisateurs Chrome
WebPageTest.org	Test labo multi-localisations	Cascade réseau détaillée, choix du serveur de test
GTmetrix	Test labo	Interface claire, historique des tests
Chrome DevTools (onglet Network)	Test local	Analyse requête par requête en temps réel
curl en ligne de commande	Test brut serveur	Idéal pour isoler le temps serveur pur

Mesurer le TTFB avec curl

Pour obtenir une mesure brute du TTFB sans l’overhead du navigateur, utilisez cette commande :

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://www.votre-site.com

Résultat typique pour un site optimisé :

DNS: 0.024s
Connect: 0.048s
TLS: 0.096s
TTFB: 0.187s
Total: 0.214s

Résultat typique pour un site non optimisé :

DNS: 0.085s
Connect: 0.192s
TLS: 0.388s
TTFB: 1.247s
Total: 2.891s

La différence saute aux yeux. Dans le second cas, le serveur met plus d’une seconde rien que pour commencer à répondre.

Grille d’interprétation du TTFB

TTFB	Évaluation	Action recommandée
< 200 ms	Excellent	Maintenir la configuration
200 – 500 ms	Correct	Optimisations mineures possibles
500 – 800 ms	Médiocre	Optimisation nécessaire
> 800 ms	Critique	Intervention urgente requise

Les 7 causes principales d’un TTFB élevé

Après avoir audité des centaines de sites, l’équipe de Lueur Externe constate que les mêmes causes reviennent systématiquement. Voici les plus fréquentes, classées par impact.

1. Un hébergement sous-dimensionné ou mal configuré

C’est la cause numéro un. Un hébergement mutualisé à 3 €/mois partage ses ressources CPU et RAM entre des dizaines voire des centaines de sites. Aux heures de pointe, le temps de traitement serveur explose.

Symptômes typiques : TTFB fluctuant fortement selon l’heure de la journée, pics inexpliqués de latence.

2. L’absence de cache serveur

Sans cache, chaque visiteur déclenche l’exécution complète du code PHP, les requêtes SQL, la compilation des templates… Un site WordPress ou PrestaShop non caché peut exécuter 50 à 200 requêtes SQL par page.

3. Des requêtes SQL non optimisées

Une seule requête mal indexée peut bloquer le serveur pendant plusieurs secondes. Les jointures sur des tables volumineuses sans index, les requêtes SELECT * inutiles et les sous-requêtes non optimisées sont des coupables fréquents.

4. Une version PHP obsolète

Passer de PHP 7.4 à PHP 8.2 peut réduire le temps d’exécution backend de 20 à 40 % grâce aux améliorations du moteur JIT et à l’optimisation de la gestion mémoire.

5. Des plugins ou modules trop nombreux ou mal codés

Sur WordPress, chaque plugin actif ajoute du code exécuté à chaque requête. Sur PrestaShop, un module mal développé qui effectue des appels API externes synchrones peut ajouter plusieurs secondes au TTFB.

6. L’absence de CDN

Sans CDN (Content Delivery Network), un utilisateur à Tokyo qui consulte un site hébergé à Paris subit environ 250 ms de latence réseau rien que pour l’aller-retour. Un CDN avec des points de présence globaux réduit cette latence à moins de 30 ms.

7. Une mauvaise configuration DNS

Un DNS lent ou mal configuré peut ajouter 50 à 150 ms au TTFB. L’utilisation de serveurs DNS performants (Cloudflare DNS, AWS Route 53) et la mise en place correcte des enregistrements sont souvent négligées.

Solutions concrètes pour réduire votre TTFB

Passons à la pratique. Voici les leviers d’optimisation les plus efficaces, organisés par ordre de priorité.

Mettre en place un cache serveur efficace

Le cache est de loin le levier le plus impactant. Il permet de stocker en mémoire les pages générées et de les servir directement sans ré-exécuter le backend.

Pour WordPress, la combinaison recommandée :

Cache objet : Redis ou Memcached pour les requêtes SQL récurrentes
Cache de page : WP Super Cache, W3 Total Cache ou WP Rocket
Cache Opcode : OPcache pour stocker le bytecode PHP compilé

Pour PrestaShop, l’approche est similaire :

Activer le cache Smarty en mode “Tout en cache”
Configurer Memcached ou Redis comme cache objet
Activer la compilation du cache template

Exemple de configuration OPcache optimisée dans php.ini :

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.interned_strings_buffer=16
opcache.jit_buffer_size=100M
opcache.jit=1255

Résultat attendu : réduction du TTFB de 50 à 90 % sur les pages cachées.

Optimiser la couche base de données

Les requêtes SQL lentes sont un tueur silencieux de performance. Voici comment les traquer et les corriger.

Activer le slow query log MySQL :

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 0.5;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Toute requête dépassant 500 ms sera journalisée. Analysez ensuite avec EXPLAIN :

EXPLAIN SELECT p.*, c.name
FROM ps_product p
JOIN ps_category_lang c ON p.id_category_default = c.id_category
WHERE p.active = 1
AND c.id_lang = 1
ORDER BY p.date_add DESC
LIMIT 50;

Les colonnes type et Extra de la sortie EXPLAIN révèlent les problèmes : un type: ALL signifie un scan complet de table, un Using filesort indique un tri coûteux. L’ajout d’index ciblés peut transformer une requête de 2 secondes en 10 ms.

Bonnes pratiques base de données :

Ajouter des index sur les colonnes utilisées dans WHERE, JOIN et ORDER BY
Utiliser SELECT avec les colonnes nécessaires uniquement (éviter SELECT *)
Configurer correctement le innodb_buffer_pool_size (environ 70 % de la RAM disponible pour un serveur dédié)
Nettoyer régulièrement les tables de sessions et de logs

Passer à un hébergement performant

Le choix de l’infrastructure est fondamental. Voici une comparaison réaliste du TTFB selon le type d’hébergement :

Type d’hébergement	TTFB moyen constaté	Coût mensuel typique
Mutualisé bas de gamme	800 – 2000 ms	3 – 10 €
Mutualisé premium	400 – 800 ms	15 – 30 €
VPS (2 vCPU, 4 Go RAM)	150 – 400 ms	20 – 50 €
Serveur dédié optimisé	80 – 200 ms	80 – 200 €
Cloud AWS (EC2 + ElastiCache)	50 – 150 ms	100 – 500 €

Chez Lueur Externe, notre certification AWS Solutions Architect nous permet de concevoir des architectures cloud taillées sur mesure : instances EC2 dimensionnées au plus juste, ElastiCache pour le cache Redis managé, CloudFront comme CDN, et RDS optimisé pour la base de données. Le surcoût d’hébergement est largement compensé par les gains de conversion.

Déployer un CDN correctement configuré

Un CDN ne se limite pas à servir les fichiers statiques (images, CSS, JS). Les CDN modernes comme Cloudflare, AWS CloudFront ou Fastly peuvent également cacher les pages HTML complètes.

Configuration recommandée :

Cache des assets statiques : TTL de 30 jours minimum
Cache des pages HTML : TTL de 5 à 60 minutes selon la fréquence de mise à jour
Purge automatique : webhook de purge déclenché lors des mises à jour de contenu
Early Hints (103) : permet au navigateur de précharger des ressources avant même la réponse complète

Gain typique : 100 à 300 ms pour les visiteurs éloignés géographiquement du serveur d’origine.

Mettre à jour PHP et optimiser la configuration serveur

Le passage à PHP 8.2 ou 8.3 apporte des gains significatifs grâce au compilateur JIT (Just-In-Time). Mais la configuration du serveur web compte aussi énormément.

Nginx vs Apache : pour les sites à fort trafic, Nginx en reverse proxy devant PHP-FPM est généralement 20 à 30 % plus rapide qu’Apache avec mod_php, grâce à sa gestion événementielle des connexions.

Exemple de configuration Nginx optimisée pour le TTFB :

server {
    listen 443 ssl http2;
    server_name www.votre-site.com;

    # Cache FastCGI
    fastcgi_cache_path /tmp/nginx-cache levels=1:2
        keys_zone=MYAPP:100m inactive=60m;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_cache MYAPP;
        fastcgi_cache_valid 200 10m;
        fastcgi_cache_bypass $cookie_logged_in;
        add_header X-Cache-Status $upstream_cache_status;
    }

    # Gzip
    gzip on;
    gzip_comp_level 5;
    gzip_types text/plain text/css application/json
        application/javascript text/xml;
}

Cette configuration met en cache les réponses PHP directement au niveau de Nginx. Les visiteurs non connectés reçoivent une réponse en cache en quelques millisecondes, sans aucune exécution PHP.

Réduire les appels externes côté serveur

Chaque appel API externe effectué pendant le rendu serveur ajoute sa propre latence au TTFB. Un site qui interroge une API de stock, une API de prix, un service de géolocalisation et un tracker analytics côté serveur peut facilement accumuler 1 à 3 secondes de latence.

Solutions :

Mettre en cache les réponses API avec un TTL adapté (Redis, fichier JSON temporaire)
Rendre les appels asynchrones quand c’est possible
Différer côté client les appels non essentiels au rendu initial (analytics, chat, widgets sociaux)

Étude de cas : un site PrestaShop passé de 1,8 s à 180 ms de TTFB

Pour illustrer concrètement ces optimisations, voici les résultats d’un projet type réalisé sur un site e-commerce PrestaShop avec environ 15 000 produits.

Situation initiale :

Hébergement mutualisé OVH Pro
PHP 7.4, pas de cache objet
47 modules actifs
TTFB moyen : 1 847 ms
LCP : 4,2 secondes

Actions réalisées :

Migration vers une instance AWS EC2 (t3.medium) avec ElastiCache Redis
Passage à PHP 8.2 avec OPcache JIT activé
Désactivation de 19 modules non essentiels
Ajout d’index SQL sur 8 tables critiques
Mise en place de Nginx avec cache FastCGI
Déploiement de CloudFront comme CDN

Résultats après optimisation :

TTFB moyen : 182 ms (réduction de 90 %)
LCP : 1,4 seconde
Taux de rebond : -23 %
Taux de conversion : +18 % sur les 3 mois suivants

Monitoring continu : ne pas laisser le TTFB se dégrader

L’optimisation du TTFB n’est pas un travail ponctuel. Chaque mise à jour de plugin, chaque ajout de fonctionnalité, chaque pic de trafic peut faire remonter le temps de réponse.

Mettez en place un monitoring continu :

Synthetic monitoring : tests automatisés depuis plusieurs localisations (Pingdom, UptimeRobot, ou un simple cron avec curl)
Real User Monitoring (RUM) : mesurer le TTFB réel de vos visiteurs via l’API Navigation Timing
Alertes : notification dès que le TTFB dépasse un seuil défini (par exemple 500 ms)

Extrait JavaScript pour mesurer le TTFB côté client :

// Mesure du TTFB via l'API Performance
const [navigation] = performance.getEntriesByType('navigation');
if (navigation) {
  const ttfb = navigation.responseStart - navigation.requestStart;
  console.log(`TTFB: ${Math.round(ttfb)} ms`);

  // Envoi vers votre outil d'analytics
  if (ttfb > 800) {
    navigator.sendBeacon('/api/perf-alert', JSON.stringify({
      metric: 'ttfb',
      value: Math.round(ttfb),
      url: window.location.href
    }));
  }
}

Conclusion : chaque milliseconde compte

Le Time to First Byte est la fondation de toute la performance de votre site. Un TTFB élevé plombe le LCP, dégrade l’expérience utilisateur, augmente le taux de rebond et nuit à votre référencement Google. À l’inverse, un TTFB optimisé crée un cercle vertueux : pages rapides, visiteurs satisfaits, meilleur classement, plus de conversions.

Les leviers sont clairement identifiés : cache serveur, optimisation SQL, hébergement adapté, CDN, version PHP récente et configuration serveur rigoureuse. La bonne nouvelle, c’est que la plupart de ces optimisations sont cumulatives — chacune retire quelques dizaines voire centaines de millisecondes.

Chez Lueur Externe, nous réalisons des audits de performance complets depuis plus de 20 ans. Notre expertise certifiée Prestashop et AWS Solutions Architect nous permet d’intervenir à tous les niveaux : du diagnostic initial à la mise en production d’architectures haute performance. Que votre site tourne sur WordPress, PrestaShop ou une solution sur mesure, nous identifions les goulots d’étranglement et appliquons les corrections qui font la différence.

Votre TTFB dépasse les 500 ms ? Ne laissez pas la lenteur de votre serveur freiner votre croissance. Contactez l’équipe Lueur Externe pour un audit de performance personnalisé.