Un revendeur de matériel électronique migrait son infrastructure serveur et en a profité pour poser la question suivante : le passage de TLS 1.2 à TLS 1.3 vaut-il vraiment la mesure sur un site WordPress à fort trafic, ou s’agit-il d’une amélioration surtout théorique ? Pour y répondre avec des chiffres plutôt qu’une intuition, la migration a été accompagnée d’une série de mesures de latence de connexion, avant et après, depuis trois régions différentes.
Le certificat du site était déjà géré via Certbot et Let’s Encrypt, ce qui a simplifié la bascule : l’activation de TLS 1.3 relève de la configuration du serveur web, pas du certificat lui-même, qui reste valable pour les deux versions du protocole.
Pourquoi TLS 1.3 réduit la latence de connexion
L’établissement d’une connexion TLS 1.2 classique nécessite généralement deux allers-retours réseau complets avant que le premier octet de données applicatives ne puisse être échangé : un pour la négociation initiale des paramètres de chiffrement, un second pour finaliser l’échange de clés. TLS 1.3 simplifie ce mécanisme et parvient à établir une connexion sécurisée complète en un seul aller-retour, grâce à une négociation de clés simplifiée qui devine les paramètres de chiffrement probables dès le premier message.
Ce gain d’un aller-retour a un impact direct sur la latence perçue, proportionnel au temps de trajet réseau entre le visiteur et le serveur : plus la distance est grande, plus économiser un aller-retour complet représente un gain absolu important en millisecondes.
La configuration mise en place
Sur ce serveur nginx, l’activation de TLS 1.3 s’est faite en ajoutant la version au protocole accepté, en conservant TLS 1.2 en repli pour les visiteurs utilisant encore d’anciens navigateurs :
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;Le renouvellement automatique du certificat via Certbot n’a nécessité aucune modification, la commande de renouvellement restant identique :
certbot renew --dry-run
Le protocole de mesure
Le temps d’établissement de connexion TLS a été mesuré avec l’outil curl, en isolant spécifiquement cette étape via son format de sortie détaillé, depuis trois points de mesure : Paris, siège de l’hébergement, New York et Singapour, deux zones où le site recevait un trafic croissant :
curl -o /dev/null -s -w 'Connexion TLS : %{time_appconnect}\n' https://exemple.fr/Les résultats mesurés
| Point de mesure | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Paris (proche du serveur) | 28 ms | 16 ms |
| New York | 172 ms | 94 ms |
| Singapour | 310 ms | 168 ms |
Le gain relatif reste proche d’un facteur deux dans les trois cas, confirmant que l’économie d’un aller-retour réseau complet se traduit directement en gain de latence, d’autant plus marqué que la distance physique augmente. Pour ce site dont une part croissante du trafic provenait d’Amérique du Nord et d’Asie, ce gain touchait directement une portion significative et grandissante des visiteurs.
Ce que ce test ne couvre pas
Cette mesure porte exclusivement sur le temps d’établissement de la connexion sécurisée elle-même, sans comparer les suites de chiffrement disponibles ni le choix du certificat, qui reste identique dans les deux configurations. HSTS, qui influence la façon dont le navigateur décide de passer en HTTPS dès la première visite, suit une logique de configuration distincte non traitée ici.
En résumé
TLS 1.3 n’est pas qu’une amélioration théorique : sur un site recevant un trafic international, le gain de latence de connexion mesuré ici atteint un facteur proche de deux, particulièrement visible pour les visiteurs les plus éloignés géographiquement du serveur. L’activation, quand le serveur et Certbot le permettent déjà, ne demande qu’une ligne de configuration, sans impact sur le certificat existant.
