Que sont les connexions réseau dans la vitesse de page ?

Que sont les connexions réseau dans la vitesse de page ?

Une connexion réseau est le canal qu'un navigateur ouvre vers un serveur avant de pouvoir récupérer quoi que ce soit. L'établir prend du temps : une résolution DNS, une poignée de main TCP et, en HTTPS, une négociation TLS. Une page qui charge des fichiers depuis de nombreux serveurs différents paie ce coût plusieurs fois ; la manière dont les connexions sont ouvertes, réutilisées et partagées compte donc souvent autant que la taille des fichiers.

Ce que coûte une nouvelle connexion

La première requête vers un serveur comprend une résolution DNS, une poignée de main TCP et la négociation TLS sécurisée. Les requêtes suivantes sont plus rapides car la connexion est déjà ouverte (MDN, "Understanding latency"). Chaque étape est un aller-retour réseau : le coût augmente avec la distance entre le visiteur et le serveur. C'est pourquoi une nouvelle connexion pénalise surtout les réseaux mobiles et les visiteurs éloignés.

Exemple : une page charge ses propres fichiers, un script d'analytique, un hébergeur de polices, un réseau publicitaire et un widget de chat. Cela fait cinq origines, donc cinq résolutions DNS et cinq établissements de connexion avant l'arrivée du dernier octet, même si chaque fichier est petit.

Réutiliser les connexions

• Connexions persistantes (keep-alive). Une connexion persistante reste ouverte et sert à plusieurs requêtes, ce qui évite de refaire la poignée de main. En HTTP/1.1, la persistance est la valeur par défaut ; les connexions inactives sont fermées au bout d'un moment (MDN, "Connection management in HTTP/1.x").
• Parallélisme en HTTP/1.x. HTTP/1.x traite les requêtes l'une après l'autre sur une connexion, donc les navigateurs en ouvrent plusieurs par domaine. Le chiffre courant est de 6 connexions parallèles, que MDN présente comme typique et non comme une norme fixe.
• Multiplexage en HTTP/2. HTTP/2 permet à des requêtes parallèles de partager une connexion et compresse les en-têtes répétés. Les astuces HTTP/1 comme le domain sharding n'aident plus et peuvent nuire : mieux vaut réduire le nombre d'origines. HTTP/3 est aussi multiplexé et évite de bloquer tous les flux quand un paquet est perdu (MDN, "Evolution of HTTP").

Préchauffer les connexions

Si vous savez que la page aura besoin d'une autre origine, prévenez le navigateur tôt. <link rel="preconnect"> lance à l'avance le travail DNS, TCP et TLS, et n'aide que les requêtes cross-origin. MDN conseille de le réserver aux origines les plus critiques, car préconnecter beaucoup de tiers peut être contre-productif. Pour les origines moins prioritaires, <link rel="dns-prefetch"> n'économise que l'étape DNS. Voir le préchargement des ressources pour les indications voisines et la référence MDN sur preconnect pour la syntaxe exacte.

Autres façons de réduire le coût des connexions

• Moins d'origines. Hébergez vous-même les polices et scripts critiques et retirez les balises tierces inutiles.
• Servir depuis un point proche. Un CDN raccourcit chaque aller-retour et réduit le temps jusqu'au premier octet.
• Ne pas attendre les tiers. Chargez les scripts non critiques en chargement asynchrone pour qu'une connexion lente ne bloque pas le rendu.
• Utiliser des versions modernes de TLS et HTTP sur le serveur et le CDN.

Erreurs fréquentes

• Préconnecter une douzaine d'origines "au cas où". Chacune consomme une connexion et du temps CPU.
• Garder les réflexes HTTP/1 après le passage à HTTP/2, comme répartir les ressources sur des sous-domaines.
• Tester depuis un seul endroit. Le coût de connexion dépend de la distance : une page rapide près du serveur peut être lente ailleurs.
• Accuser la taille des fichiers alors que la cascade montre de longues barres DNS, connexion ou TLS.

Comment le mesurer

Le panneau réseau du navigateur découpe chaque requête en résolution DNS, connexion, TLS, attente et téléchargement, et montre quand des requêtes attendent une connexion (MDN, "Understanding latency"). Repérez les barres de connexion répétées vers une même origine et les nombreuses petites origines. Pour suivre l'évolution, le monitoring de vitesse de page LoadFocus lance des audits Lighthouse planifiés depuis 25 régions cloud, ce qui permet de comparer le chargement d'une même page à différentes distances. Pour une vérification rapide, le vérificateur de Core Web Vitals est gratuit. Pour vos API, le monitoring d'API décompose chaque temps de réponse en DNS, connexion TCP, premier octet et téléchargement. Si vous comparez les versions de protocole, lisez les articles du blog sur HTTP/3 et les tests de charge et les protocoles réseau pour les tests de performance. Le fond du délai lui-même est expliqué dans la latence.

Questions fréquentes

Pourquoi la première requête vers un site est-elle plus lente que les suivantes ?

La première nécessite une résolution DNS, une poignée de main TCP et une négociation TLS. Les suivantes réutilisent la connexion ouverte et sautent ces étapes.

Combien de connexions un navigateur ouvre-t-il vers un serveur ?

En HTTP/1.x, les navigateurs ouvrent couramment 6 connexions parallèles par domaine. En HTTP/2 et HTTP/3, les requêtes partagent une connexion grâce au multiplexage, et une seule suffit généralement.

Que fait preconnect ?

Il demande au navigateur de lancer le travail DNS, TCP et TLS pour une autre origine avant que la page ne la demande. Il n'aide que les requêtes vers une origine différente et doit se limiter aux plus critiques.

Une connexion plus rapide règle-t-elle une page lente ?

Pas toujours. La bande passante aide pour les gros téléchargements, mais la plupart des pages sont limitées par les allers-retours et le nombre d'origines. Réduire les connexions et la distance aide souvent plus que d'ajouter de la bande passante.

Quelle différence entre dns-prefetch et preconnect ?

dns-prefetch ne résout que le nom de domaine. preconnect ouvre aussi la connexion TCP et, en HTTPS, termine la négociation TLS : il fait gagner plus de temps, mais coûte davantage.