Temps de réponse serveur

Ce que vérifie ce contrôle

Mesure le temps que met le serveur à renvoyer le premier octet du document HTML — le TTFB. Le chronomètre démarre lorsque le crawler de MetricSpot envoie la requête et s’arrête à l’arrivée du premier octet de réponse. DNS, TCP, TLS et traitement serveur sont tous inclus.

Le contrôle est validé en dessous de 800 ms (seuil “bon” de web.dev) et alerte au-dessus de 1,8 s.

Pourquoi c’est important

Le TTFB est un plafond pour toutes les autres Core Web Vitals. Le Largest Contentful Paint (LCP) ne peut pas battre TTFB + temps de rendu — si votre serveur met 2 secondes à répondre, votre LCP est mathématiquement d’au moins 2 secondes, peu importe la vitesse de votre CSS ou l’agressivité de votre optimisation d’images. Le seuil “bon LCP” de Google est de 2,5 s ; un TTFB de 2 s vous laisse 500 ms pour tout le reste.

Un TTFB lent pointe généralement vers l’une de quatre causes : une fonction serverless à froid, une requête de base de données dans le chemin de la requête, l’absence de cache à la périphérie, ou un CMS qui fait un travail qu’il ne devrait pas (WordPress sans object cache est le classique).

Comment corriger

Trouvez d’abord le goulot d’étranglement. Ajoutez des en-têtes Server-Timing pour visualiser où passe le temps :

Server-Timing: db;dur=420, render;dur=180, total;dur=620

Puis attaquez l’étape la plus longue.

Mettez le HTML en cache à la périphérie. Une réponse statique ou page-cachée devrait être servie en 20-100 ms depuis le POP le plus proche, et non 800 ms depuis votre origine.

# nginx — micro-cache des pages dynamiques pendant 60s
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=html:50m max_size=1g inactive=10m;

location / {
  proxy_cache html;
  proxy_cache_valid 200 60s;
  proxy_cache_use_stale updating error timeout;
  proxy_cache_lock on;
  proxy_pass http://app;
}

Cloudflare : activez “Cache Everything” via une Cache Rule pour le HTML, puis définissez Cache-Control: s-maxage=60, stale-while-revalidate=600 depuis votre origine. Le stale-while-revalidate est la magie — Cloudflare sert instantanément la copie périmée et la rafraîchit en arrière-plan.

Caddy :

example.com {
  reverse_proxy localhost:3000
  header Cache-Control "public, max-age=0, s-maxage=60, stale-while-revalidate=600"
}

Next.js (App Router) : préférez la génération statique. Si une page est dynamique, configurez le segment de route :

export const revalidate = 60; // ISR
export const dynamic = "force-static"; // quand c'est possible

Pour les server components qui interrogent une base de données, encapsulez le fetch dans unstable_cache ou utilisez fetch(url, { next: { revalidate: 60 } }).

Bun / Node : les gains habituels sont (a) un pool de connexions à votre base (pg.Pool, pas un client neuf par requête), (b) éviter les requêtes N+1 — un JOIN bat 50 allers-retours, (c) précalculer ce qui peut l’être au build, (d) gzip/brotli sur la réponse.

WordPress : installez un object cache persistant (Redis via le plugin Redis Object Cache) et un cache de page (WP Super Cache, W3 Total Cache ou LiteSpeed Cache). Une installation WP de base sans cache prend couramment 1-3 s par requête ; les deux caches activés font tomber le chiffre sous 200 ms.

Base de données : ajoutez l’index manquant. Lancez EXPLAIN ANALYZE sur la requête la plus lente de votre chemin ; si elle indique Seq Scan, il vous faut un index. Un seul index manquant peut être l’intégralité du problème de TTFB.

Latence géographique : si votre origine est à Francfort et vos visiteurs à Singapour, aucune optimisation serveur ne corrigera le round-trip de 180 ms. Mettez un CDN devant le HTML (pas seulement les images).

Une fois le TTFB sain, travaillez sur le Largest Contentful Paint et l’Interaction to Next Paint — ils sont en aval du TTFB et révèlent les problèmes côté client.

Questions fréquentes

Le TTFB est-il une Core Web Vital ?

Non. Le TTFB est une métrique amont — Google ne l’utilise pas directement comme signal de classement. Mais c’est le plancher du LCP, qui est un signal de classement. Un mauvais TTFB garantit un mauvais LCP.

Pourquoi MetricSpot mesure-t-il un TTFB différent de PageSpeed Insights ?

Points de mesure différents. MetricSpot mesure depuis son crawler dans un unique data center. PSI utilise des données terrain (Chrome User Experience Report) lorsqu’elles sont disponibles, ce qui correspond à de vrais utilisateurs partout dans le monde sur de vrais réseaux. Les données terrain sont la vérité ; les données de laboratoire sont le diagnostic.

Mon TTFB est bon sur la page d’accueil mais mauvais sur les pages produit — pourquoi ?

La page d’accueil est probablement mise en cache et les pages produit ne le sont pas. Soit étendez le cache de page aux URL produit (avec un TTL court et une invalidation au changement de stock), soit précalculez les pages produit au build via ISR / revalidation à la demande.