TTFB : le temps de réponse serveur qui plombe votre landing page avant même le premier pixel

Avant qu’une landing page n’affiche son titre, son image hero ou son bouton d’action, il se passe quelque chose d’invisible : le navigateur envoie une requête, et attend. Ce temps d’attente, entre le moment où la requête part et celui où le premier octet de réponse arrive, s’appelle le TTFB (Time To First Byte, temps de réponse serveur). Aucun pixel ne s’est encore affiché — et pourtant, ce délai conditionne tout ce qui suit. Un TTFB de 800 ms, c’est 800 ms de retard automatique sur le LCP, quelle que soit la qualité de l’image hero ou du code front. C’est l’indicateur de vitesse le plus en amont, le moins visible dans les outils grand public, et souvent le plus négligé.

Ce que le TTFB mesure exactement

Le TTFB couvre trois étapes successives : la résolution DNS (traduire le nom de domaine en adresse IP), l’établissement de la connexion (TCP puis chiffrement TLS pour le HTTPS), et enfin le temps de traitement côté serveur avant l’envoi du premier octet de réponse. C’est cette dernière étape qui varie le plus d’un site à l’autre : un serveur qui doit interroger une base de données, assembler un template et exécuter du code métier à chaque visite met naturellement plus de temps qu’un serveur qui se contente de servir un fichier HTML déjà généré. Sur une landing page — une page dont le contenu change rarement, parfois jamais entre deux mises à jour — cette différence est presque toujours évitable.

Pourquoi ce n’est pas un Core Web Vital, mais que ça les détermine tous

Le TTFB ne fait pas partie des trois Core Web Vitals de Google (LCP, CLS, INP) : il n’a pas de seuil « bon / à améliorer / mauvais » officiel visible dans le rapport principal de Search Console. Mais il conditionne mécaniquement le premier d’entre eux. Le LCP se mesure depuis l’arrivée sur la page jusqu’à l’affichage du plus grand élément visible — et cette mesure commence après le TTFB, pas avant. Google recommande d’ailleurs, dans son propre guide sur le sujet, de ne pas dépasser 800 ms de TTFB pour garder une marge suffisante sur un LCP à moins de 2,5 secondes. Un site qui répond en 200 ms dispose de 2,3 secondes pour tout le reste (téléchargement du HTML, chargement de l’image hero, rendu) ; un site qui répond en 1,5 seconde a déjà dépassé le seuil « bon » avant même que le navigateur ne commence à peindre quoi que ce soit.

Ce que dit la recherche sur la vitesse serveur et la décision d’achat

L’intuition que « ça agace » ne suffit pas à convaincre un client ou un associé de prioriser un sujet aussi technique — la recherche, elle, est plus précise. Dans une étude fondatrice publiée en 2004 dans la revue Behaviour & Information Technology, Fiona Fui-Hoon Nah a mesuré le temps d’attente que les internautes tolèrent avant d’abandonner une page : au-delà d’environ deux secondes sans aucun signal de chargement, l’attention décroche et l’abandon devient probable (Nah, 2004). Plus récemment, une étude menée par Wojciech Stadnik et Zdzisław Nowak sur une plateforme e-commerce réelle sous Magento a établi un lien direct et mesurable entre le temps de chargement moyen des pages et le taux de conversion observé, en s’appuyant sur des données Google Analytics de trafic réel plutôt que sur des tests en laboratoire (Stadnik & Nowak, 2018). Le TTFB n’est qu’une composante du temps de chargement total, mais c’est la première : tout retard accumulé ici se répercute intégralement sur toutes les métriques suivantes.

Les causes fréquentes d’un TTFB élevé sur une landing page

• Hébergement mutualisé surchargé ou géographiquement éloigné — un serveur qui traite des centaines de sites simultanément, ou situé loin de l’audience réelle de la page (données publicitaires géociblées, par exemple), ajoute une latence réseau et un temps de file d’attente cumulés.
• Rendu généré à la volée à chaque requête — un CMS ou un framework qui reconstruit la page dynamiquement (requêtes base de données, appels API, assemblage de template) au lieu de servir un fichier statique déjà prêt.
• Absence de cache ou de CDN — sans mise en cache en périphérie de réseau, chaque visiteur déclenche le traitement complet côté serveur d’origine, même si le contenu n’a pas changé depuis la dernière visite.
• Fonctions serverless en démarrage à froid — une architecture basée sur des fonctions qui s’exécutent à la demande peut ajouter plusieurs centaines de millisecondes lors des premiers appels après une période d’inactivité, si la page principale dépend de ce type de fonction plutôt que d’être pré-générée.
• Plugins ou middlewares excessifs — sur un CMS généraliste, chaque plugin actif (analytics, popups, A/B testing serveur, personnalisation) ajoute un traitement avant l’envoi de la réponse.

Comment mesurer son TTFB

Dans Chrome DevTools, onglet Network, cliquez sur le document HTML principal (la première ligne de la liste, en général) et regardez l’onglet Timing : la ligne « Waiting for server response » correspond au TTFB. PageSpeed Insights signale explicitement un audit « Réduire le temps de réponse initial du serveur » lorsqu’il détecte un TTFB dégradé, avec la valeur mesurée. WebPageTest offre la vue la plus détaillée : sa cascade de chargement (waterfall) isole visuellement le DNS, la connexion TLS et le temps d’attente serveur, utile pour diagnostiquer précisément quelle étape pose problème plutôt que de deviner. Comme pour le LCP, testez depuis plusieurs emplacements géographiques si votre audience est répartie, et pas uniquement depuis votre propre connexion de bureau — un résultat local en fibre optique masque souvent un problème bien réel pour un visiteur mobile plus loin du serveur.

Réduire le TTFB sans toucher au design

La bonne nouvelle : contrairement au LCP ou au CLS, corriger le TTFB ne demande presque jamais de retoucher le contenu visible de la page. C’est un sujet d’infrastructure, pas de copywriting ni de mise en page.

1. Pré-générer la page en HTML statique plutôt que de la reconstruire à chaque requête (génération statique, SSG) — le serveur n’a plus qu’à servir un fichier déjà prêt, sans calcul ni appel base de données.
2. Servir la page depuis un réseau de périphérie (CDN edge) qui réplique le fichier statique au plus près géographique de chaque visiteur, éliminant une bonne partie de la latence réseau pure.
3. Éviter tout appel externe bloquant (base de données, API tierce, service de personnalisation) sur le chemin critique qui précède l’envoi du premier octet — ces appels peuvent avoir lieu après, de façon asynchrone, sans retarder l’affichage initial.
4. Configurer des en-têtes de cache corrects (Cache-Control) pour que les visites répétées et les CDN intermédiaires réutilisent une réponse déjà calculée plutôt que d’en redemander une neuve.

Nous détaillons la configuration complète d’un déploiement pensé pour ce résultat dans notre article sur le déploiement d’une landing page Next.js sur Vercel : génération statique au build, distribution via un réseau de périphérie mondial, et zéro base de données à interroger pour afficher la page. C’est aussi ce qui explique une partie de l’écart de TTFB observé entre un site généré ainsi et un CMS traditionnel qui reconstruit chaque page dynamiquement — un sujet que nous creusons dans notre comparatif Next.js contre WordPress.

Le cas particulier des pages alimentées par de la publicité payante

Sur une landing page qui reçoit du trafic Google Ads ou Meta Ads, chaque milliseconde de TTFB coûte littéralement de l’argent : un visiteur qui vient de cliquer sur une annonce a un seuil de patience encore plus bas qu’un visiteur organique, et un chargement lent dégrade à la fois le taux de rebond et, indirectement, le niveau de qualité de l’annonce sur les deux plateformes. Une landing page dédiée à une campagne — contrairement à une page produit d’un site e-commerce complexe, chargée de widgets et de scripts tiers — se prête particulièrement bien à une génération statique complète, précisément parce qu’elle n’a besoin d’aucune donnée dynamique pour s’afficher : le formulaire de capture ou le lien de paiement suffisent, et ils peuvent s’exécuter après l’affichage initial.

C’est le choix technique fait par défaut sur les templates LanderKit : chacun des 10 templates est un projet Next.js autonome, sans base de données ni backend à interroger pour afficher la page, pensé pour un TTFB proche du minimum technique possible dès la mise en ligne. Pour une offre à fort trafic publicitaire, le template SaaS & Liste d’attente ou le template Webinaire illustrent ce principe : formulaire de capture simple, aucune dépendance serveur bloquante, et une page qui répond en quelques dizaines de millisecondes plutôt qu’en plusieurs centaines.

Le TTFB n’est pas le sujet le plus visible d’un audit de landing page — personne ne le mentionne en réunion, contrairement à la couleur du bouton ou au texte du titre. C’est justement pour cela qu’il reste souvent non corrigé pendant des mois : il ne se voit pas à l’œil nu, seulement dans les outils de mesure et, en creux, dans un taux de rebond légèrement plus élevé que ce que le reste de la page laisserait attendre.