Input latency is the delay between a physical action, such as a mouse click or key press, and the moment the screen shows the result of that action. Every stage in the chain adds time, from the switch closing to the frame that finally reaches your eyes. Peripheral testing isolates the first few stages so you can compare mice and keyboards fairly, even though the full chain also includes the game and the monitor.
This guide shows how to measure that delay at home with a phone, a fixed setup and a repeatable count. Sofia Lindqvist, our Peripherals Reviewer with seven years of experience, works with a high-speed camera rig for latency measurement and a switch-force gauge. The home method below is simpler, and its numbers are estimates at the resolution of the camera, not replacements for lab-grade data. Read the method first, then the numbers, because the method sets the limits of what you can claim.
What input latency includes
A click begins with the switch. When the button is pressed, the switch contacts close, and the mouse firmware has to debounce the signal so one press registers once. The sensor or switch then reports the event over USB or a wireless link at the polling interval, and the operating system delivers it to the game. Each of these steps adds a small, sometimes variable, delay.
After the operating system hands over the input, the game engine reads it during its update loop. The engine then produces a frame that includes the result, and the graphics driver queues that frame for display. Frame queueing can add a full frame of delay under some settings, which is why frame caps and low-latency modes exist. Finally, the monitor scans the new frame onto the panel, and the panel’s response time sets how fast the pixels change.
Peripheral tests focus on the first stages: switch actuation, debounce, polling and the initial handling by Windows. Those stages are the part you can change by choosing a mouse, a keyboard or a wireless mode. The game, driver and monitor stages depend on everything else in the system, so a good peripheral test keeps those constant between runs.
The key idea is to compare like with like. Use the same game, the same resolution, the same refresh rate and the same settings for every device you test. If you change the monitor between runs, the results describe the monitor, not the mouse. Keep the rest of the system fixed, and the difference between devices becomes visible.
Latency varies between clicks, so a single number means little. A device might show a 7 ms result once and 12 ms the next time, depending on where the click falls in the polling cycle. For that reason, take a set of readings and look at the median and the spread. A tight cluster around one value is more useful than a single best result.
Think of latency as a budget rather than a single number. Each stage spends part of the total, and a faster mouse recovers only the time it actually saves. If the monitor already adds 10 ms, a peripheral that saves 1 ms is a small share of the chain. Keeping that budget in mind stops you from overvaluing small peripheral changes that the rest of the system will hide.
Why frame counting at 240 fps matters
A camera records a fixed number of frames each second, so the frame rate sets the time resolution of your measurement. At 240 fps, each frame lasts about 4.17 ms, because 1000 divided by 240 is 4.17. At 120 fps, each frame lasts 8.33 ms, and at 60 fps, each frame lasts 16.7 ms. Those figures explain why a 60 fps phone video is too coarse for peripheral comparisons, while 240 fps is the practical minimum.
Counting frames is the core of the method. Find the frame where the button physically moves or the LED lights, then find the first frame where the screen changes. Subtract the two, multiply by the frame interval, and you have the delay in milliseconds. Repeating the count across many clicks reduces the effect of any single miscount, and it reveals the spread that a single reading hides.
Frame counting also has a limit. Any delay shorter than one frame cannot be resolved, so a 4.17 ms interval means a result of 4 ms and a result of 8 ms are the only values you can observe at that resolution. Two mice that differ by 1 ms will often look identical on a 240 fps phone. Use the method to spot differences of several milliseconds, and to confirm that a setting change has an effect.
Some phones allow higher frame rates at reduced resolution. A 480 fps or 960 fps mode can give finer steps, but the image may be too small or too dark for reliable counting. Test the mode with a known event before you trust it. A slow-motion mode that changes frame timing unpredictably is not useful for latency work.
Always confirm the frame rate of the recording. Some phones label slow motion as 240 fps but record at a variable rate. Check the file’s metadata or record a timing reference, such as a stopwatch on screen, to verify the frame interval before you start counting. A mistaken frame rate shifts every result by the same error, which is easy to miss.
Write the frame interval in your log next to each result so the conversion can be traced later.
Test methods compared
Several methods can measure peripheral latency. They differ in resolution, cost and how easily you can repeat them at home. The table below compares the common options. The resolution column reflects the time step each method can observe, and the cost column is an approximate estimate for a self-built setup.
| Method | Equipment | Time resolution (approx.) | Approximate cost (estimate) | Best for |
|---|---|---|---|---|
| 240 fps phone recording | Phone, tripod, LED or screen flash | About 4.17 ms per frame | Phone you already own | Beginners and comparing two devices |
| High-speed camera at 1000 fps or more | High-speed camera, strong lighting | About 1 ms or finer | Several hundred to several thousand | Detailed comparisons across many clicks |
| Dedicated latency analyzer | Commercial analyzer with a photodiode or click sensor | Sub-millisecond, device-specific | Higher, specialist equipment | Reviewers and repeatable lab-style runs |
| Oscilloscope with a switch probe | Oscilloscope, probe, switch wiring | Sub-millisecond | Moderate to high | Switch timing and debounce analysis |
| Software timers or game counters | None beyond the PC | Unreliable for this purpose | Free | Not recommended for latency claims |
For most readers, the 240 fps phone is the right starting point. It requires no special hardware, and the frame-counting routine transfers directly to better equipment if you move up later. The high-speed camera is a sensible second step if you need to resolve smaller differences between switches or polling modes. Dedicated analyzers are worth considering only if you test many devices or publish comparisons that others will rely on. If you are shopping rather than testing, our lowest latency gaming mouse guide is a quicker route to a shortlist.
Software timers should not be used for latency claims. A timer inside the game or a utility measures the software’s own view of the event, which misses the switch, the USB path and the display stages. Two mice can show identical software timings while differing on the physical measurement. A camera or sensor sees the real event, which is why it is the reference point.
Whatever you choose, keep the method fixed across the devices you compare. Changing the camera, the lighting or the counting rule between runs makes the comparison meaningless. Note the equipment in your log, so a later reader can repeat the test under the same conditions.
Setting up a home rig with a phone
Mount the phone on a tripod so the frame does not move. Aim it at the mouse button and the monitor region where the result will appear. Use a stable light source so the button press and the screen change are visible, and avoid auto-exposure changes by locking the exposure if your phone allows it. A dim, flickering room makes frame counting harder, so do the test in consistent light.
Create a visible reference on screen. A simple approach is a black square that turns white when the click registers, drawn by a small test program or a game-based flash. The change must be sharp and immediate, not a fade. If your test program draws the flash after the operating system receives the input, the measurement includes that software step, so keep the same program for every device.
Connect the mouse to the test PC directly, or use the same dongle for every run. For wireless tests, place the dongle in the same position each time, at least a short distance from the PC’s noisy USB ports. Record the polling rate, the dongle position and the firmware version. Changing any of those between runs changes the result, so treat them as part of the test condition.
Use a monitor with a known refresh rate and keep V-Sync and frame caps fixed. Disable any motion smoothing or post-processing on the display, because those add processing delay that has nothing to do with the mouse. Note the refresh rate, the panel mode and the response setting in your log.
Before recording, run a calibration pass. Click and watch the flash several times, then check that the recording shows a consistent relationship between the button and the screen change. If the flash appears at random points, the reference is wrong, the lighting is poor, or the phone’s frame rate is not what you think. Fix the setup before you spend time on counts.
Keep your seating, desk height and hand position identical for every run. A mouse feels different when the wrist sits at a new angle, and that changes how firmly you press and where the button engages. Note your grip style as well, because palm and claw grips place the click on the switch in different spots.
Mouse and keyboard specifics that change the result
Polling rate sets how often the device reports to the PC. At 125 Hz the interval is 8 ms, at 500 Hz it is 2 ms, at 1000 Hz it is 1 ms, and at 8000 Hz it is 0.125 ms. A higher rate reduces the average wait before the next report. The effect is greatest at low rates, and the gain from 1000 Hz to 8000 Hz is much smaller than the gain from 125 Hz to 1000 Hz. Our estimate is that most players will not notice differences beyond 1000 Hz in typical games. For the polling math in more detail, see our mouse DPI and polling rate explained guide, and for menu steps, the how to change mouse polling rate walkthrough.
Debounce settings and switch design add a variable delay. A switch that bounces needs a debounce period, and a long debounce adds latency while a short one can register noise. Optical and magnetic switches, which are common in newer keyboards, avoid some mechanical bounce, but they add their own processing. Judge the switch type by the measured result on your rig rather than by its marketing.
Wireless modes add a radio hop. A well-designed 2.4 GHz connection can keep the added delay small, but interference, dongle placement and the protocol’s retransmission rules all influence it. Bluetooth connections usually show larger and more variable delays than dedicated wireless modes. Test each mode separately and look at the spread, because occasional spikes can matter more than the average.
Keyboards follow the same logic. A keyboard with a 1000 Hz report rate and a fast switch will often show lower latency than one with a slower scanning method, but the difference may be smaller than the variation between keys. Test several keys, not just one, and include the key you use most often. A keyboard that is fast on one key and slow on another is not a good choice for competitive play.
Sensor settings can also change the chain. Some mice let you adjust lift-off distance, angle snapping or filtering. These settings do not change the physical click, but they can affect how the cursor responds to movement. Keep the settings identical across devices, and record them so the comparison describes the hardware and not the configuration.
Monitor and game settings that add to the chain
The monitor and game settings often add more delay than the peripheral. A high refresh rate reduces the time each frame waits on the display. At 144 Hz a frame lasts about 6.9 ms, and at 240 Hz it lasts about 4.2 ms, so a faster panel shortens the final stage of the chain. These are arithmetic values from the refresh rate, not measurements of any particular panel.
Frame queueing settings can add a frame or more of delay. Maximum pre-rendered frames, V-Sync and triple buffering all affect how long a rendered frame waits before it is shown. Low-latency modes in the driver or game, such as NVIDIA Reflex or AMD Anti-Lag, aim to reduce that queue. Their effect depends on the game, the GPU load and the frame rate, so test them with the same scene.
A frame cap can help or hurt. Capping the frame rate a little below the monitor’s refresh rate can reduce queueing and keep latency steadier when the GPU is near its limit. A cap set too low lowers the frame rate, and the time between frames grows, which can add delay of its own. Pick a cap that matches your monitor and GPU, and check it rather than assuming. Our how to reduce input lag guide covers the system-side settings in order.
Display processing adds a final layer. Motion smoothing, dynamic contrast and some scaling modes can add processing time before the image reaches the panel. Turning them off in the monitor’s menu is a simple way to remove that delay. Keep the display mode fixed during our research and record it.
Finally, the game itself matters. Different titles use different input handling and different frame pacing. A peripheral that tests well in one game may show a different result in another. Test at least two titles, and note which one each result came from, so the comparison reflects the device and not a single engine’s habits.
Test the monitor and the game separately from the peripheral. A simple way to isolate the chain is to run the same flash test with the monitor in each display mode and record the difference. Then fix the best mode for all peripheral runs. That approach keeps the display from hiding the difference between mice and keyboards.
Recording, counting and reporting your results
Record a fixed number of clicks for each device, at least twenty, and keep the order consistent. Count the frames for each click, convert them to milliseconds, and write them down. Report the median and the range rather than the best single click, because the best click tells you about luck, not about the device.
Use a simple log. For each run, record the device, polling rate, connection mode, monitor refresh rate, game or test program, frame cap, display settings and the date. Add the per-click results and the median. A log in this form lets you repeat the test later and spot which variable changed when results shift.
Look at the spread as well as the median. A device with a tight range, such as all results between 8 and 11 ms, usually feels more predictable than one that ranges from 6 to 16 ms, even if its median is slightly lower. Consistency matters in competitive play, because a sudden spike can cost a fight even when the average is good.
Round results to the resolution of the method. A 240 fps phone can resolve about 4 ms steps, so reporting results to two decimal places implies precision that the method does not have. Report whole frames and convert them to ranges, such as 8 to 12 ms, and say that the figures are estimates from the camera.
When you publish results, state the method, the frame rate, the number of clicks and the settings. Include a short description of the rig and note any limits. Readers can then judge the result for themselves, and the comparison stays useful even when someone repeats it on different hardware.
Store the raw frame counts, not only the converted milliseconds. Raw counts let you recalculate results if the frame rate turns out to differ from what you assumed, and they make it easy to check a suspicious run. Save each video clip under a name that includes the device, the date and the run number, so the footage can be re-examined later without guessing which run it came from.
Common mistakes that skew latency results
The most common mistake is changing more than one variable at a time. If you swap the mouse, the polling rate and the monitor between runs, you cannot tell which change caused the difference. Change one thing per run, and keep a written list so the sequence is clear afterward.
A second mistake is testing only one click. Latency varies with where the click falls in the polling cycle and where the frame boundary lands. A single click can look fast or slow by chance. Repeat the count, use the median, and look at the spread before drawing a conclusion.
A third mistake is ignoring the display. Two mice run on different monitors will produce different results even when the mice are identical. Use the same monitor for every device, and note its refresh rate, response setting and processing mode. Otherwise the display may explain most of the gap.
A fourth mistake is trusting software readouts. Counters inside a game or a timing utility measure only part of the chain, and they may misreport the actual event. A camera or sensor records the physical click and the screen change, which is the reference that software readouts cannot provide.
The last mistake is treating small differences as meaningful. A difference of one or two frames at 240 fps is within the uncertainty of the method. Look for consistent differences of several frames that repeat across runs and across games. Anything smaller should be recorded as inconclusive rather than presented as a winner.
A sixth mistake is testing right after a firmware or driver update. The first boot after an update can run background indexing and driver setup that skew early results. Wait for the system to settle, run a short warm-up session, and then start the logged runs.
A seventh mistake is changing the test program between devices. A different flash timing, a different window size or a different input method alters the reference. Use one program, one version and one window layout for every device you compare, and record the program’s version in the log.
Troubleshooting: when your latency numbers look wrong
If your results are much higher than expected, start with the display. Check the refresh rate, disable motion smoothing and processing, and confirm that V-Sync and frame caps are set the way you intended. A monitor in a high-processing mode can add several milliseconds on its own, and that delay will appear in every peripheral test you run on it.
If results jump around from click to click, check the lighting and the camera exposure. Flicker from artificial lights can blur the flash, and auto-exposure changes can shift the apparent moment of change. Lock the exposure, use steady light, and recheck the flash timing. Inconsistent recordings are usually a setup problem rather than a device problem.
If a wireless mouse shows large spikes, move the dongle to a clear position, away from USB 3.0 ports and other radio sources. Use a short extension cable if the dongle sits behind the tower. Repeat the test in wired mode to confirm whether the spikes come from the radio link or from the device itself.
If the flash appears before the click is registered, the reference may be wrong. Check that the test program draws the flash only after the input event, or use a physical LED on the mouse instead of a software flash. A reference that fires early produces negative or impossibly small latency numbers, which signal a setup error rather than a fast device.
If a result seems impossibly fast, check the frame rate of the recording. A phone that records slow motion at a variable rate can make frames look shorter or longer than they are. Verify the frame interval using a known timing source before you trust the count. Recheck the setup, then repeat the run, and only record the result once the calibration pass is clean.
Frequently asked questions
What is input latency in a gaming PC?
Input latency is the delay between a physical action, such as a mouse click or key press, and the moment the screen shows the result of that action. It is the sum of several stages: switch actuation, peripheral processing, USB polling, operating system handling, game logic, rendering, and display scan-out. Peripheral testing isolates the first few stages, while the full chain also includes the game and the monitor.
Can I measure mouse latency with a phone?
Yes, if the phone records at 240 frames per second. Film the button and the screen together, then count the frames between the click and the first visible change on screen. At 240 fps each frame represents about 4.17 ms, so the method gives you a resolution of roughly 4 ms. That is enough to compare two peripherals on the same system, though it cannot resolve sub-millisecond differences.
Does a higher polling rate always reduce latency?
It reduces the polling interval, not every delay in the chain. A 1000 Hz mouse reports every 1 ms, while a 125 Hz mouse reports every 8 ms, so the wait for the next report can differ by up to about 7 ms. Beyond that, sensor processing, debounce, dongle overhead and game frame timing all matter. Higher rates above 1000 Hz help mainly with smoothness and very fast movement.
Is a wireless mouse slower than a wired one?
Modern wireless mice with a dedicated 2.4 GHz dongle can perform close to wired models in many tests, but the gap depends on the design. Dongle placement, interference and the mouse’s radio protocol all affect consistency. Test both modes on your own system with the same game and settings, and look at the spread of results rather than only the average.
Which latency test method should a beginner use?
Start with a 240 fps phone, a fixed monitor, and a simple on-screen flash. It costs nothing beyond the phone and a tripod, and it teaches you the frame-counting routine. If you later need sub-millisecond detail, move to a high-speed camera or a dedicated latency analyzer. Whatever method you choose, record at least twenty clicks per device and report the median.