Measuring input latency in the browser

Close view of a computer keyboard with pale keycaps. — Fig. 1. A keyboard used while timing keydown-to-paint in a local prototype.

Card-game prototypes feel late when the painted highlight trails the key that triggered it. This entry logs a small measurement method I used on a local Durak table, not a formal benchmark.

The method is: stamp performance.now() in the keydown handler, then stamp it again inside a requestAnimationFrame callback after the DOM change that represents the play (a selected card gaining a class, for example). The difference is not "true" input lag. It excludes the operating system's keyboard delay and the display's pixel response. It does include the time your own script and the browser's style and paint work take after the event arrives in JavaScript. That is the part you can change.

I ran thirty keypresses on an otherwise idle page, discarded the first, and looked at the median. On this machine the median sat around a single frame at 60 Hz when the handler only toggled a class. Adding a full re-render of the table on every key (building new DOM for every card) pushed the median over two frames. That was enough to decide that the table should patch the one card that moved, rather than redraw the hand from scratch.

Two cautions. First, do not average these figures across machines and call the result a fact about "the browser." Second, alert() and heavy console.log in the handler will ruin the measurement. Keep the path you time as close as possible to the path a player will actually use.