On a passé deux heures à croire qu’un refactoring Zustand avait introduit une régression d’INP. Le graphique Lighthouse oscillait entre 140 ms et 420 ms sans aucune modification de code. Le coupable ? Un four à micro-ondes à quatre mètres du routeur.
Un WiFi instable ne se contente pas de ralentir Netflix. Il injecte des artefacts dans les métriques Core Web Vitals, et n’importe quel objet du quotidien peut saboter ton banc de test sans prévenir.
Le WiFi, variable oubliée du diagnostic Core Web Vitals
La plupart des guides d’optimisation Core Web Vitals s’arrêtent au code, à l’élimination des ressources bloquantes ou au lazy-loading. Mais les métriques de lab sont capturées sur ta machine, via ta connexion locale. Un paquet TCP retardé de 300 ms à cause d’une interférence, et c’est le First Contentful Paint qui bouge, le LCP qui décale, et l’INP qui explose si un script attend une réponse réseau.
Google Chrome enregistre l’INP à partir de l’événement utilisateur jusqu’au prochain affichage visuel. Si le thread principal est libre mais que le réseau accuse un délai anormal avant la confirmation d’une interaction, l’INP enregistré grimpe mécaniquement. La même page, testée sur Ethernet, retrouve des valeurs normales. Le piège est redoutable : tu corriges des lignes de JS alors que la racine du mal est un miroir mal placé.
Les objets parasites : un inventaire rapide
Miroirs, vitres épaisses, radiateurs en fonte, murs porteurs en béton armé. Câbles électriques mal blindés courant le long du routeur. Lave-linge en cycle essorage. Et le champion toutes catégories, le four à micro-ondes, qui émet pile dans la bande 2,4 GHz. Tous ces éléments absorbent ou réfléchissent les ondes, augmentant le taux d’erreur par paquet et la latence. Pas besoin d’une thèse en électromagnétisme pour comprendre qu’un routeur placé derrière un aquarium ou collé à une plaque de métal va générer des artefacts de mesure en rafale.
Ce jour où le micro-ondes a fait exploser l’INP
Notre app de test tournait sur un Next.js 14 avec un état global géré par Zustand. Rien de lourd. Pourtant, le monitoring local affichait un INP dégradé, parfois jusqu’à 420 ms, sur une simple liste paginée. On a d’abord suspecté un effet de bord dans le recalcul de sélecteurs, on a révisé la config du middleware de cache, on a même ouvert les suggestions de Claude Code pour traquer une regression silencieuse. Rien.
Le schéma intrigant, c’était l’horaire. Les dégradations apparaissaient vers 12h15, puis disparaissaient vers 13h. On a fini par corréler les spikes INP avec l’utilisation du micro-ondes de l’open space. Un test simple a suffi : on lance la measure réseau avec Web Vitals, on demande à un collègue de réchauffer son plat, et en moins de trente secondes l’INP passe de 135 ms à 398 ms. Micro-ondes éteint, retour à la normale. Le code ne portait aucune responsabilité.
Sur un poste en 2,4 GHz, n’importe quel appareil domestique peut se transformer en outil de torture pour tes métriques. Les paquets perdus et les retransmissions augmentent le jitter, et ce jitter est interprété par l’API PerformanceObserver comme un délai d’interaction attribuable à la page. Le navigateur ne distingue pas une lenteur réseau d’une lenteur de traitement JavaScript lorsqu’il calcule l’INP en laboratoire.
Isoler le banc de test : Ethernet, 5GHz, et discipline
Avant de remettre en cause l’architecture de gestion d’état, câble Ethernet. À défaut, bande 5 GHz et périphériques bruyants coupés. Compare une trace réseau Ethernet à une trace WiFi : si le TTFB ou la résolution DNS bougent de plus de 30 ms, le problème n’est pas dans ton serveur.
LCP et TTFB : quand le réseau simule un serveur lent
Le LCP, c’est le temps jusqu’au rendu du plus grand élément visible. Sur une page avec une image hero, le chargement de cette image dépend du réseau. Si des paquets TCP sont perdus à cause d’un mur en béton armé ou d’un micro-ondes, le LCP va mécaniquement grimper. Même mécanisme pour le TTFB : une requête de document qui met 500 ms au lieu de 80 ms à cause d’une couche physique dégradée peut te faire croire que ton serveur est à la ramasse. J’ai vu des écarts de 600 ms de TTFB enregistrés en local, alors que le serveur répondait en 85 ms mesuré via un ping depuis un VPS.
La conséquence directe : les données de la Search Console (CrUX) ne montrent rien, parce qu’elles agrègent des sessions réelles sur des connexions variées. Mais tes tests locaux t’envoient sur une fausse piste. Tu passes des heures à optimiser des polices ou à réduire le bundle JS, alors que le seul geste utile serait de déplacer le routeur de cinquante centimètres.
Questions fréquentes
Le passage en 5 GHz règle-t-il tout ?
Non. Le 5 GHz est moins sujet aux interférences des micro-ondes et de nombreux appareils domestiques, mais il porte moins loin et traverse plus difficilement les murs. Si ton poste de test est séparé du routeur par deux pièces, le signal peut rester trop faible pour des mesures stables. Mieux vaut un câble Ethernet dès que tu suspectes une pollution.
Les outils RUM comme CrUX sont-ils affectés par ces interférences ?
Ils le sont, mais dilués. CrUX agrège des millions de sessions d’utilisateurs réels, certains sur mobile en 4G, d’autres en fibre. Une interférence isolée n’apparaît pas dans la tendance globale. En revanche, un utilisateur qui rencontre une connexion dégradée verra effectivement son LCP ou son INP augmenter. C’est pour ça qu’un seul rapport CrUX ne suffit pas pour diagnostiquer un problème de performance reproductible.
Le WiFi 6 résout-il ces problèmes ?
Le WiFi 6 améliore la robustesse en environnement dense et réduit la latence, mais il n’élimine pas les interférences électromagnétiques. Un micro-ondes placé à proximité immédiate du routeur continuera de perturber le spectre. Le garde-fou numéro un reste le contrôle de l’environnement physique pendant les mesures.
