DEV Community: pai da xin

I Thought a Reaction Time Test Was Just a Timer. Then I Built One.

pai da xin — Sat, 22 Aug 2026 09:32:39 +0000

I expected a reaction time test to be a very small project.

Wait for a signal, click as quickly as possible, and show the result in milliseconds. That sounds simple enough.

But once I started building one, I realized that the interesting part was not the final number. It was everything that happens before and after the click.

The simple idea

A reaction time test measures how long it takes to respond to a visual signal. The result is usually shown in milliseconds, so a lower number means a faster response.

The basic formula is easy. Creating a test that feels clear and repeatable is harder.

A user needs to know when the round starts, what action counts as a response, and how the final result should be interpreted. Small details like browser focus, display refresh rate, input devices, and personal timing can all affect the result.

Why I chose five rounds

One lucky attempt should not define someone's reaction speed.

For this reason, I built the test around five visual rounds. After each round, the result is recorded in milliseconds, and the user can look at the complete set instead of relying on a single click.

I also added a practice mode because most people need one or two attempts to understand the rhythm of the test. Practice makes the experience less frustrating and gives users a chance to get comfortable before comparing results.

What I built

The result is a small browser-based reaction time test. It runs directly in the browser and focuses on one task: wait for the signal to turn green, then click as quickly as possible.

The five-round visual reaction time test running in the browser.

You can try it here: free browser reaction time test

A reaction time score is useful for comparison, but it is not a permanent label. Different monitors, refresh rates, mice, trackpads, browsers, and attempts, and pay attention to the overall pattern rather than one especially fast or slow round.

What I want to improve next

I would like to make the result history easier to understand and explore more ways to compare repeated attempts without making the interface feel complicated.

This project reminded me that even a tiny browser tool can involve a lot of thoughtful decisions. The final page looks simple, but the details behind that simplicity are where most of the work happens.

Gamepad Tester Online: How to Check Buttons, Sticks, and Drift in Your Browser

pai da xin — Sat, 22 Aug 2026 09:22:58 +0000

A controller can feel broken even when the hardware is still fine.

Maybe a stick does not return exactly to the center. Maybe a trigger reports a small value before you touch it. Or perhaps a button works in one game but does nothing in another.

Before replacing the controller or installing random driver tools, it is worth checking what the browser can actually see.

What the browser can read

Modern browsers can expose connected controllers through the Gamepad API. This makes it possible to inspect button states, analog stick values, triggers, and other input signals without installing a separate desktop application.

The browser cannot pair a Bluetooth controller or install drivers for you. The controller must already be connected through your operating system. After that, pressing a button usually makes it available to the page.

The Gamepad Tester Online interface showing live controller diagnostics.

A simple diagnostic workflow

Connect the controller in Windows, macOS, or Linux.
Open the browser-based tester.
Press any button to make the controller visible to the page.
Press each face button, shoulder button, and trigger.
Move both sticks slowly around their full range.
Leave the sticks untouched and check whether their values remain near the center.
Reset the test and repeat anything that looks unusual.

This process takes less than a minute, but it can reveal whether the problem is related to the controller, the operating system, or the browser input layer.

How to read the signals

A button should normally stay at its resting value and change when you press it. The exact mapping can vary between controllers and browsers, so the important thing is whether the input changes consistently.

A centered analog stick should remain close to its neutral position. A persistent offset or constantly moving value can be a sign of calibration problems or joystick drift.

Triggers usually report a range as they are pressed. They should move smoothly instead of jumping unpredictably between values.

If the page says that no controller is detected, that does not automatically mean the hardware is damaged. The controller may not have sent an input event yet, or the browser may not have permission to expose it until a button is pressed.

Why a browser test is useful

A browser test is convenient because there is nothing to download. It also checks the signal at the same layer used by many web games and browser applications.

used as a quick diagnostic baseline.

live controller status, button events, stick telemetry, trigger values, and a basic stick health check in one page.

You can try it here: Gamepad Tester Online

The goal is simple: make controller input visible before you start guessing what is wrong.

Final thoughts

Not every controller problem is a hardware failure. Sometimes the issue appears at the boundary between the device, the operating system, and the browser.

A quick signal check cannot answer every question, but it can turn a vague feeling of “something is wrong” into a much clearer diagnosis.

Reaction

pai da xin — Sat, 22 Aug 2026 07:39:48 +0000

I Thought Building a CPS Test Would Take an Hour. I Was Wrong.

pai da xin — Fri, 21 Aug 2026 09:11:20 +0000

I Thought Building a CPS Test Would Take an Hour. I Was Wrong.

I started building a small CPS test because I wanted a simple way to
measure click speed in the browser.

My first assumption was straightforward: count clicks, divide by time,
and show the result.

But once I began testing it, the details became more interesting than I
expected.

The first version was too simple

My initial version used a basic timer and counted every click.

It worked, but I quickly noticed that a CPS score can feel unfair if the
test does not clearly answer a few questions:

When should the timer start?
Should keyboard input count too?
Does a one-second test mean the same thing as a ten-second test?
What happens when the browser loses focus?

Those decisions affect the result more than I expected.

Starting on the first click

The most important decision was when to start the timer.

I decided that the first valid click should start the test. This means
the user does not lose time trying to react to a countdown. After that,
every valid input is counted until the selected duration ends.

It is a small interaction detail, but it makes the test easier to
understand and repeat.

Why I included different test lengths

A one-second test is fun, but it can be influenced by a short burst of
speed. A longer test is usually more stable.

That is why I included 1, 5, 10, and 30-second options, as well as a
custom duration. I think comparing several attempts is more useful than
treating one score as a final answer.

What I built

I turned the experiment into a free browser-based CPS test. It supports
mouse and keyboard input, starts on the first valid input, and does not
require an account.

You can try the tool here:
Free browser CPS test

What I am still improving

I am still thinking about edge cases such as browser focus, accidental
inputs, and making results easier to compare across test durations.

Building this reminded me that even a tiny browser tool has many small
decisions hiding behind a simple interface.

If you have built browser timing tools before, I would be interested in
how you handle these cases.

Disclosure: I use