DEV Community: Umairaalam

Can JavaScript Measure Mouse Polling Rate?

Umairaalam — Thu, 17 Sep 2026 14:08:09 +0000

A gaming mouse may be configured to 1000Hz, 4000Hz, or even 8000Hz, but open a browser-based test and you may not always see exactly the same number.

Why?

The obvious assumption is that if a mouse reports at 1000Hz, JavaScript should receive 1000 mouse events every second.

That sounds reasonable, but browsers do not work quite that directly.

JavaScript can measure mouse movement timing, but it does not directly read the USB polling rate from your mouse hardware. What it sees is the stream of pointer events that reaches the browser after passing through the operating system and browser event-processing layers.

Understanding that difference is important if you are building a mouse polling rate test, an input visualizer, a browser game, or any application that deals with high-frequency mouse input.

What Does Mouse Polling Rate Mean?

Mouse polling rate describes how frequently a mouse reports updated information to the computer.

For example:

Polling Rate Approximate Interval
125Hz 8ms
250Hz 4ms
500Hz 2ms
1000Hz 1ms
2000Hz 0.5ms
4000Hz 0.25ms
8000Hz 0.125ms

The relationship is simple:

pollingRate = 1000 / intervalInMilliseconds;

If two observable updates are exactly 1ms apart, that interval corresponds to roughly 1000Hz.

But the word observable matters.

A browser does not sit directly between the mouse sensor and the USB controller.

A simplified input path looks more like this:

Mouse hardware
↓
Mouse firmware
↓
USB or wireless connection
↓
Operating system
↓
Browser input processing
↓
Pointer event
↓
JavaScript

Your JavaScript code operates near the end of this chain.

That is why a browser measurement and a hardware-configured polling rate should not automatically be treated as the same measurement.

How to Measure Mouse Polling Rate in JavaScript

The simplest approach is listening for pointer movement.

let previousTime = null;

window.addEventListener("pointermove", (event) => {
if (previousTime !== null) {
const interval = event.timeStamp - previousTime;
const hz = 1000 / interval;

console.log(`${hz.toFixed(0)} Hz`);

}

previousTime = event.timeStamp;
});

The idea is straightforward.

Every time a pointermove event arrives, we calculate the time since the previous event and convert that interval into an estimated frequency.

For example:

2ms interval → approximately 500Hz
1ms interval → approximately 1000Hz
0.5ms interval → approximately 2000Hz

But this simple implementation has a major limitation.

It measures dispatched pointermove events.

It does not prove that every hardware report generated by the mouse produced an individual JavaScript event.

Why pointermove May Show Fewer Events

`
Browsers have to balance input processing with rendering, JavaScript execution, layout work, network activity, and everything else happening on the page.

Because of that, browsers are allowed to combine multiple pointer updates into fewer dispatched events.

This is called event coalescing.

Imagine the browser receives several position updates:

Update 1
Update 2
Update 3
Update 4

Instead of executing your JavaScript listener four separate times, the browser may combine some of those updates into one dispatched pointermove event.

This reduces event-handling overhead.

The W3C Pointer Events specification explicitly allows browsers to delay and coalesce pointermove events for performance reasons.

For normal interfaces, this behavior is usually beneficial.

For mouse-frequency measurements, however, it creates an important distinction:

JavaScript callback frequency is not necessarily identical to mouse hardware report frequency.

pointermove vs pointerrawupdate

Developers working with high-frequency pointer input should also know about:

pointerrawupdate

A simple listener looks like this:

window.addEventListener("pointerrawupdate", (event) => {
console.log(event.timeStamp);
});

According to MDN, browsers may delay pointermove events for performance, while pointerrawupdate is intended to be dispatched as soon and as frequently as the browser can produce those events.

That makes pointerrawupdate interesting for applications such as:

high-frequency pointer measurement
drawing applications
low-latency dragging
input visualizers
experimental browser input tools

But the name can be misleading.

pointerrawupdate Does Not Mean Raw USB Access

Using pointerrawupdate does not give JavaScript direct access to mouse firmware or USB packets.

The operating system and browser are still involved.

The Pointer Events specification also allows pointerrawupdate events themselves to be coalesced when JavaScript cannot process every update immediately.

So this would be an unsafe conclusion:

My JavaScript received 780 pointerrawupdate callbacks, therefore my mouse hardware is running at exactly 780Hz.

A better interpretation is:

The browser exposed this pointer-event pattern during the measurement.

That distinction makes the result technically much more defensible.

getCoalescedEvents() Can Reveal More Samples

Pointer Events provides another useful API:

event.getCoalescedEvents()

When several pointer updates are merged into one event, getCoalescedEvents() can expose the individual pointer events that were combined.

MDN describes it as a way to retrieve the events that were coalesced into a single pointermove or pointerrawupdate event.

A simple example:

window.addEventListener("pointermove", (event) => {
const coalesced = event.getCoalescedEvents?.() ?? [];

if (coalesced.length) {
for (const sample of coalesced) {
console.log(sample.timeStamp);
}
} else {
console.log(event.timeStamp);
}
});

Now we can distinguish between:

JavaScript callbacks

and:

Pointer samples available inside those callbacks

Those numbers may be different.

That is particularly important when investigating high-polling-rate mice.

A Better JavaScript Mouse Polling Rate Experiment

Instead of displaying the highest Hz value immediately, collect the timing data first.

Here is a more useful starting point:

const intervals = [];
let previousTime = null;

function processSample(sample) {
const currentTime = sample.timeStamp;

if (previousTime !== null) {
const interval = currentTime - previousTime;

if (interval > 0) {
  intervals.push(interval);
}

}

previousTime = currentTime;
}

window.addEventListener("pointermove", (event) => {
const coalesced = event.getCoalescedEvents?.() ?? [];

if (coalesced.length) {
coalesced.forEach(processSample);
} else {
processSample(event);
}
});

Once enough samples have been collected, you can analyze the distribution instead of trusting one event.

For an individual sample:

const hz = 1000 / interval;

But one sample should not define the result.

Why Peak Polling Rate Can Be Misleading

Suppose your intervals look like this:

1.02ms
0.98ms
1.01ms
0.99ms
0.31ms
1.03ms

That 0.31ms interval converts to more than 3000Hz.

Does that mean your 1000Hz mouse suddenly produced a stable 3000Hz polling rate?

Not necessarily.

It could simply be an outlier caused by event scheduling, timing behavior, coalescing, or another part of the browser environment.

This is why showing only:

Peak: 3225Hz

can produce a very misleading mouse polling rate test.

A stronger measurement looks at several things together:

number of samples
average interval
median interval
consistency
minimum and maximum intervals
outliers
repeated test runs

The overall pattern is usually more informative than the largest number observed during one movement.


### Consistency Matters Too

Consider these two sets of intervals:

Test A

1.0
1.0
1.0
1.0
1.0

and:

Test B

0.4
1.6
0.6
1.4
1.0

Both can produce a similar average.

But their timing behavior is clearly different.

That is why I prefer thinking about polling-rate measurement as a distribution of observed event intervals, rather than one magical Hz number.

For developers building input tools, this also opens the door to showing useful metrics such as jitter or interval consistency instead of simply displaying a peak result.

Don't Let Your Test Affect the Measurement

There is another problem that is surprisingly easy to create yourself.

Imagine running this hundreds or thousands of times per second:

window.addEventListener("pointerrawupdate", (event) => {
result.textContent = event.timeStamp;

updateGraph();
calculateStatistics();
rebuildResults();
saveData();
});

The event handler is now performing DOM updates, calculations, graph rendering, and data processing during the measurement itself.

At sufficiently high event frequencies, the test can start interfering with the environment it is attempting to measure.

MDN specifically warns that high-frequency pointerrawupdate listeners can negatively affect page performance when the application cannot process the events quickly enough.

A cleaner architecture is:

const samples = [];

window.addEventListener("pointerrawupdate", (event) => {
samples.push(event.timeStamp);
});

Then update the interface separately:

function render() {
// Render current results here.

requestAnimationFrame(render);
}

requestAnimationFrame(render);

Now input collection and visual rendering are separated.

That makes the test easier to reason about and reduces unnecessary work inside the high-frequency event listener.

Browser Support Also Matters

You should not assume that every browser exposes the same Pointer Events features.

For pointerrawupdate, use feature detection:

const supportsRawPointer =
"onpointerrawupdate" in window;

For getCoalescedEvents():

const supportsCoalescedEvents =
typeof PointerEvent !== "undefined" &&
typeof PointerEvent.prototype.getCoalescedEvents === "function";

If an API is unavailable, your application should gracefully fall back rather than failing.

This is particularly important for a public mouse polling rate test because visitors may arrive using different browser engines, operating systems, and devices.

MDN currently marks both pointerrawupdate and getCoalescedEvents() as having limited availability rather than universal Baseline support.

Why 4000Hz and 8000Hz Mice Make This More Interesting

At 125Hz, the theoretical interval between reports is around 8ms.

At 1000Hz, it is around 1ms.

At 8000Hz:

1000 / 8000 = 0.125ms

That is an extremely short interval.

As the configured polling rate increases, factors outside the mouse itself become increasingly relevant to what JavaScript can observe.

These can include:

operating-system input handling
browser scheduling
event coalescing
CPU workload
JavaScript execution
timer precision
browser support
the implementation of the test itself

This is why seeing something below exactly 4000Hz or 8000Hz in a browser does not, by itself, prove that the mouse is defective or configured incorrectly.

The browser is an observation layer, not a hardware analyzer.

What Does a Browser Mouse Polling Rate Test Actually Measure?

This is the most useful conclusion from the experiment:

A browser-based mouse polling rate test measures the timing and frequency of pointer updates observable inside the browser.

It does not directly inspect mouse firmware.

It does not read USB reports directly.

And it should not claim that every JavaScript event corresponds one-to-one with a physical mouse report.

I use the same measurement boundary in my browser-based Mouse Polling Rate Test. The result is intended to represent browser-observed input timing, so users can test movement patterns and compare repeated runs without pretending JavaScript has direct access to the mouse's hardware reporting layer.

That is a much more useful way to interpret the result.

So, Can JavaScript Measure Mouse Polling Rate?

Yes, with an important limitation.

JavaScript can measure the timing of mouse or pointer events exposed by the browser and use those intervals to estimate an observed event frequency.

But it cannot directly verify every USB polling report generated by the hardware.

For most browser-based testing, the better question is therefore not:

“What is the exact hardware polling rate?”

It is:

“What mouse input frequency and timing can this browser observe under the current setup?”

Once that measurement boundary is clear, JavaScript becomes genuinely useful for comparing:

different polling-rate settings
browsers
wired vs wireless configurations
repeated test runs
input consistency
different systems

without overstating what the browser can actually see.

Try the Experiment Yourself

If you have a 1000Hz, 2000Hz, 4000Hz, or 8000Hz mouse, compare:

pointermove

with:

pointerrawupdate

and, where supported:

getCoalescedEvents()

I'm especially interested in one thing:

Do you see a meaningful difference between pointermove and pointerrawupdate as the configured polling rate increases?

If you test it, share your mouse polling-rate setting, browser, and what you observe. Comparing results across different systems could reveal some interesting browser behavior.

References
W3C: Pointer Events specification
MDN: pointerrawupdate event
MDN: getCoalescedEvents()

What Browser Mouse Polling Rate Tests Actually Measure

Umairaalam — Fri, 24 Jul 2026 13:13:32 +0000

A mouse may be configured for 125 Hz, 500 Hz, 1000 Hz, or higher. But when you run a polling rate test in a browser, the displayed number does not come directly from the mouse firmware or raw USB packets.

It represents the timing of mouse movement events that reached the webpage.

That distinction matters when interpreting the result.

How a Browser Test Calculates Observed Hz

A browser-based test listens for mouse movement inside an active testing area. Every accepted movement event has a timestamp.

The basic calculation is:

const intervalMs = currentTime - previousTime;
const observedHz = 1000 / intervalMs;

If two accepted events arrive 1 millisecond apart, the interval-derived result is approximately 1000 events per second.

A 2 millisecond interval produces approximately 500 events per second, while an 8 millisecond interval produces approximately 125 events per second.

The calculation is simple. However, the path an input event follows before reaching the webpage is more complicated.

The Browser Does Not Read Raw USB Reports

A mouse report passes through several stages:

The mouse sensor and firmware process movement.
The device sends data through USB, Bluetooth, or a wireless receiver.
The operating system handles the input.
The browser receives an input event.
JavaScript processes the event and updates the result.

A browser test observes the event near the end of this path. It does not normally inspect every raw USB HID report generated by the device.

This is why the result should be described as a browser-observed event rate, rather than direct certification of the mouse’s hardware polling rate.

You can run the live mouse polling rate test here:

https://pollingratetester.com/mouse-polling-rate-test/

Why the Displayed Value Changes

Even when the mouse profile remains unchanged, the result can move between attempts.

Several factors affect the event sample:

Movement speed and distance
Short pauses during the test
The pointer leaving the active area
Browser focus
Background applications
Operating-system scheduling
Browser implementation
Timer precision
Wired, Bluetooth, or 2.4 GHz connection mode

The browser may also combine multiple pointer updates into a single dispatched event. This process is known as event coalescing.

Event coalescing can reduce the number of separate events visible to ordinary JavaScript, particularly when input arrives faster than the browser chooses to dispatch it.

Because of these variables, one maximum reading should not be treated as the final answer.

Average and Maximum Values Are Not the Same

The maximum value normally comes from the shortest accepted interval in the sample.

One unusually short interval can create a high peak that the mouse does not sustain.

The average value provides better context, but it can also be reduced by pauses, slow movement, focus changes, and interrupted collection.

For a more useful comparison:

Keep the same mouse profile and DPI.
Use the same browser.
Keep the browser tab active.
Move the mouse continuously in controlled circles.
Use the same test duration.
Run at least three attempts.
Compare the average pattern before considering the maximum.

This method does not remove every browser limitation, but it reduces unnecessary variation between attempts.

What a Browser Test Is Useful For

A browser polling rate test is useful when comparing conditions on the same system.

For example, you can compare:

500 Hz and 1000 Hz profiles
Wired and wireless modes
A receiver connected through a hub and directly to the computer
Results before and after closing heavy background applications
Repeated attempts using the same browser and movement pattern

The test can show whether browser-observed event timing changes between controlled setups.

Run the test and compare repeated attempts:

https://pollingratetester.com/mouse-polling-rate-test/

What the Result Cannot Prove

A browser result cannot independently prove that:

Every raw USB report reached the operating system
A mouse sustained its advertised hardware polling rate
A USB port or wireless receiver is faulty
A high maximum value was maintained throughout the test
The complete input-to-display latency is low
A 4000 Hz or 8000 Hz profile was formally validated

Lower-level USB or HID analysis is more suitable when raw hardware verification is required.

Why the Testing Methodology Is Public

Browser tools should clearly explain what they measure and where their limits are.

A large number without measurement context can easily be misunderstood. For that reason, I published the complete testing procedure, calculation references, known limitations, and sample CSV structures in a public GitHub repository.

Review the full methodology on GitHub:

https://github.com/Umairaalam/polling-rate-tester

The repository contains:

The controlled testing procedure
Reference calculations
Known browser limitations
Mouse and keyboard sample CSV files
A data dictionary
Citation information

Permanent Zenodo Archive

The methodology package is also preserved on Zenodo with a permanent Digital Object Identifier.

View the archived release:

https://doi.org/10.5281/zenodo.21533776

The Zenodo record provides a stable citation for the methodology, sample data structure, and documented limitations.

The goal is not to make browser testing sound more precise than it is. The goal is to make the result useful by explaining exactly what the browser observed.