Réduire la sous-partie durée d'attente du Time to First Byte
La durée d'attente se compose des redirections et d'autres processus du navigateur. Comprenez la sous-partie du TTFB pour réduire le temps total jusqu'au premier octet (Time to First Byte).

Réduire la durée d'attente du Time to First Byte
Le Time to First Byte (TTFB) peut être décomposé en sous-parties suivantes :
- Attente + Redirection (ou durée d'attente)
- Worker + Cache (ou durée de cache)
- DNS (ou durée DNS)
- Connexion (ou durée de connexion)
- Requête (ou durée de requête)
Vous cherchez à optimiser le Time to First Byte ? Cet article fournit une analyse approfondie de la partie durée d'attente du Time to First Byte. Si vous cherchez à comprendre ou à corriger le Time to First Byte et que vous ne savez pas ce que signifie la durée d'attente, veuillez consulter qu'est-ce que le Time to First Byte et corriger et identifier les problèmes de Time to First Byte avant de commencer cet article.
Les redirections peuvent avoir un impact important sur le Time to First Byte (TTFB) car chaque redirection s'ajoute au temps nécessaire pour qu'un navigateur reçoive le premier octet de données d'un serveur. Voici comment les redirections influencent le TTFB :
Comment les redirections augmentent-elles le Time to First Byte ?
Les redirections sont généralement incluses dans la mesure complète du TTFB (voir l'encadré bleu). Cela signifie que le temps pris pour toutes les redirections est pris en compte dans le score global TTFB, ce qui peut le faire paraître plus élevé que prévu.
Lorsqu'une page est redirigée, voici les étapes habituelles qui se produisent :
- Le navigateur envoie une requête initiale à l'URL d'origine.
- Le serveur traite cette requête et répond avec un code d'état de redirection (par ex. 301 ou 302).
- Le navigateur envoie ensuite une nouvelle requête à l'URL redirigée.Le serveur traite cette deuxième requête et commence à envoyer le contenu réel.
Augmentation du temps de traitement du serveur
Ce traitement supplémentaire augmente le TTFB global, car chaque étape nécessite du temps pour que le serveur traite la requête et réponde.
Chaînes de redirection
Dans certains cas, plusieurs redirections peuvent se produire avant d'atteindre la destination finale. Cela crée une "chaîne de redirection" qui peut augmenter le TTFB. Chaque redirection dans la chaîne ajoute son propre temps de traitement, ajoutant au délai avant que le premier octet de contenu réel ne soit reçu.
Latence réseau
Les redirections impliquent souvent des allers-retours réseau supplémentaires entre le client et le serveur. Cela introduit une latence réseau supplémentaire, surtout si les redirections impliquent des domaines ou des serveurs différents. La distance physique entre le client et le serveur pour chaque redirection peut également impacter le TTFB.
Redirections JavaScript vs Redirections côté serveur: Seules les redirections côté serveur (qui fonctionnent avec un en-tête de redirection 30x) sont ajoutées au Time to First Byte. Les redirections JavaScript ne sont pas ajoutées au Time to First Byte car une réponse complète (200) a été envoyée par le serveur.
On pourrait penser que les redirections JavaScript devraient être préférées car elles n'ajoutent pas au Time to First Byte. Malheureusement, les redirections JavaScript sont beaucoup plus lentes pour les utilisateurs réels et seront une cause de mauvaise User Experience,
Impact sur l'User Experience (et le SEO)
Bien que les redirections soient parfois nécessaires, leur impact sur le TTFB peut avoir des implications plus larges :
- User Experience: Un TTFB plus lent dû aux redirections peut retarder le rendu initial de la page, frustrant potentiellement les utilisateurs.
- SEO: Bien que le TTFB ne soit pas un facteur de classement direct, il influence d'autres métriques comme le Largest Contentful Paint (LCP), qui est un Core Web Vital pris en compte par les moteurs de recherche.
Comment mesurer les problèmes de TTFB causés par les redirections
Pour trouver l'impact que les utilisateurs réels subissent à cause des redirections, vous devrez utiliser un outil RUM comme CoreDash. Le Real User Monitoring vous permettra de suivre les Core Web Vitals dans les moindres détails.
Dans CoreDash cliquez simplement sur 'redirect count' pour visualiser vos données segmentées par nombre de redirections. Ensuite, par exemple, cliquez sur le segment '1 redirect' pour filtrer les données RUM par '1 redirect' et voir toutes les URL affectées.

Comment minimiser l'impact des redirections
En règle générale, suivez ces 3 étapes simples pour éviter les problèmes de redirection :
- Minimisez l'utilisation des redirections lorsque c'est possible.
- Évitez les chaînes de redirection en mettant à jour les liens pour qu'ils pointent directement vers l'URL de destination finale.
- Utilisez des redirections côté serveur au lieu de redirections côté client lorsque c'est possible, car elles sont généralement plus rapides.
Redirections de même origine. Les redirections de même origine proviennent de liens sur votre propre site web. Vous devriez avoir un contrôle total sur ces liens et vous devriez prioriser la correction de ces liens lorsque vous travaillez sur le Time to First Byte. La méthode typique pour trouver ces redirections internes est d'utiliser l'un des outils disponibles qui vous permettront de vérifier l'ensemble de votre site web pour les redirections.
Redirections cross-origin. Les redirections cross-origin proviennent de liens sur d'autres sites web. Vous avez très peu de contrôle sur celles-ci. Pour les liens à fort impact qui génèrent beaucoup de trafic, envisagez de contacter le webmaster du site pour mettre à jour l'URL liée.
Chaînes de redirection. Des redirections multiples ou des chaînes de redirection se produisent lorsqu'une seule redirection ne redirige pas vers l'emplacement final de la ressource. Ces types de redirection pèsent davantage sur le Time to First Byte et doivent être évités à tout prix. Encore une fois, utilisez un outil pour trouver ces types de redirections et corrigez-les !
Redirections HTTP vers HTTPS. Une façon de contourner cela est d'utiliser l'en-tête Strict-Transport-Security (HSTS), qui imposera HTTPS lors de la première visite d'une origine, puis indiquera au navigateur d'accéder immédiatement à l'origine via le schéma HTTPS lors des visites futures.
En général, nous recommandons de :
- Vérifiez et mettez à jour régulièrement vos liens internes ! Chaque fois que vous modifiez l'emplacement d'une page, mettez à jour vos liens internes vers cette page pour vous assurer qu'il ne reste aucune référence à l'emplacement précédent de la page.
- Gérez les redirections au niveau du serveur. Où la méthode de redirection préférée est une redirection 301. Une redirection 301 est une redirection permanente, tandis qu'une redirection 302 est une redirection temporaire. Les redirections temporaires, par exemple, pourraient ne pas être mises à jour dans les moteurs de recherche.
- Utilisez des URL relatives : Lorsque vous créez des liens vers des pages de votre propre site web, utilisez des URL relatives au lieu d'URL absolues. Cela aidera à prévenir les redirections inutiles.
- Utilisez des URL canoniques : Si vous avez plusieurs pages avec un contenu similaire, utilisez une URL canonique pour indiquer la version préférée de la page. Cela aidera à prévenir le contenu dupliqué et les redirections inutiles.
CrUX data is 28 days late.
Google provides data 28 days late. CoreDash provides data in real-time. Debug faster.
- Real-Time Insights
- Faster Debugging
- Instant Feedback

