Optimiser la sous-partie Connection Duration (TCP + TLS) du Time to First Byte

Optimiser la Connection Duration (TCP + TLS) du Time to First Byte

Cet article fait partie de notre guide sur le Time to First Byte (TTFB). La connection duration est la quatrième sous-partie du TTFB et représente le temps que le navigateur passe à établir une connexion TCP et à négocier le chiffrement TLS avec le serveur. Pour les utilisateurs qui sont géographiquement éloignés du serveur, la connection duration peut ajouter 100 à 500 millisecondes au TTFB en raison des multiples allers-retours (round trips) requis pour les handshakes TCP et TLS.

Le Time to First Byte (TTFB) peut être décomposé en les sous-parties suivantes :

• Waiting + Redirect (ou waiting duration)
• Worker + Cache (ou cache duration)
• DNS (ou DNS duration)
• Connection (ou connection duration)
• Request (ou request duration)

Vous cherchez à optimiser le Time to First Byte ? Cet article couvre la partie connection duration 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 connection duration, veuillez lire qu'est-ce que le Time to First Byte et identifier et corriger les problèmes de Time to First Byte avant de commencer cet article.

La partie connection duration du Time to First Byte correspond au temps pendant lequel le navigateur se connecte au serveur web. Après cette connexion, le navigateur et le serveur ajoutent généralement une couche de chiffrement (TLS). Le processus de négociation de ces 2 connexions prendra un certain temps, et ce temps est ajouté au Time to First Byte.

Processus de connexion en détail

Le Transmission Control Protocol (TCP) est responsable de l'établissement d'une connexion fiable entre le client (navigateur) et le serveur. Ce processus implique un handshake en trois étapes (three-way handshake) :

• Paquet SYN (Synchronize) : le client envoie un paquet SYN au serveur pour initier la connexion et demander la synchronisation.
• Paquet SYN-ACK (Synchronize-Acknowledge) : le serveur répond par un paquet SYN-ACK, accusant réception du paquet SYN et acceptant d'établir une connexion.
• Paquet ACK (Acknowledge) : le client renvoie un paquet ACK au serveur, confirmant la réception du paquet SYN-ACK. À ce stade, une connexion TCP est établie, permettant aux données d'être transférées de manière fiable entre le client et le serveur.

Le TCP garantit que les données sont envoyées et reçues dans le bon ordre, en renvoyant les paquets perdus et en gérant le contrôle de flux pour s'adapter à la capacité du réseau.

Une fois la connexion TCP établie, le protocole Transport Layer Security (TLS) est utilisé pour sécuriser la connexion. Le handshake TLS implique several étapes pour authentifier le serveur et établir un canal de communication sécurisé :

• ClientHello : le client envoie un message « ClientHello » au serveur, indiquant les versions de TLS supportées, les suites de chiffrement (cipher suites) et un nombre aléatoire (Client Random).
• ServerHello : le serveur répond par un message « ServerHello », sélectionnant la version de TLS et la suite de chiffrement dans la liste du client, et fournissant son certificat numérique et un nombre aléatoire (Server Random).
• Échange de certificat et de clé : le serveur envoie son certificat numérique au client pour authentification. Le client vérifie le certificat auprès d'autorités de certification de confiance.
• Premaster Secret : le client génère un secret maître préalable (premaster secret), le chiffre avec la clé publique du serveur (provenant du certificat) et l'envoie au serveur.
• Génération de la clé de session : le client et le serveur utilisent tous deux le premaster secret, ainsi que le Client Random et le Server Random, pour génere une clé de session partagée pour le chiffrement symétrique.
• Messages Finished : le client et le serveur échangent des messages chiffrés avec la clé de session pour confirmer que le handshake a réussi et que les deux parties disposent de la bonne clé de session.

Une fois le handshake TLS terminé, le client et le serveur ont établi une connexion sécurisée et chiffrée. Cela garantit que toutes les données échangées sont protégées contre l'écoute clandestine et la falsification par des tiers.

TLS 1.3 vs TLS 1.2 : Pourquoi c'est important pour le TTFB

La version de TLS utilisée par votre serveur a un impact direct sur la connection duration. Le TLS 1.3 est plus rapide que le TLS 1.2 car il réduit le nombre d'allers-retours nécessaires pour terminer le handshake :

Le TLS 1.3 réduit le handshake de deux allers-retours à un seul. Pour un utilisateur situé à 100ms du serveur (temps d'aller-retour), cela permet d'économiser environ 100ms sur chaque nouvelle connexion. Pour les visiteurs récurrents, la reprise 0-RTT (zero round trip time) du TLS 1.3 permet au client d'envoyer des données chiffrées immédiatement après la reconnexion en réutilisant les informations de session précédemment échangées. Cela peut réduire la charge du handshake TLS à presque zéro pour les visiteurs réguliers.

HTTP/3 et QUIC : L'avenir des connexions rapides

L'HTTP/3 accélère les connexions TLS en s'intégrant au protocole QUIC, qui réduit le nombre d'allers-retours nécessaires pour établir une connexion sécurisée en combinant les processus de handshake en un seul, et supporte la reprise 0-RTT pour des reconnexions plus rapides. De plus, l'utilisation de l'UDP par QUIC élimine le blocage en tête de ligne (head-of-line blocking) et améliore le contrôle de la congestion, ce qui conduit à une transmission de données plus efficace et à des chargements de page plus rapides.

L'HTTP/3 apporte plusieurs améliorations par rapport à l'HTTP/2 qui affectent directement la connection duration :

• Handshake combiné : Avec l'HTTP/2 sur TCP, le handshake TCP et le handshake TLS se produisent séquentiellement (3 allers-retours au total pour une nouvelle connexion). L'HTTP/3 sur QUIC combine le transport et le handshake TLS en un seul aller-retour. Pour les nouvelles connexions, cela permet d'économiser un aller-retour complet par rapport à l'HTTP/2.
• Reprise de connexion 0-RTT : Comme le TLS 1.3, QUIC supporte la reprise 0-RTT. Les visiteurs récurrents peuvent commencer à envoyer des données immédiatement sans attendre la fin d'un handshake. C'est particulièrement efficace pour les utilisateurs mobiles qui basculent fréquemment entre le Wi-Fi et les connexions cellulaires.
• Pas de blocage en tête de ligne : Avec l'HTTP/2 sur TCP, un seul paquet perdu bloque tous les flux sur cette connexion jusqu'à ce que le paquet soit retransmis. QUIC utilise l'UDP et gère les flux indépendamment, de sorte qu'un paquet perdu n'affecte que le flux spécifique auquel il appartient. Cela permet d'obtenir des performances de connexion plus cohérentes sur des réseaux peu fiables.
• Migration de connexion : Les connexions QUIC sont identifiées par un ID de connexion plutôt que par une IP et un port source. Cela signifie que lorsqu'un utilisateur mobile passe du Wi-Fi au cellulaire (et que son adresse IP change), la connexion QUIC survit sans avoir besoin d'être rétablie. Cela évite le handshake TCP + TLS complet qui serait autrement requis.

Comment le temps de connexion impacte-t-il le Time to First Byte ?

Comment minimiser l'impact du temps de connexion sur le TTFB

Utiliser le Preconnect pour les origines critiques

L'indice de ressource <link rel="preconnect"> indique au navigateur d'établir une connexion (DNS + TCP + TLS) vers une origine spécifiée avant que les ressources de cette origine ne soient réellement nécessaires. Cela élimine la connection duration du chemin critique lorsque la ressource est finalement demandée :

<!-- Preconnect vers les origines tierces critiques -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">

Utilisez le preconnect avec parcimonie (3 à 5 origines maximum). Chaque preconnect ouvre une connexion TCP + TLS complète, ce qui consomme des ressources CPU et réseau. Ne faites un preconnect que vers les origines qui sont nécessaires à chaque chargement de page. Pour les origines qui ne sont nécessaires qu'occasionnellement, utilisez plutôt dns-prefetch (consultez notre guide sur la DNS duration).

Configuration du serveur pour le TLS 1.3 et l'HTTP/3

• HTTP/3 : apporte le protocole QUIC sur UDP au lieu de TCP, permettant un transfert de données plus rapide et plus efficace.
• TLS 1.3 : ajoute plus de sécurité et réduit les allers-retours du handshake. Requis pour la reprise de connexion 0-RTT.
• Reprise de connexion 0-RTT : fonctionnalité du TLS 1.3 qui permet aux clients récurrents d'envoyer des données chiffrées immédiatement après la reconnexion en réutilisant les informations précédemment échangées.
• TCP Fast Open : permet d'envoyer des données dans le paquet SYN initial, réduisant le temps d'aller-retour pour le handshake TCP.
• TLS False Start : permet l'envoi précoce de données avant que le handshake TLS ne soit terminé.
• OCSP Stapling : accélère la validation du certificat en éliminant la nécessité pour le client de contacter directement l'autorité de certification.

Voici un exemple de configuration Nginx qui active le TLS 1.3 et l'OCSP Stapling :

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # Suites de chiffrement TLS 1.3
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # Activer l'OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # Activer la reprise de session (TLS session tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... reste de votre configuration serveur
}

Pour Apache, activez le TLS 1.3 avec :

<VirtualHost *:443>
    SSLEngine on
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Activer l'OCSP Stapling
    SSLUseStapling On
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    # Activer la reprise de session
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... reste de votre configuration de serveur virtuel
</VirtualHost>

CONSEIL sur le Time to First Byte : un CDN ne permet pas seulement d'obtenir des temps d'aller-retour plus courts. L'utilisation d'un CDN améliorera souvent immédiatement les temps de connexion TCP et TLS, car les fournisseurs de CDN premium auront correctement configuré ces paramètres pour vous. Consultez notre guide sur la façon de configurer Cloudflare pour la performance pour commencer.

Mesurer la Connection Duration with JavaScript

Vous pouvez mesurer la sous-partie connection duration du TTFB directement dans le navigateur à l'aide de l'API Navigation Timing :

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');

  const tcpDuration = nav.connectEnd - nav.connectStart;
  const tlsDuration = nav.connectEnd - nav.secureConnectionStart;
  const totalConnection = tcpDuration;

  console.log('Connection Duration:', totalConnection.toFixed(0), 'ms');
  console.log('  Handshake TCP:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  Négociation TLS:', tlsDuration.toFixed(0), 'ms');

  if (nav.nextHopProtocol) {
    console.log('  Protocole:', nav.nextHopProtocol);
  }
}).observe({
  type: 'navigation',
  buffered: true
});

La propriété nextHopProtocol révèle quel protocole a été utilisé pour la connexion. Les valeurs courantes sont « h2 » (HTTP/2), « h3 » (HTTP/3) et « http/1.1 ». Si votre serveur supporte l'HTTP/3 mais que vos données RUM montrent que la plupart des connexions utilisent « h2 », cela peut indiquer que le support de l'HTTP/3 n'est pas correctement annoncé via l'en-tête Alt-Svc.

Comment trouver les problèmes de TTFB causés par un temps de connexion lent

Pour trouver l'impact que subissent les utilisateurs réels à cause de la latence de connexion, vous devrez utiliser un outil de RUM comme CoreDash. Le Real User Monitoring vous permettra de suivre les Core Web Vitals plus en détail et sans le délai de 28 jours de Google.

Dans CoreDash, cliquez sur « Décomposition du Time to First Byte » pour visualiser la partie connexion du Time to First Byte.

Lectures complémentaires : Guides d'optimisation

Guides connexes :

• 103 Early Hints : le serveur peut envoyer des indices de ressources (preload, preconnect) tout en traitant encore la réponse principale, permettant au navigateur de commencer à établir les connexions plus tôt.
• Configurer Cloudflare pour la performance : Cloudflare active automatiquement l'HTTP/3, le TLS 1.3 et l'OCSP Stapling. L'utilisation d'un CDN rapproche également votre serveur des utilisateurs, réduisant les temps d'aller-retour pour toutes les connexions.

Sous-parties du TTFB : Guides complets

La connection duration est l'une des cinq sous-parties du TTFB. Explorez les autres sous-parties pour comprendre l'image complète :

• Fix and Identify TTFB Issues : le point de départ du diagnostic pour toute l'optimisation du TTFB.
• Waiting Duration : redirections, mise en file d'attente du navigateur et optimisation HSTS.
• Cache Duration : performance du service worker, recherches dans le cache du navigateur et bfcache.
• DNS Duration : sélection du fournisseur DNS, configuration du TTL et dns-prefetch.
• Request Duration : temps de traitement du serveur, requêtes de base de données et optimisation du backend.