Pourquoi les jeux navigateur laguent (et comment y remédier)
Ton clic de souris atteint un jeu natif en quelques millisecondes. Dans un jeu navigateur, ce même clic fait la queue derrière l'OS, un moteur JavaScript et un compositeur avant de devenir un pixel. Voici où les navigateurs ajoutent du délai, comment mesurer ta part de ce délai, et les corrections qui font vraiment bouger le chiffre.

La chaîne d'input, du switch au pixel
Chaque clic que tu fais parcourt une chaîne de montage. Chaque étape ajoute son propre délai, et le navigateur est au milieu du chemin :
| Étape | Coût typique | Notes |
|---|---|---|
| Switch souris + debounce | 1-4 ms | Les switchs optiques sont les plus rapides ; voir notre guide du debounce souris |
| Polling USB / sans fil | 1-8 ms | 1 ms à 1000 Hz de polling ; jusqu'à 8 ms à 125 Hz |
| Dispatch des événements OS | ~1 ms | Généralement peu coûteux, sauf si le système est chargé |
| Dispatch des événements navigateur | 1-10 ms+ | Hit-testing, thread principal JS, extensions |
| Attente requestAnimationFrame | 0-16,7 ms | Jusqu'à une frame entière à 60 Hz |
| Compositeur + rendu | 2-8 ms | C'est là que l'accélération matérielle compte |
| Scan-out écran + réponse | 2-17 ms | Rafraîchissement de la dalle et temps de réponse des pixels |
Additionne tout et un jeu navigateur sur une config 60 Hz peut afficher 40 à 60 ms de délai clic-photon avant même que la logique du jeu fasse quoi que ce soit. Un jeu natif avec raw input zappe carrément plusieurs de ces étapes. Cet écart, c'est exactement pourquoi la même souris peut paraître précise sur le bureau et molle dans un onglet de navigateur.
La taxe d'affichage : 16,7 ms avant de voir quoi que ce soit
Voici le fait à ressortir en LAN : à 60 Hz, l'écran à lui seul peut ajouter jusqu'à 16,7 ms de délai — une frame entière — avant que ton clic devienne visible. Cette seule étape coûte plus cher que tout le pipeline d'une souris gaming : un bon switch optique déclenche en environ 1 ms et un polling à 1000 Hz ajoute 1 ms de plus.
Les gens dépensent volontiers 150 € pour grappiller 2 ms sur une souris tout en laissant 16,7 ms sur la table dans les réglages de leur écran. Passe à 144 Hz et la taxe frame tombe à 6,9 ms ; à 240 Hz, elle est de 4,2 ms. Si ton écran en est capable mais est mal configuré — une situation déprimante de banalité — notre guide pour vérifier ton vrai taux de rafraîchissement prend deux minutes.
Rien de tout ça ne veut dire que la souris ne compte pas. Ça veut dire que la latence est un budget dépensé sur toute la chaîne, et que les plus grosses lignes de dépense sont rarement celles qui ont le meilleur marketing.
Mesurer la part de délai de ton navigateur
Tu ne peux pas corriger ce que tu ne peux pas isoler. Notre test de latence d'input navigateur mesure le segment que le navigateur contrôle : il compare l'horodatage de chaque événement d'input avec l'horloge haute résolution au moment où le gestionnaire d'événement s'exécute vraiment, puis affiche une médiane et un 95e percentile sur une série de clics, taps ou frappes clavier.
Lis les résultats comme ceci : la médiane est ton délai de dispatch typique — sur un navigateur de bureau sain, généralement de quelques millisecondes à un chiffre. Le p95, c'est la queue de distribution — à quel point ça dégénère quand le thread principal hoquette. Une médiane de 2 ms avec un p95 de 30 ms signifie que ton navigateur va bien en moyenne mais se fige régulièrement, ce qui dans un jeu donne l'impression d'inputs avalés au hasard.
Sois honnête sur ce que ça mesure : le délai de dispatch à la frontière des événements du navigateur. Ça n'inclut ni le switch de ta souris, ni le transport USB, ni le scan-out de l'écran — la section guide de l'outil le dit elle-même. Pour le tableau complet de bout en bout, déroule la checklist input lag quand tu as fini ici.
Pourquoi la même souris paraît pire dans un navigateur
Les jeux natifs lisent l'input au plus près du métal — des API raw input qui récupèrent les données souris sans cérémonie. Les navigateurs prennent le chemin des écoliers. L'OS donne l'événement au navigateur, le navigateur décide quel élément se trouve sous le curseur (hit-testing de tout le DOM), le transmet à JavaScript sur le thread principal, et c'est seulement là que ton code de jeu peut réagir. Si le thread principal est occupé à exécuter un script de pub, ton clic fait la queue.
Trois amplificateurs spécifiques au navigateur :
- Thread principal saturé : les onglets lourds, les pubs vidéo et les scripts de page douteux partagent tous le thread sur lequel ton jeu tourne. Un seul onglet en arrière-plan qui joue une vidéo en sourdine peut ajouter du jitter visible à chaque input.
- Extensions : chaque extension qui écoute les événements de la page ajoute du travail au dispatch. Les correcteurs grammaticaux et les injecteurs de coupons sont des récidivistes.
- Coalescence d'événements : les navigateurs regroupent les événements de mouvement de pointeur haute fréquence et les livrent par paquets. Parfait pour la fluidité sur le papier ; en pratique, tes données de visée arrivent par grumeaux.
C'est aussi pour ça que le clavier peut paraître spongieux dans le navigateur alors que le même clavier est instantané dans une appli native — un phénomène qu'on décortique dans mon clavier lag ? et dans l'analyse plus profonde de la latence clavier.
Les solutions qui marchent vraiment
Par ordre d'impact approximatif :
- Active l'accélération matérielle. Dans Chrome/Edge : Paramètres → Système → « Utiliser l'accélération graphique lorsqu'elle est disponible ». Délester la composition sur le GPU vaut plusieurs millisecondes et tue la plupart des bizarreries de frame pacing. Elle devrait être activée par défaut ; les politiques d'entreprise et les vieux blocages de pilotes sont les raisons habituelles du contraire.
- Fais tourner ton écran à son vrai taux de rafraîchissement. La moitié des signalements de « navigateur qui lag » qu'on voit sont des dalles 144 Hz bloquées à 60 Hz. Vérifie les frames réellement affichées, pas seulement le réglage Windows.
- Ferme les onglets en arrière-plan et désactive les extensions. Surtout tout ce qui joue des médias ou injecte des scripts de page. Teste avec un profil de navigateur propre — si le p95 s'effondre, une extension mangeait tes inputs.
- Passe en plein écran. Les fenêtres plein écran bénéficient d'un chemin de composition plus direct dans la plupart des navigateurs, grappillant quelques millisecondes et supprimant le surcoût du gestionnaire de fenêtres du bureau.
- Préfère les périphériques filaires au Bluetooth. Le Bluetooth ajoute environ 10 à 20 ms et des blocages occasionnels de retransmission par-dessus tout le reste. Les dongles 2,4 GHz et le simple USB sont nettement plus précis.
- Utilise le pointer lock quand le jeu le propose. Le pointer lock donne aux jeux navigateur des deltas souris quasi bruts, en contournant le hit-testing du curseur pour le mouvement.
Applique-les une par une et relance le test de latence après chaque changement. Voir ton propre p95 passer de 25 ms à 6 ms est plus convaincant que n'importe quel guide de réglages.
Vsync et frame pacing, en un paragraphe
Le rendu navigateur est vsyncé : les frames sont présentées au rythme du rafraîchissement de ton écran. C'est bien — ça empêche le tearing — mais ça signifie que ton jeu ne peut se mettre à jour qu'aux frontières de frames, et toute frame qui rate son échéance attend une frame entière de plus. À 60 Hz, une échéance ratée coûte 16,7 ms ; à 240 Hz, le même raté coûte 4,2 ms. Un frame pacing irrégulier, c'est pourquoi un jeu navigateur peut afficher « 60 FPS » et paraître quand même saccadé : les frames sont toutes là, elles arrivent juste à des moments irréguliers. Le taux de rafraîchissement élevé est le remède le moins cher, parce qu'il réduit la taille de chaque erreur possible.
Quand ce n'est pas le navigateur
Si tu as tout fait ci-dessus et que les jeux semblent toujours bizarres, le goulot d'étranglement est ailleurs dans la chaîne. Les suspects habituels hors navigateur : une TV au lieu d'un écran (le mode jeu désactivé peut ajouter 30 à 80 ms), un clavier ou une souris Bluetooth, un écran toujours à 60 Hz, une forte charge système d'une autre appli, ou — dans les jeux en ligne — la simple latence réseau, qui est un problème différent déguisé en même costume. Un ping de 20 ms n'est pas de l'input lag, mais tes mains ne peuvent pas faire la différence ; notre article sur le temps de réaction moyen explique pourquoi 20 ms est pile à la limite de la perception humaine.
Traite tout le système méthodiquement avec la checklist input lag : mesure chaque étape, change une chose, remesure. La chasse à la latence n'est frustrante que quand tu devines.
En résumé
Les jeux navigateur laguent parce qu'un clic navigateur voyage plus loin qu'un clic natif — à travers le hit-testing, le thread principal JavaScript, un compositeur vsyncé et enfin l'écran. Les plus gros gains sont ennuyeux et gratuits : accélération matérielle activée, taux de rafraîchissement bien réglé, onglets en arrière-plan et extensions tués, plein écran activé, Bluetooth désactivé. Mesure le délai de dispatch de ton navigateur, corrige les étapes que tu contrôles, et c'est seulement après que tu peux accuser le jeu. La plupart des « jeux navigateur qui laguent » sont en fait des setups navigateur qui laguent.
Prêt à tester votre propre matériel ?
Test de latence d'input navigateurQuestions fréquentes
Pourquoi les jeux navigateur laguent-ils par rapport aux vrais jeux ?
Les jeux natifs lisent l'input via des API bas niveau avec un traitement minimal. Les navigateurs font passer chaque input par le dispatch de l'OS, le hit-testing du DOM et le thread principal JavaScript avant que le code du jeu le voie, puis présentent les frames vsyncées à ton écran. Un onglet chargé ou un écran 60 Hz ajoute facilement 20 à 40 ms qu'un jeu natif ne paie jamais.
Comment réduire l'input lag dans les jeux navigateur ?
Les cinq corrections à plus fort impact : active l'accélération matérielle, règle ton écran sur son vrai taux de rafraîchissement, ferme les onglets en arrière-plan et les extensions, joue en plein écran, et utilise des périphériques filaires ou 2,4 GHz au lieu du Bluetooth. Mesure le changement avec le test de latence d'input navigateur après chaque étape.
Le Bluetooth ajoute-t-il de l'input lag ?
Oui — typiquement 10 à 20 ms par-dessus tout le reste, plus des blocages occasionnels quand les paquets sont retransmis. Le Bluetooth convient pour taper et le travail de bureau, mais pour les jeux, un dongle sans fil 2,4 GHz ou une connexion filaire est mesurablement plus précis.
L'input lag navigateur, c'est la même chose que le ping ?
Non. L'input lag est le délai entre ton action physique et la réaction locale du jeu ; le ping est l'aller-retour réseau vers un serveur. Ils se ressemblent dans la main — tu cliques et quelque chose arrive en retard — c'est pourquoi on les confond. Le test de latence mesure le délai de dispatch local ; le ping nécessite un test réseau.
Un écran 144 Hz réduit-il l'input lag dans un navigateur ?
Oui, de deux façons. L'attente de frame vsyncée passe de jusqu'à 16,7 ms à 60 Hz à 6,9 ms à 144 Hz, et toute échéance de frame ratée coûte 10 ms de moins. Tout ce qui est en amont — souris, OS, dispatch navigateur — reste identique, mais la taxe côté écran rétrécit immédiatement.