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

Optimiser la sous-partie Durée de connexion (TCP + TLS) 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 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 géographiquement éloignés du serveur, la durée de connexion peut ajouter 100 à 500 millisecondes au TTFB en raison des multiples allers-retours nécessaires pour les handshakes TCP et TLS.

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 de connexion 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 de connexion, 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.

La partie durée de connexion 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 s'ajoute au Time to First Byte.

Processus de connexion en détail

Le protocole de contrôle de transmission (TCP) est responsable de l'établissement d'une connexion fiable entre le client (navigateur) et le serveur. Ce processus implique un handshake à trois voies (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 le transfert fiable de données entre le client et le serveur.

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 plusieurs é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 TLS prises en charge, les suites de chiffrement et un nombre aléatoire (Client Random).
• ServerHello : Le serveur répond par un message "ServerHello", sélectionnant la version 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 des autorités de certification de confiance.
• Premaster Secret : Le client génère un secret prémaster, 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 tous deux le secret prémaster, ainsi que le Client Random et le Server Random, pour générer une clé de session partagée pour le chiffrement symétrique.
• Messages terminés : 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 les écoutes et les falsifications par des tiers.

TLS 1.3 vs TLS 1.2 : Pourquoi cela compte 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 nettement plus rapide que TLS 1.2 car il réduit le nombre d'allers-retours nécessaires pour terminer le handshake :

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

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

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 prend en charge la reprise 0-RTT pour des reconnexions plus rapides. De plus, l'utilisation de UDP par QUIC élimine le blocage de tête de ligne (head-of-line blocking) et améliore le contrôle de congestion, ce qui conduit à une transmission de données plus efficace et des chargements de page plus rapides.

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

• Handshake combiné : Avec HTTP/2 sur TCP, le handshake TCP et le handshake TLS se produisent séquentiellement (3 allers-retours au total pour une nouvelle connexion). HTTP/3 sur QUIC combine le transport et le handshake TLS en un seul aller-retour. Pour les nouvelles connexions, cela économise un aller-retour entier par rapport à HTTP/2.
• Reprise de connexion 0-RTT : Comme TLS 1.3, QUIC prend en charge 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 de tête de ligne : Avec HTTP/2 sur TCP, un seul paquet perdu bloque tous les flux sur cette connexion jusqu'à ce que le paquet soit retransmis. QUIC utilise UDP et gère les flux indépendamment, donc un paquet perdu n'affecte que le flux spécifique auquel il appartient. Cela se traduit par des performances de connexion plus cohérentes sur les réseaux peu fiables.
• Migration de connexion : Les connexions QUIC sont identifiées par un ID de connexion plutôt que par une IP source et un port. 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 Preconnect pour les origines critiques

L'indication de ressource <link rel="preconnect"> indique au navigateur d'établir une connexion (DNS + TCP + TLS) vers une origine spécifiée avant même 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, ce qui consomme des ressources CPU et réseau. Ne vous pré-connectez qu'aux origines nécessaires à chaque chargement de page. Pour les origines qui ne sont nécessaires qu'occasionnellement, utilisez plutôt dns-prefetch (voir 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, 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é de TLS 1.3 qui permet aux clients récurrents d'envoyer des données chiffrées immédiatement lors de 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 le besoin pour le client de contacter directement l'autorité de certification.

Voici un exemple de configuration Nginx qui active TLS 1.3 et 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>

CONSEIL Time to First Byte : un CDN n'offre pas seulement 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 durée de connexion avec JavaScript

Vous pouvez mesurer la sous-partie durée de connexion du TTFB directement dans le navigateur en utilisant 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 trouver l'impact que les utilisateurs réels subissent en raison de la latence de connexion, vous devrez utiliser un outil 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 "Time to First Byte breakdown" pour visualiser la partie connexion du Time to First Byte.

Lectures complémentaires : Guides d'optimisation

Pour des techniques d'optimisation connexes qui complètent l'optimisation de la connexion, explorez ces guides :

• 103 Early Hints : le serveur peut envoyer des indications de ressources (preload, preconnect) tout en traitant la réponse principale, permettant au navigateur de commencer à établir des connexions plus tôt.
• Configurer Cloudflare pour la performance : Cloudflare active automatiquement HTTP/3, TLS 1.3 et 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 : Articles approfondis

La durée de connexion est l'une des cinq sous-parties du TTFB. Explorez les autres sous-parties pour comprendre le tableau complet :

• Corriger et identifier les problèmes de TTFB : le point de départ du diagnostic pour toute optimisation du TTFB.
• Durée d'attente : redirections, file d'attente du navigateur et optimisation HSTS.
• Durée de cache : performance du service worker, recherches dans le cache du navigateur et bfcache.
• Durée DNS : sélection du fournisseur DNS, configuration TTL et dns-prefetch.