On a commencé à le remarquer pendant la première grande vague de remote, mais en 2026, c’est devenu structurel : un site qui passe tous les audits internes, toutes les CI, Lighthouse 100/100 sur le laptop du lead dev, et qui pourtant affiche un LCP à 4,8 secondes dans la Search Console. Le coupable n’était pas une régression du bundle, ni une dérive du cache CDN. C’était la box Freebox de Kevin, combinée à son VPN entreprise et à une extension de visio qui modifiait le DOM en arrière-plan.
Si vous managez une équipe distribuée, le télétravail a introduit des variables que les outils de mesure côté serveur ou en synthétique ne capturent pas. Voilà les six points précis où la machine se grippe, et comment on les a corrigés sur des vrais projets.
Le réseau domestique, cette variable que votre RUM ignore encore
Un TTFB de 180 ms depuis un datacenter AWS ne signifie rien quand votre utilisateur réel est derrière une box 4G avec 40 % de perte de paquets un mardi à 10h. On a instrumenté un site e-commerce avec un RUM (Real User Monitoring) qui collectait les métriques via l’API PerformanceObserver. Sur 30 % des sessions marquées « télétravail », le temps de résolution DNS dépassait les 600 ms, et la latence TCP ajoutait 200 ms supplémentaires par rapport aux sessions de bureau.
Le piège : les audits Lighthouse tournent en condition de laboratoire, sur un réseau simulé « Fast 3G » ou « Slow 4G » standardisé. Ces profils ne reflètent pas la réalité d’un réseau domestique où le buffer bloat étrangle le trafic TCP si quelqu’un lance un backup iCloud en arrière-plan. Pour les développeurs qui assurent le suivi de leurs optimisations Core Web Vitals, la priorité est d’ajouter des métriques réseau côté client : dnsLookupTime, tcpHandshakeTime, responseStart. Sans ça, vous attribuez au serveur une lenteur qui est en réalité dans le salon de l’utilisateur.
La parade n’est pas d’optimiser pour le pire réseau, mais d’identifier les segments où la latence est anormale et de déclencher une stratégie de cache agressive sur ces sessions : stale-while-revalidate côté CDN, prefetch des ressources critiques dès l’intention de navigation, et un fetchpriority="high" conditionnel sur l’image LCP. On a aussi ajouté une couche de log dans le RUM qui flag les sessions avec plus de 500 ms de latence cumulée sur le connectionStart. Ça a permis d’exclure ces données des moyennes de performance et d’ajuster les budgets de performance par profil réseau.
Le VPN d’entreprise, un middleware qui casse le TTFB sans laisser de trace
Le VPN, c’est un middleware réseau que tout le monde subit et que personne n’audite. Il ajoute un saut supplémentaire dans la résolution des routes, parfois un chiffrement qui double la charge CPU sur le terminal de télétravail, et il impose ses propres serveurs DNS. On a diagnostiqué un site vitrine dont le TTFB passait de 190 ms à 1,2 s dès que l’utilisateur activait le VPN de son entreprise. La cause n’était pas le site, mais le DNS du VPN qui redirigeait les requêtes vers un résolveur saturé, ajoutant 800 ms de latence.
Pire : certains VPN modifient les en-têtes HTTP, compressent le trafic avec un algorithme agressif qui altère le Content-Encoding négocié, ou injectent des certificats auto-signés pour inspecter le HTTPS. Résultat : vous croyez servir du Brotli, le client reçoit du Gzip de piètre qualité, et vos mesures en RUM montrent un encodedBodySize incohérent. Si vous ne loguez pas le transferSize et le decodedBodySize séparément dans votre RUM, vous passez à côté.
On a contourné une partie du problème en forçant la négociation TLS 1.3 avec early_data et en activant le 0-RTT côté CDN pour les connexions déjà établies. Mais la vraie correction a été de faire reconnaître par l’IT de l’entreprise cliente que les règles de proxy devaient exclure les domaines du site analysé. Quelques semaines de négociation, et le TTFB médian de ce site est revenu à 320 ms. La leçon : le VPN n’est pas transparent, et vos audits doivent inclure un test systématique avec une connexion VPN représentative.
Les outils de collaboration qui squattent le thread principal
Slack, Teams, Notion, les extensions de visio : quand votre navigateur de travail est aussi celui qui héberge l’application que vous développez, le thread principal devient une zone de combat. On a vu un INP à 480 ms sur un site en React, stable en labo, mais qui s’effondrait dans le RUM. Après une session de debug à distance avec un collègue, on a identifié le coupable : l’extension Chrome « Microsoft Teams Meeting » injectait un script de détection de présence dans chaque onglet, et ce script exécutait une boucle requestAnimationFrame qui retardait le first input delay.
L’INP mesure la latence des interactions de l’utilisateur. Si une extension monopolise le thread principal pendant 60 ms toutes les 200 ms pour checker une liste de participants, le navigateur ne traite pas le clic sur « Ajouter au panier » dans la même frame. Les audits classiques ne le verront jamais parce que les extensions sont absentes des profils de test vierges. En télétravail, la politique IT impose souvent une suite d’outils. Si vous ne capturez pas la liste des extensions actives via une API en entreprise, vous êtes aveugle.
Notre solution a été d’ajouter un petit script de détection dans notre RUM qui enregistre la présence de navigator.mediaDevices et de certains objets globaux injectés par les extensions, puis de corréler ces données avec l’INP. On a aussi documenté pour les équipes le principe de séparer le navigateur de dev/test du navigateur de communication. Un simple profil Chrome dédié, sans extensions, change la donne. Et pour les choix d’IDE où l’on code, la même logique s’applique : mieux vaut un environnement cloisonné que l’extension marketplace qui ralentit tout.
L’inflation silencieuse du bundle due aux versions locales divergentes
En télétravail, chaque développeur a sa propre machine, sa propre version de Node, ses propres scripts de build non standardisés. Ça crée un écosystème où le bundle de production peut varier subtilement selon la configuration locale. On a détecté un jour que le fichier JS principal d’une app Next.js était 18 % plus lourd que la version de référence. La cause : un développeur utilisait une version locale de Babel avec un plugin de polyfill qui dupliquait les async/await helpers, alors que le browserslist de l’équipe excluait déjà les navigateurs non concernés.
Ce genre de dérive ne se voit pas dans la CI si le build n’est pas reproductible à l’octet près. Le télétravail amplifie ce phénomène parce que les machines ne sont plus homogènes comme dans un openspace. Pour contrer ça, il faut imposer un hash du lockfile dans la CI et vérifier que le bundle produit est identique bit à bit. On a ajouté un step qui compare le checksum SHA256 du bundle final avec celui de la branche principale. Si ça diverge, le déploiement est bloqué.
Pour réduire structurellement le coût des polyfills, on a aussi basculé sur une approche conditionnelle avec <script type="module"> et <script nomodule> (quand le support le justifie encore). Un bon exemple : en adoptant un state management avec Zustand et un bundling par routes, on a retiré 12 Ko de code mort qui s’étaient glissés dans le chunk commun. L’audit de bundle doit être routinier, pas anecdotique, surtout quand l’équipe est éclatée.
La fragmentation des données de performance sans RUM unifié
Quand l’équipe est en remote, les rapports de performance viennent de sources éparpillées : la Search Console, un Lighthouse CI legacy, un outil de synthétique qui ne tourne plus depuis trois mois, le ressenti de quelqu’un « sur sa machine » dans un canal Slack. Ce patchwork empêche de corréler un pic de LCP avec une modification de code. Sans RUM unifié, la performance en télétravail est une opinion, pas une mesure.
On a mis en place un pipeline unique : le RUM ingère les métriques via l’API PerformanceObserver et les envoie à une base centralisée avec des tags de session, de géolocalisation et de type de réseau. Les données synthétiques viennent alimenter un tableau de bord à côté, mais ne remplacent jamais le RUM. La règle est simple : toute alerte de performance déclenchée par la Search Console doit être vérifiée dans le RUM avant qu’un ticket soit ouvert. Sur un projet e-commerce, ça a évité une escalade urgente un vendredi soir parce que le LCP moyen avait bondi de 300 ms le temps d’un week-end de soldes ; en réalité, c’était une augmentation du trafic mobile sur réseau lent, prévisible et déjà documentée.
La documentation des optims : ce que le dev du soir a fait dans son coin
On termine par le cas le plus insidieux : un développeur en télétravail ajoute un « petit hack » (un defer déplacé, un preload ajouté manuellement, un fetchpriority bidouillé dans le Head) pour régler un souci de performance qu’il a observé sur sa branche. Ça passe la code review sans que personne ne mesure l’impact global, et la ligne reste en production sans documentation. Trois sprints plus tard, un autre dev enlève ce preload pensant qu’il est redondant, et le LCP replonge.
La seule parade, c’est une discipline de documentation des décisions de performance dans le code même : des commentaires qui expliquent le « pourquoi », pas le « quoi » ; des tests de non-régression sur les valeurs de CWV, pas seulement sur le rendu visuel ; et une revue obligatoire de la PR par quelqu’un qui compare le bundle avant et après. On a instauré un template de PR qui inclut une section « Impact performance mesuré » avec les chiffres du LCP, de l’INP et du TTFB en préprod. Sans ce champ, la PR ne peut pas être mergée. Ce n’est pas une contrainte de plus : c’est ce qui nous a évité de rejouer en boucle les mêmes erreurs.
Questions fréquentes
Le télétravail a-t-il un impact direct sur le référencement via les Core Web Vitals ? Indirectement, oui. Si une part significative de vos utilisateurs est en remote avec une latence plus élevée, les métriques de terrain agrégées dans le Chrome UX Report peuvent se dégrader, ce qui affecte le classement sur les signaux de page experience. Mais ce n’est pas le télétravail en lui-même que Google pénalise, c’est la moyenne des métriques réelles.
Faut-il interdire les VPN pour améliorer le TTFB ? Interdire n’est pas crédible en entreprise. La solution est d’auditer la configuration du VPN sur le périmètre de votre site, de négocier des exclusions de routage pour les domaines statiques critiques, et de mesurer l’effet du VPN via le RUM. Vous pouvez aussi servir les assets les plus lourds d’un CDN avec un domaine dédié hors VPN.
Comment tester son site dans des conditions réseau de télétravail sans déployer un RUM ? Utilisez Chrome DevTools en mode Network Throttling personnalisé, ajoutez une latence et une perte de paquets réalistes (ex. : 150 ms de latence, 2 % de perte), et installez les extensions IT standard de l’entreprise cible dans le profil de test. Ce n’est pas parfait, mais c’est plus proche de la réalité qu’un profil Fast 3G standard.
