Un matin de release, tout est vert sur le dashboard de monitoring. Pourtant dans la Search Console, le rapport Core Web Vitals vire à l’orange sur mobile. En ouvrant les DevTools, tu vois un TTFB qui oscille entre 400 ms et 1,2 seconde sur une page statique servie derrière un CDN. Première réaction « le serveur a un souci », alors que le vrai coupable est ta propre connexion internet. Le sujet paraît éloigné du SEO technique, mais quand ta ligne fait fluctuer chaque mesure, c’est ton diagnostic qui part en vrille. On a contrôlé ça sur une ligne Orange fibre « 1 Gbps » en zone urbaine : 5 ms de latence sur un test à vide, 240 ms avec un upload saturé. De quoi fausser tous tes relevés WebPageTest si tu ne mesures pas depuis un datacenter neutre.
Le mythe du gigabit : quand ta ligne ultra-rapide masque un TTFB désastreux
Le commercial opérateur te vend du débit descendant. Le développeur front qu’on est regarde autre chose : le temps que met le premier octet à revenir quand ta ligne n’est pas au repos. Une connexion fibre 2 Gbps symétrique peut parfaitement délivrer un TTFB médiocre dès que tu ouvres un tunnel VPN, que le backup iCloud se déclenche ou que ta suite d’outils SaaS synchro en arrière-plan sature le buffer de la box.
Le phénomène s’appelle bufferbloat. Il se produit quand les mémoires tampon de ton routeur sont trop généreuses et laissent s’accumuler les paquets au lieu de les jeter tôt. Résultat : ta connexion affiche une latence ridicule à vide et une latence explosive en charge. Et c’est précisément en charge que Google enregistre les métriques de terrain des Core Web Vitals pour tes visiteurs. Si tu reproduis le même environnement de test derrière ta box mal paramétrée, tes mesures Lighthouse reflètent la latence locale, pas celle des utilisateurs réels. Quand un client te signale un LCP à 4,2 s uniquement sur les tests que tu lances toi-même depuis ton bureau, tu passes deux heures à incriminer ton cache HTTP alors que ta box est juste en train d’écraser les paquets ACK. On a vu ça sur une mission récente : le LCP « labo » était dégradé de 800 ms par rapport aux mesures de terrain, uniquement à cause du bufferbloat domestique.
Ce que personne ne te dit sur la box opérateur : bufferbloat et QoS dormante
Sortie de carton, ta Freebox ou ta Livebox applique une file de priorité pensée pour la téléphonie sur IP et la télé linéaire, pas pour tes trente onglets Chrome, ton watcher webpack et ta session Screen Sharing. L’algorithme de queue par défaut est souvent une simple FIFO qui ne sait pas différencier un paquet DNS léger d’un paquet TCP upload bourré. Résultat : même en dessous de ta bande passante théorique, la latence sous charge peut atteindre 150 à 400 ms. C’est assez pour faire passer ton TTFB de 80 ms (acceptable) à 300 ms (dégradé) et ruiner tes conclusions sur un éventuel problème de rendu côté serveur.
La bonne nouvelle, c’est qu’on peut corriger ça sans changer de ligne. Il suffit d’activer une forme de Smart Queue Management (SQM) au niveau du routeur. En pratique, beaucoup de box opérateur ne l’exposent pas, ce qui oblige à placer ton propre routeur derrière la box en mode bridge. On installe OpenWrt, on applique un qdisc fq_codel ou cake sur l’interface WAN, et hop, la latence sous charge revient à moins de 10 ms. Certains routeurs grand public récents (du type Eero Pro, IQRouter ou même des modèles ASUS avec QoS adaptative) embarquent cette discipline sans command line. Le critère de choix n’est pas le prix, c’est la présence ou non de la mention explicite « SQM » ou « bufferbloat mitigation » dans la fiche technique. Si tu veux mesurer l’effet, un test de bufferbloat sur Waveform ou dslreports te donne une note de A+ (zéro bufferbloat) à D. On cherche au minimum un B stable.
Pourquoi ta connexion secondaire 4G/5G est une assurance productivité
Un orage coupe la fibre, et voilà ta session de debug interrompue en pleine analyse d’un log serveur. Pour 15 € par mois, un forfait data 5G en dual-SIM partagée connecté à un routeur miniature (GL.iNet, Teltonika) suffit à basculer automatiquement tes sessions critiques, terminal SSH inclus. Le vrai confort, ce n’est pas le débit de secours, c’est la conservation d’une latence stable même sur réseau mobile, à condition d’activer le même SQM côté routeur pour éviter l’explosion du buffer sur des cellules saturées.
⚠️ Attention : beaucoup de routeurs 4G bon marché n’embarquent que des files FIFO. Sans SQM, votre latence mobile sous charge peut dépasser 1 seconde, rendant le backup inutilisable pour du SSH ou du partage d’écran.
Tests croisés : mesure ton TTFB réel depuis trois localisations différentes
Mesurer la latence de ta connexion depuis ton propre navigateur, c’est mesurer la longueur de ton bureau en prenant ta main comme étalon. Pour isoler le bruit local, tu as besoin de trois mesures :
- Un datacenter proche : lance une instance AWS t4g.nano en région Paris (
eu-west-3), exécute uncurl -w "@curl-format.txt" -o /dev/null -s https://ton-site.comen affichant letime_starttransfer, et compare avec letime_connect. - Un test de performance synthétique distant : WebPageTest avec la localisation « Paris » ou « Frankfurt » te donne un TTFB sans traverser ta box.
- Une mesure terrain depuis ton propre domicile, mais sans charge puis avec charge (upload saturé via
scp). L’écart entre ces deux mesures est le coût réel de ta box sur ton propre TTFB.
Sur un cas récent, on a constaté 82 ms de TTFB depuis le datacenter, 315 ms depuis le domicile en charge. La différence, c’est 233 ms purement locales, zéro incident serveur. Si tu croises ça avec les statistiques de la Search Console, tu cesses d’accuser l’hébergeur et tu t’attaques au bon maillon : ta propre infrastructure de connexion.
Si tu passes tes journées à inspecter des logs et des tests de performance dans un IDE, ces écarts de latence jouent aussi sur ta productivité. On a creusé la différence entre un terminal local et un terminal distant dans notre comparatif Claude Code vs Cursor IDE, où la latence réseau impacte directement la fluidité des suggestions.
Le VPN d’entreprise, fossoyeur de ta latence : ce que tu peux configurer
Dans une boîte avec des politiques de sécurité strictes, tout le trafic passe par le VPN, même les requêtes vers le CDN public du site que tu audites. Le résultat : un TTFB multiplié par trois parce que tes paquets traversent un tunnel vers un bureau parisien avant de ressortir sur internet. La solution n’est pas de supprimer le VPN, c’est d’activer le split tunneling pour les plages IP des services que tu testes, et que la DSI autorise le protocole WireGuard, dont la surcharge en CPU et en latence est bien inférieure à un OpenVPN mal configuré.
Quand tu négocies avec l’équipe réseau, ne demande pas « un VPN plus rapide », demande l’exclusion des domaines publics de ton monitoring et un transport WireGuard sur UDP avec MTU adapté. Présente le gain chiffré : on a observé un passage de 310 ms à 105 ms de TTFB en basculant le trafic CDN hors tunnel sur une ligne fibre Orange classique.
Checklist pour auditer ta ligne comme un réseau pro
- Exécute un test bufferbloat depuis deux services différents (dslreports/speedtest, Waveform) et note le score sous charge montante.
- Identifie le modèle exact de ta box, vérifie si elle supporte le mode bridge sans bridage logiciel du NAT (certaines box SFR brident le débit en mode bridge).
- Si ta box n’expose pas de paramètre SQM, investis dans un routeur compatible OpenWrt ou dans un modèle grand public avec QoS adaptative documentée.
- Programme un test croisé mensuel :
curldepuis ton instance cloud + WebPageTest + Search Console, pour détecter une dérive avant qu’elle n’empoisonne tes rapports. - Active la double pile IPv4/IPv6 : certains opérateurs utilisent du CGNAT en IPv4 et offrent une IPv6 publique native avec une latence inférieure de 5 à 10 ms, ce qui peut affecter les performances de ton site en rendu hybride si tu mesures depuis une IP partagée.
Ces points sont rarement mentionnés dans les guides de performance web, parce qu’ils se situent à un niveau inférieur au CDN. Pourtant, un TTFB maîtrisé commence par une couche réseau qu’on peut auditer soi-même, sans attendre que l’opérateur « optimise » quoi que ce soit. Si tu traques les Core Web Vitals au quotidien, rappelle-toi que l’optimisation ne se joue pas que dans le code, elle commence chez toi, sur l’équipement qui termine la boucle TCP.
Questions fréquentes
Ma box m’affiche une latence de 3 ms sur speedtest. Pourquoi mon TTFB est-il quand même dégradé ?
Parce qu’un speedtest mesure la latence au repos, sans congestion. Un test bufferbloat ou une session SSH active pendant un upload révèlent une latence réelle bien plus haute. Votre box laisse les buffers grossir avant que le mécanisme de contrôle de congestion TCP ne corrige le tir.
Est-ce que la 5G fixe peut remplacer la fibre pour du dev/SEO ?
Sur le débit, oui, sur la latence sous charge, pas systématiquement. Les réseaux 5G peuvent délivrer 10 ms de latence sans bufferbloat si l’antenne est proche et le routeur bien configuré, mais le jitter reste supérieur à la fibre. C’est une option décente uniquement si vous doublez avec un routeur SQM et un contrat data sans throttling.
Faut-il vraiment un routeur externe alors que ma box coûte déjà 5 € par mois ?
Oui, parce qu’une box opérateur sous-traite souvent la QoS sans vous laisser la main. Un routeur externe à 80 € sous OpenWrt vous donne le même contrôle qu’un réseau professionnel, et cet investissement évite de perdre des heures à suspecter à tort votre stack web.
