On a tous déjà entendu un dev front s’arracher les cheveux sur un LCP à 5 secondes sur sa propre machine, alors que le site tourne sur un CDN à 100 ms et que sa fibre affiche 1 Gbps. Le réflexe : accuser le bundle JS, le render-blocking, le serveur. Parfois, c’est juste. Parfois, non. Le vrai problème vient d’un étage que personne n’a pensé à inspecter : la connexion elle-même, et plus précisément ce qui se passe entre la box et le navigateur. Pas le débit. La mécanique.
J’ai perdu une après-midi sur un cas exactement comme ça il y a trois mois, sur un side-project Next.js déployé chez Vercel. Le Lighthouse local me sortait un LCP à 6,2 s, pendant que le collègue branché en Ethernet depuis la même box obtenait 1,8 s. Même page, même build, même serveur. Seule différence : la chaîne réseau locale. C’est ce jour-là que j’ai compris que la vitesse d’Internet, telle que vendue par les FAI, est un miroir déformant.
La bande passante n’est pas la vitesse
Les offres commerciales nous matraquent de chiffres : 300 Mbps, 1 Gbps, 8 Gbps. C’est de la capacité, pas de la vitesse. Une voiture de 500 chevaux dans un embouteillage ne roule pas plus vite qu’une citadine. La métrique qui compte pour un chargement de page, c’est le temps que met le premier paquet à arriver, la régularité de l’aller-retour et ce qui se passe quand la connexion est saturée.
Sur une page web classique, la différence entre un débit de 100 Mbps et 1 Gbps est quasi invisible au chargement. Un fichier CSS de 20 Ko, une réponse d’API de 2 Ko, un document HTML de 30 Ko : ces ressources tiennent dans un paquet TCP. Leur temps de transfert dépend du path delay, pas du tuyau. Ce qui allonge la perception, c’est la succession d’aller-retours : DNS, TLS, HTTP, puis le téléchargement des ressources critiques. Chaque étape ajoute sa propre latence, et c’est la somme qui fait mal.
Quand un utilisateur dit « ma connexion est lente », il confond presque toujours débit et latence. La confusion arrange bien les fournisseurs, qui peuvent vendre du Mbps en oubliant de te parler du bufferbloat.
Bufferbloat : le piège qui transforme une fibre en ADSL
Là où les réseaux domestiques se vautrent, c’est sur la gestion des files d’attente. Imagine : tu lances une grosse synchro (backup, upload d’une vidéo, mise à jour Steam). Ta connexion est saturée en émission. Pendant ce temps, la requête de ton navigateur pour charger une page passe derrière. Elle attend son tour dans une file d’attente colossale à l’intérieur de ta propre box. C’est le bufferbloat.
Le résultat, mesuré avec l’outil de l’Internet Society ou le test de bufferbloat de Waveform, est sans appel : une latence qui passe de 10 ms à 500 ms, voire plus, sous charge. Sur mon routeur d’origine, un upload saturé transformait mon ping vers 8.8.8.8 en une seconde pleine. Le LCP suivait la même courbe.
⚠️ Attention : Le bufferbloat n’est pas un défaut du FAI distant. Il se produit dans ta box, sur ton routeur, parfois même dans le pilote Wi-Fi. Tu peux avoir la meilleure fibre de France et un bufferbloat qui tue chaque chargement de page dès qu’un autre appareil est actif.
La correction est technique mais accessible : un routeur qui implémente un algorithme de gestion active des files (AQM), comme fq_codel ou CAKE. OpenWrt et certaines box récentes le proposent nativement. L’impact sur le LCP d’une page e-commerce avec 50 ressources peut atteindre 2 à 3 secondes en moins. Sans toucher une ligne de code. Juste en vidant les files d’attente au bon moment.
Wi-Fi versus Ethernet : l’INP se joue dans les airs
L’INP (Interaction to Next Paint) mesure le délai entre une interaction utilisateur et le prochain rendu visuel. Il est sensible à la réactivité de la connexion, pas seulement au JS. Un Wi-Fi congestionné injecte une latence irrégulière qui retarde l’arrivée des données d’une requête asynchrone, et donc la mise à jour du DOM en réponse à un clic.
Un banc d’essai maison, sur un site d’optimisation des Core Web Vitals, nous a montré un écart de 35 ms de temps de réponse réseau entre une liaison Ethernet directe et un Wi-Fi 5 saturé par deux autres appareils en streaming. Sur une interaction qui déclenche un appel API et un re-rendu, ces 35 ms transforment un INP de 150 ms en 210 ms. Le seuil « needs improvement » est à 200 ms. On passe au-dessus sans avoir modifié une seule ligne de JavaScript.
💡 Conseil : Avant de réécrire ton state manager en Zustand pour gratter 10 ms, branche un câble et vérifie si ton INP en labo ne vient pas du canal radio.
Le Wi-Fi 6 et 6E réduisent le problème, mais ne le suppriment pas. La bande 5 GHz est moins encombrée, mais sa portée est plus courte. La bande 2,4 GHz traverse mieux les murs, mais elle est partagée avec les micro-ondes, les objets connectés et les voisins. Le vrai test, c’est de mesurer la gigue (jitter) et la perte de paquets sur 60 secondes de ping continu, pas le débit à un instant T.
Le DNS de ton FAI, ce petit retard qu’on oublie
Chaque nouvelle page, chaque sous-domaine inconnu, chaque ressource tierce passe par une résolution DNS. Le serveur DNS par défaut de ta box est celui de ton fournisseur. Dans certains cas, il met 80 à 120 ms à répondre, contre 10 ms pour un résolveur public bien doté. Avec 5 à 10 requêtes DNS par page (domaine principal, CDN, analytics, polices), la différence cumulée peut atteindre 500 ms sur le Time to First Byte perçu.
Changer le résolveur DNS (Cloudflare, Quad9, NextDNS) n’est pas une solution magique, mais c’est un levier concret qui ne coûte rien et qui réduit la latence de la première étape pour tous les appareils du réseau. Certains navigateurs activent un pré-resolve des domaines survolés, mais ça ne couvre pas tout.
Ce que ton code ne peut pas compenser
Une page qui envoie 200 requêtes et 3 Mo de JS reste lente même sur une connexion parfaite. Mais l’inverse est vrai aussi : un site léger et bien assemblé peut rester frustrant si la couche réseau locale est malade. Ce qu’on voit dans les outils de type Lighthouse ou WebPageTest, ce n’est jamais la vitesse pure du serveur. C’est toujours la vitesse de l’aller-retour complet, depuis le navigateur.
Sur un projet Claude Code vs Cursor IDE, on avait justement comparé les environnements de dev, avec un throttling simulé en 4G. Le constat : un temps de réponse serveur à 80 ms ne changeait rien quand le réseau local ajoutait 200 ms de bufferbloat simulé. La page était lente, point. Revenir au code n’améliorait rien. Seul le paramètre réseau comptait.
C’est pour ça qu’il est dangereux de juger la performance d’un site depuis son propre poste sans contrôler ce qui se passe sur le réseau immédiat. Les développeurs qui testent en local sur un serveur de dev branché en boucle locale voient des temps irréprochables, que le vrai utilisateur n’aura jamais.
Mesurer avant de croire
Pour savoir si le problème est chez toi ou chez le site, il faut des outils qui mesurent autre chose que le débit. Un speedtest classique ne montre pas la latence sous charge. Utilise :
- Waveform Bufferbloat Test : lance une saturation montante et descendante, te donne la latence ajoutée pendant le transfert.
- PingPlotter ou
ping -i 0.2: pour visualiser les variations sur 5 minutes. - WebPageTest avec un profil réseau réaliste : tu peux simuler un bufferbloat local avec des outils comme
netemsous Linux ou un routeur configurable. - Fast.com de Netflix : il inclut une mesure de latence chargée/déchargée, plus proche des conditions réelles de streaming.
Quand tu vois un écart de LCP de plus de 1,5 seconde entre le labo et le terrain, et que le serveur répond en moins de 100 ms, c’est le réseau local qui trinque. Ne cherche pas midi à quatorze heures dans le code.
Questions fréquentes
La 5G résout-elle les problèmes de latence locale ? La 5G offre un ping radio plus faible que la 4G, mais la latence mesurée depuis un smartphone reste soumise aux aléas de la cellule, de la congestion et du bufferbloat de l’opérateur. Pour un usage web classique, la différence avec une bonne 4G est souvent marginale en chargement de page. Le bénéfice se voit surtout sur les transferts volumineux et les usages temps réel.
Un VPN peut-il améliorer la vitesse de mon Internet ? Parfois, oui, mais pour des raisons contre-intuitives. Si le VPN force un chemin mieux routé et évite un peering congestionné de votre FAI, le ping vers certains serveurs peut baisser. En revanche, il ajoute sa propre latence de chiffrement. Le test A/B est la seule règle qui tienne.
Faut-il choisir la fibre plutôt que le câble coaxial uniquement pour le débit ? Le vrai avantage de la fibre, c’est la stabilité de la latence et l’absence quasi totale de bruit électrique. Le câble coaxial partage la bande avec le quartier ; votre latence peut varier aux heures de pointe. Le débit est rarement le discriminant. Une bonne connexion câble avec un routeur anti-bufferbloat peut offrir une expérience de navigation équivalente à la fibre la plupart du temps.
