Réduire la sous-partie de durée d'attente du Time to First Byte

Réduire la durée d'attente du Time to First Byte

Cet article fait partie de notre guide sur le Time to First Byte (TTFB). La durée d'attente est la première sous-partie du TTFB et se compose principalement du temps de redirection et de la mise en file d'attente du navigateur. Une durée d'attente élevée est presque toujours causée par des redirections inutiles qui ajoutent des allers-retours avant que le serveur ne puisse commencer à traiter la requête réelle.

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 couvre la partie de la 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 lire 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 à un navigateur pour recevoir 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 par toutes les redirections est pris en compte dans le score TTFB global, le faisant potentiellement 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 exemple, 301 ou 302).
• Le navigateur envoie ensuite une nouvelle requête à l'URL redirigée.
• Le serveur traite cette seconde requête et commence à envoyer le contenu réel.

Types de redirections et leur impact

Toutes les redirections ne se valent pas. Comprendre les différents types vous aide à prioriser les redirections à éliminer en premier :

Une seule redirection ajoute généralement de 50 à 300 millisecondes au TTFB selon les conditions du réseau et le temps de réponse du serveur. Lorsque deux ou trois redirections s'enchaînent, ces temps s'additionnent et peuvent pousser le TTFB bien au-delà du seuil "bon" de 800 ms.

Temps de traitement du serveur accru

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 augmente le TTFB. Chaque redirection dans la chaîne ajoute son propre temps de traitement, s'ajoutant au délai avant que le premier octet de contenu réel ne soit reçu.

Un exemple courant de chaîne de redirection :

http://example.com
  -> 301 -> https://example.com
    -> 301 -> https://www.example.com
      -> 301 -> https://www.example.com/en/

Dans cet exemple, trois redirections ont lieu avant que le navigateur ne reçoive le moindre contenu. La première redirection (HTTP vers HTTPS) peut être éliminée grâce à HSTS. Les deuxième et troisième redirections peuvent être éliminées en mettant à jour les liens internes pour pointer directement vers l'URL finale.

Latence du 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 différents domaines ou serveurs. La distance physique entre le client et le serveur pour chaque redirection peut encore 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) s'ajoutent au Time to First Byte. Les redirections JavaScript ne s'ajoutent pas 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 privilégiées puisqu'elles ne s'ajoutent pas au Time to First Byte. Malheureusement, les redirections JavaScript sont beaucoup plus lentes pour les vrais utilisateurs et causeront une 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 Vitals pris en compte par les moteurs de recherche.
• Budget d'exploration : Les robots d'exploration des moteurs de recherche suivent les redirections, ce qui signifie que chaque redirection consomme un budget d'exploration supplémentaire. Pour les grands sites web, cela peut ralentir la découverte de contenu nouveau ou mis à jour.

Comment mesurer les problèmes de TTFB causés par les redirections

Pour trouver l'impact que subissent les vrais utilisateurs à cause des redirections, vous devrez utiliser un outil RUM comme CoreDash. Le Real User Monitoring vous permettra de suivre les Core Web Vitals de manière très détaillée.

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 redirection" et afficher toutes les URLs affectées.

Comment auditer votre site pour les redirections

Un audit systématique des redirections implique trois étapes :

Étape 1 : Explorez votre site

Utilisez un outil d'exploration (tel que MarketingTracer, Screaming Frog ou Sitebulb) pour explorer l'intégralité de votre site web. L'explorateur signalera toutes les URLs internes qui répondent avec un code d'état 3xx. Exportez la liste et triez par le nombre de liens internes entrants pointant vers chaque URL redirigée.

Étape 2 : Identifiez les chaînes de redirection

Filtrez les résultats de l'exploration pour toute URL qui redirige vers une autre URL qui redirige également. Ces chaînes doivent être corrigées en premier car elles multiplient la pénalité sur le TTFB.

Étape 3 : Corrigez et vérifiez

Mettez à jour vos liens internes pour pointer directement vers l'URL de destination finale. Après avoir mis à jour les liens, réexplorez pour vérifier que les redirections ne sont plus déclenchées depuis la navigation interne. Utilisez l'extrait JavaScript suivant pour détecter les redirections depuis le navigateur :

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  if (nav.redirectCount > 0) {
    console.warn('Redirect detected!', {
      redirectCount: nav.redirectCount,
      redirectTime: nav.redirectEnd - nav.redirectStart,
      finalUrl: nav.name
    });
  }
}).observe({
  type: 'navigation',
  buffered: true
});

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 cela 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 plutôt que des redirections côté client quand 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 consiste à utiliser l'un des outils disponibles qui vous permettra 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 webmestre du site pour mettre à jour l'URL liée.

Chaînes de redirection. De multiples redirections ou chaînes de redirection se produisent lorsqu'une seule redirection ne redirige pas vers l'emplacement final de la ressource. Ces types de redirections mettent davantage à l'épreuve 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 les corriger.

Redirections HTTP vers HTTPS et HSTS

Les redirections HTTP vers HTTPS sont l'un des types de redirection les plus courants. Chaque visiteur qui tape votre domaine sans "https://" ou qui suit un ancien lien HTTP subira une redirection 301. L'en-tête Strict-Transport-Security (HSTS) élimine cette redirection pour les visiteurs de retour en indiquant au navigateur de toujours utiliser HTTPS.

Pour activer HSTS, ajoutez l'en-tête suivant à la réponse de votre serveur :

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Voici ce que signifie chaque directive :

• max-age=31536000 : le navigateur se souviendra d'utiliser HTTPS pour ce domaine pendant un an (31 536 000 secondes).
• includeSubDomains : applique également l'exigence HTTPS à tous les sous-domaines.
• preload : permet à votre domaine d'être inclus dans la liste de préchargement HSTS intégrée au navigateur, ce qui signifie que même la toute première visite utilisera HTTPS sans redirection.

Pour soumettre votre domaine à la liste de préchargement HSTS, visitez hstspreload.org. Une fois votre domaine sur la liste de préchargement, les navigateurs ne feront jamais de requête HTTP vers votre domaine, éliminant complètement la redirection HTTP vers HTTPS pour tous les visiteurs.

Dans Apache, vous pouvez ajouter HSTS avec :

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Dans Nginx :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

En général, nous recommandons de :

1. Vérifier et mettre à 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'ancien emplacement de la page.
2. Gérer les redirections au niveau du serveur. 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, peuvent ne pas être mises à jour dans les moteurs de recherche.
3. Utiliser des URL relatives : lors de la création de 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.
4. Utiliser 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 à éviter le contenu dupliqué et les redirections inutiles.

Pour aller plus loin : Guides d'optimisation

Guides associés :

• 103 Early Hints : réduire le TTFB perçu en envoyant des indices de ressources pendant que le serveur traite la réponse complète.
• Configurer Cloudflare pour les performances : optimiser votre configuration CDN pour réduire les chaînes de redirection et améliorer le TTFB global.

Sous-parties du TTFB : Guides complets

La durée d'attente est l'une des cinq sous-parties du TTFB. Explorez les autres sous-parties pour comprendre la situation dans son ensemble :

• Corriger et identifier les problèmes de TTFB : le point de départ diagnostique pour toute optimisation du TTFB.
• Durée de cache : performances des service workers, recherches dans le cache du navigateur et bfcache.
• Durée DNS : sélection du fournisseur DNS, configuration du TTL et dns-prefetch.
• Durée de connexion : handshake TCP, optimisation TLS, HTTP/3 et preconnect.
• Durée de requête : temps de traitement du serveur, requêtes de base de données et optimisation backend.