Optimisez la sous-partie durée de connexion (TCP + TLS) du Time to First Byte

Optimisez la durée de connexion (TCP + TLS), une sous-partie du Time to First Byte

Cet article fait partie de notre guide sur le Time to First Byte (TTFB). La durée de connexion est la quatrième sous-partie du TTFB. Elle représente le temps passé par le navigateur à établir une connexion TCP et à négocier le chiffrement TLS avec le serveur. Pour les utilisateurs éloignés géographiquement du serveur, la durée de connexion peut ajouter 100 à 500 millisecondes au TTFB. Cela est dû aux multiples allers-retours nécessaires pour les poignées de main TCP et TLS.

Le Time to First Byte (TTFB) se décompose en plusieurs sous-parties :

• 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 durée de connexion du Time to First Byte. Si vous voulez comprendre ou corriger le Time to First Byte et ignorez ce que signifie la durée de connexion, lisez d'abord 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 durée de connexion du Time to First Byte correspond au temps de connexion du navigateur 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 deux connexions prend du temps. Ce temps s'ajoute au Time to First Byte.

Le processus de connexion en détail

Le protocole TCP (Transmission Control Protocol) est chargé d'établir une connexion fiable entre le client (navigateur) et le serveur. Ce processus implique une poignée de main en trois temps (three-way handshake) :

• Paquet SYN (Synchronisation) : le client envoie un paquet SYN au serveur pour initier la connexion et demander la synchronisation.
• Paquet SYN-ACK (Synchronisation-Acquittement) : le serveur répond avec un paquet SYN-ACK. Il accuse réception du paquet SYN et accepte d'établir une connexion.
• Paquet ACK (Acquittement) : le client renvoie un paquet ACK au serveur. Il confirme la réception du paquet SYN-ACK. À ce stade, la connexion TCP est établie. Les données peuvent ê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. Il renvoie les paquets perdus et gère le contrôle de flux pour s'adapter à la capacité du réseau.

Une fois la connexion TCP établie, le protocole TLS (Transport Layer Security) sécurise la connexion. La poignée de main TLS implique plusieurs étapes pour authentifier le serveur et établir un canal de communication sécurisé :

• ClientHello : le client envoie un message « ClientHello » au serveur. Ce message indique les versions TLS prises en charge, les suites de chiffrement et un nombre aléatoire (Client Random).
• ServerHello : le serveur répond par un message « ServerHello ». Il sélectionne la version TLS et la suite de chiffrement dans la liste du client. Il fournit 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.
• Secret prémaître (Premaster Secret) : le client génère un secret prémaître. Il le chiffre avec la clé publique du serveur (issue du certificat) et l'envoie au serveur.
• Génération de la clé de session : le client et le serveur utilisent le secret prémaître, ainsi que le Client Random et le Server Random. Ils génèrent 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. Cela confirme le succès de la poignée de main et l'obtention de la bonne clé de session par les deux parties.

Une fois la poignée de main TLS terminée, 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 les écoutes clandestines et les altérations 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 durée de connexion. TLS 1.3 est plus rapide que TLS 1.2. Il réduit le nombre d'allers-retours nécessaires pour terminer la poignée de main :

TLS 1.3 réduit la poignée de main de deux allers-retours à un seul. Pour un utilisateur situé à 100 ms du serveur (temps de l'aller-retour), cela fait gagner environ 100 ms sur chaque nouvelle connexion. Pour les visiteurs récurrents, la reprise 0-RTT (zéro aller-retour) de TLS 1.3 permet au client d'envoyer des données chiffrées immédiatement lors de la reconnexion. Il réutilise les informations de session échangées précédemment. Cela peut réduire le coût de la poignée de main TLS à presque zéro pour les visiteurs réguliers.

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

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

HTTP/3 apporte plusieurs améliorations par rapport à HTTP/2. Elles affectent directement la durée de connexion :

• Poignée de main combinée : avec HTTP/2 sur TCP, les poignées de main TCP et TLS se déroulent séquentiellement (3 allers-retours au total pour une nouvelle connexion). HTTP/3 sur QUIC combine les poignées de main de transport et TLS en un seul aller-retour. Pour les nouvelles connexions, cela économise un aller-retour complet par rapport à HTTP/2.
• Reprise de connexion 0-RTT : comme TLS 1.3, QUIC supporte la reprise 0-RTT. Les visiteurs récurrents peuvent commencer à envoyer des données immédiatement. Ils n'ont pas à attendre la fin de la poignée de main. Cela est très efficace pour les utilisateurs mobiles qui basculent fréquemment entre le Wi-Fi et les connexions cellulaires.
• Aucun blocage en tête de file : avec HTTP/2 sur TCP, un seul paquet perdu bloque tous les flux sur cette connexion jusqu'à sa retransmission. QUIC utilise UDP et gère les flux de manière indépendante. Un paquet perdu n'affecte donc que le flux spécifique auquel il appartient. Cela donne des performances de connexion plus stables sur les réseaux peu fiables.
• Migration de connexion : les connexions QUIC sont identifiées par un ID de connexion. Elles ne dépendent pas d'une adresse IP source et d'un port. Lorsqu'un utilisateur mobile passe du Wi-Fi au réseau cellulaire (et que son adresse IP change), la connexion QUIC survit. Elle n'a pas besoin d'être rétablie. Cela évite la poignée de main complète TCP + TLS qui serait autrement requise.

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

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

Utilisez preconnect pour les origines critiques

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

<!-- Preconnect to critical third-party origins -->
<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 preconnect avec parcimonie (3 à 5 origines maximum). Chaque preconnect ouvre une connexion TCP + TLS complète. Cela consomme du CPU et des ressources réseau. Limitez preconnect aux origines nécessaires sur chaque chargement de page. Pour les origines requises occasionnellement, utilisez plutôt dns-prefetch (consultez notre guide sur la durée DNS).

Configuration du serveur pour TLS 1.3 et HTTP/3

• HTTP/3 : apporte le protocole QUIC sur UDP au lieu de TCP. Cela permet un transfert de données plus rapide et plus efficace.
• TLS 1.3 : ajoute plus de sécurité et réduit les allers-retours de la poignée de main. Requis pour la reprise de connexion 0-RTT.
• Reprise de connexion 0-RTT : fonctionnalité de TLS 1.3. Elle permet aux clients récurrents d'envoyer immédiatement des données chiffrées lors de la reconnexion. Elle réutilise les informations échangées précédemment.
• TCP Fast Open : permet d'envoyer des données dans le paquet SYN initial. Cela réduit le temps d'aller-retour pour la poignée de main TCP.
• TLS False Start : autorise l'envoi anticipé de données avant la fin de la poignée de main TLS.
• OCSP Stapling : accélère la validation du certificat. Cela évite au client de contacter directement l'autorité de certification.

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

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # TLS 1.3 cipher suites
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

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

    # Enable session resumption (TLS session tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... rest of your server configuration
}

Pour Apache, activez TLS 1.3 avec :

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

    # Enable OCSP Stapling
    SSLUseStapling On
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    # Enable session resumption
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... rest of your virtual host configuration
</VirtualHost>

Astuce Time to First Byte : un CDN ne fait pas que raccourcir les temps d'aller-retour. Utiliser un CDN améliorera souvent immédiatement vos temps de connexion TCP et TLS. Les fournisseurs de CDN premium ont déjà configuré ces paramètres correctement pour vous. Consultez notre guide pour configurer Cloudflare pour la performance afin de démarrer.

Mesurer la durée de connexion avec JavaScript

Vous pouvez mesurer la durée de connexion (sous-partie du TTFB) directement dans le navigateur avec la Navigation Timing API :

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('  TCP handshake:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  TLS negotiation:', tlsDuration.toFixed(0), 'ms');

  if (nav.nextHopProtocol) {
    console.log('  Protocol:', 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 HTTP/3 mais que vos données RUM montrent que la plupart des connexions utilisent « h2 », cela peut indiquer que le support 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 mesurer l'impact de la latence de connexion sur les utilisateurs réels, utilisez un outil RUM comme CoreDash. Le Real User Monitoring permet de suivre les Core Web Vitals plus en détail. Vous évitez aussi le délai de 28 jours de Google.

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

Lectures complémentaires : Guides d'optimisation

Guides associés :

• 103 Early Hints : le serveur peut envoyer des indications de ressource (preload, preconnect) pendant qu'il traite encore la réponse principale. Cela permet au navigateur de commencer à établir les connexions plus tôt.
• Configurer Cloudflare pour la performance : Cloudflare active automatiquement HTTP/3, TLS 1.3 et l'OCSP Stapling. Utiliser un CDN rapproche aussi votre serveur des utilisateurs. Cela réduit les temps d'aller-retour pour toutes les connexions.

Sous-parties du TTFB : Guides complets

La durée de connexion est l'une des cinq sous-parties du TTFB. Explorez les autres sous-parties pour avoir une vue d'ensemble :

• Identifier et corriger les problèmes de TTFB : le point de départ du diagnostic pour toute optimisation du TTFB.
• Durée d'attente (Waiting Duration) : redirections, mise en file d'attente du navigateur et optimisation HSTS.
• Durée de cache (Cache Duration) : performances des service workers, recherches dans le cache du navigateur et bfcache.
• Durée DNS (DNS Duration) : choix du fournisseur DNS, configuration du TTL et dns-prefetch.
• Durée de requête (Request Duration) : temps de traitement du serveur, requêtes en base de données et optimisation backend.