Quel est un bon objectif de TTFB ?

En dessous de 200 ms est considéré comme bon pour la plupart des sites, entre 200 et 500 ms nécessite une amélioration, et au-delà de 500 ms constitue un véritable problème. Contrairement au LCP ou au CLS, ce n'est pas un Core Web Vital officiel, mais c'est un plancher incontournable sous les trois - rien en aval ne peut commencer avant l'arrivée du premier octet.

Un CDN corrige-t-il le TTFB même pour les pages dynamiques ?

Seulement partiellement. Un CDN accélère les assets statiques et peut mettre en cache des réponses HTML complètes pour les pages qui ne changent pas par requête, mais une page réellement dynamique (contenu personnalisé, données en direct) doit toujours atteindre votre origine - pour cela, la correction est côté serveur (vitesse des requêtes, démarrages à froid de fonction, placement régional), pas la mise en cache.

Pourquoi le TTFB est-il lent sur ma toute première requête après un déploiement mais rapide ensuite ?

C'est presque toujours un démarrage à froid sur une infrastructure serverless - la fonction doit s'initialiser avant de pouvoir traiter la requête. Les requêtes suivantes atteignent une instance chaude. Si votre modèle de trafic est en rafales, les démarrages à froid peuvent compter davantage que ne le suggère votre TTFB moyen.

Scanverra mesure-t-il le TTFB séparément du LCP ?

Oui. C'est une métrique distincte capturée dans la même passe Lighthouse utilisée pour le LCP et le CLS, afin que vous puissiez déterminer si un LCP lent est en réalité un problème de serveur lent déguisé ou un véritable problème de rendu distinct.

Comment corriger un Time to First Byte (TTFB) lent

Pourquoi votre serveur est lent à répondre

Le TTFB est presque entièrement un problème de backend et de réseau, pas de frontend. Causes courantes :

Démarrages à froid. Des fonctions serverless qui doivent démarrer un environnement d'exécution avant de traiter la première requête après un moment d'inactivité.
Un rendu dynamique non mis en cache. Chaque requête réexécute des requêtes de base de données et un rendu côté serveur qui auraient pu être mis en cache ou calculés une seule fois.
Des requêtes de base de données lentes. Une seule requête non indexée ou un motif N+1 peut ajouter des centaines de millisecondes avant même que le serveur puisse commencer à écrire une réponse.
Une longue distance physique jusqu'à l'origine. Un visiteur à Singapour accédant à un serveur en Virginie paie cet aller-retour à chaque requête, quelle que soit la rapidité de réponse du serveur lui-même.
Des chaînes de redirection. Chaque saut (http → https → www → URL finale) est un aller-retour complet avant même que la vraie réponse ne commence.

Comment identifier ce qui est réellement lent

Les contrôles de performance de Scanverra capturent le TTFB dans le cadre de la même exécution Lighthouse utilisée pour le LCP et le CLS, sur votre URL en direct - vous obtenez donc le véritable chiffre de temps de réponse du serveur, pas un proxy de celui-ci. C'est important car un LCP lent avec un TTFB rapide vous oriente vers des corrections d'image/rendu, tandis qu'un LCP lent avec un TTFB lent signifie que corriger le serveur doit venir en premier.

Pour affiner l'endroit où le temps passe réellement, consultez la répartition du timing côté serveur de votre hébergeur ou fournisseur APM (la plupart des plateformes rapportent séparément le temps passé dans l'initialisation de fonction, les appels de base de données et la sérialisation de réponse) plutôt que de deviner depuis l'extérieur.

Comment le corriger

1. Mettez en cache ce qui n'a pas besoin d'être régénéré par requête

Tout ce qui est identique pour chaque visiteur - ou chaque visiteur d'un segment donné - est candidat à la mise en cache. Définissez une durée de vie de cache explicite à l'edge du CDN plutôt que de laisser chaque requête atteindre votre origine :

Mettez en cache à l'edge, mais revalidez en arrière-plan pour que le contenu ne devienne pas obsolètetypescript

1Cache-Control: public, max-age=60, stale-while-revalidate=300

2. Rapprochez votre origine (ou au moins une couche de cache) de vos utilisateurs

Déployez dans une région proche de votre trafic réel, ou placez un cache edge/CDN devant une origine distante afin que la plupart des requêtes n'effectuent jamais le long aller-retour.

3. Corrigez la requête lente, pas le symptôme

Si votre APM montre que le temps de base de données domine le TTFB, il s'agit généralement d'un index manquant, d'un motif de requête N+1, ou d'une requête effectuant plus de travail que la page n'en a réellement besoin - profilez la requête spécifique avant de vous rabattre sur la mise en cache comme solution de contournement.

4. Réduisez la fréquence des démarrages à froid sur les fonctions serverless

Gardez les fonctions chaudes pour les routes sensibles à la latence, minimisez le code et les dépendances devant s'initialiser avant l'exécution du handler, et envisagez un serveur persistant pour les modèles de trafic où les démarrages à froid se produisent constamment.

5. Réduisez les chaînes de redirection

Chaque saut entre l'URL demandée par un utilisateur et l'URL qui sert réellement le contenu est un aller-retour complet ajouté au TTFB avant que le rendu ne puisse commencer - pointez les liens et les URL canoniques directement vers la destination finale.

Comment Scanverra détecte les problèmes de TTFB

Le TTFB est capturé directement à partir de la même véritable passe Lighthouse que Scanverra exécute pour chaque contrôle de performance - à la fois sur un profil ordinateur et sur un viewport mobile de 375 px - il est donc mesuré par rapport à la réponse réelle de votre serveur en direct, pas simulé.