Un aller-retour de moins par connexion, soit environ 90 ms gagnés en 4G : c’est le gain mesuré par l’équipe technique d’un site d’actualités après activation de TLS 1.3 côté Cloudflare, sur un lectorat qui recevait une large part de son trafic depuis des terminaux mobiles hors zones bien couvertes.
Le protocole TLS, qui sécurise toute connexion HTTPS, impose un échange préalable entre le navigateur et le serveur avant que la moindre donnée applicative ne puisse circuler : c’est le handshake. Ce billet compare la latence mesurée en TLS 1.2 et en TLS 1.3 sur ce site, activé côté Cloudflare, en frontal de l’origine WordPress.
Pourquoi le handshake TLS pèse plus lourd en mobile
Sur une connexion filaire à faible latence, un aller-retour réseau supplémentaire coûte quelques millisecondes, presque imperceptible. Sur une connexion mobile, où la latence de base (le temps d’un aller-retour unique) peut dépasser 80 à 100 millisecondes en 4G moyenne et bien davantage en zone peu couverte, chaque aller-retour supplémentaire imposé par le protocole se traduit directement en temps d’attente perçu par le lecteur, avant même le premier octet de contenu.
TLS 1.2 impose deux allers-retours complets avant que le canal chiffré ne soit prêt à transporter la première requête HTTP : un pour l’échange des paramètres de chiffrement (ClientHello/ServerHello), un second pour la confirmation des clés. TLS 1.3, normalisé par l’IETF, réduit ce processus à un seul aller-retour dans le cas standard, et propose même un mode « 0-RTT » pour les reconnexions à un serveur déjà visité, au prix de certaines précautions de sécurité sur les requêtes rejouables.
Le protocole de mesure retenu
La comparaison a été menée avec WebPageTest, en configurant deux profils de test sur un réseau 4G simulé (profil « 4G » standard de l’outil, 170 ms de RTT, 9 Mbps de bande passante descendante), l’un pointant vers le domaine avec TLS 1.3 forcé côté Cloudflare (réglage disponible dans l’onglet SSL/TLS du tableau de bord, section « réglages en périphérie »), l’autre avec TLS 1.3 désactivé pour forcer une négociation en TLS 1.2 :
| Mesure | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Temps de handshake TLS | 312 ms | 168 ms |
| Time To First Byte | 498 ms | 412 ms |
| First Contentful Paint | 1,42 s | 1,29 s |
L’écart de handshake mesuré, environ 144 millisecondes, dépasse légèrement le gain théorique attendu d’un seul aller-retour réseau (environ 90 ms sur ce profil), l’écart supplémentaire s’expliquant probablement par les suites de chiffrement plus légères négociées par défaut en TLS 1.3 sur cette configuration Cloudflare.
Ce que Cloudflare a permis sans toucher au serveur d’origine
Le point notable de cette mesure tient dans l’endroit où l’activation s’est faite : entièrement côté Cloudflare, dans la configuration du proxy, sans modification de la pile TLS du serveur d’origine WordPress lui-même. Cloudflare termine la connexion TLS avec le visiteur au niveau de son réseau de périphérie, puis rétablit sa propre connexion (potentiellement en TLS 1.2, voire en clair sur un tunnel privé) vers le serveur d’origine. Le gain de latence mesuré profite donc à tous les visiteurs sans aucune dépendance à la version d’OpenSSL installée sur le serveur d’hébergement.
Un point de vigilance sur les anciens terminaux
TLS 1.3 reste largement supporté par les navigateurs modernes, mais quelques terminaux ou applications embarquées anciennes peuvent encore négocier exclusivement en TLS 1.2. Le réglage retenu a conservé TLS 1.2 comme repli automatique plutôt que de l’exclure, pour ne pas fermer l’accès du site à cette frange résiduelle de visiteurs.
Ce que ce test ne couvre pas
- Le renouvellement des certificats et la gestion de leur cycle de vie ne relèvent pas de ce comparatif, purement centré sur la latence de connexion.
- Le gain mesuré dépend fortement du profil réseau simulé ; sur fibre ou Wi-Fi stable, l’écart resterait probablement sous la barre du perceptible.
- Aucune régression de compatibilité navigateur n’a été observée sur les statistiques d’audience du site après activation, sur la période de suivi de quatre semaines.
Un aller-retour réseau économisé ne coûte rien à activer et ne se voit jamais dans un audit de code applicatif — seulement dans une mesure réseau dédiée.
En résumé
TLS 1.3 apporte un gain de latence mesurable, concentré sur la phase de connexion et particulièrement sensible sur les réseaux mobiles à latence élevée. Son activation côté Cloudflare ne demande aucune intervention sur le serveur d’origine et ne présente, sur ce site, aucun effet de bord observé sur la compatibilité des visiteurs.
