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.

Schéma chronomètre montrant les étapes du délai d'input entre un clic de souris et la réponse d'un jeu navigateur
Entre ton clic et le pixel, un clic navigateur passe par plus de mains que tu ne le crois.

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 :

ÉtapeCoût typiqueNotes
Switch souris + debounce1-4 msLes switchs optiques sont les plus rapides ; voir notre guide du debounce souris
Polling USB / sans fil1-8 ms1 ms à 1000 Hz de polling ; jusqu'à 8 ms à 125 Hz
Dispatch des événements OS~1 msGénéralement peu coûteux, sauf si le système est chargé
Dispatch des événements navigateur1-10 ms+Hit-testing, thread principal JS, extensions
Attente requestAnimationFrame0-16,7 msJusqu'à une frame entière à 60 Hz
Compositeur + rendu2-8 msC'est là que l'accélération matérielle compte
Scan-out écran + réponse2-17 msRafraî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 :

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 :

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 navigateur

Questions 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.

Menu