| # | Split | Total | vs avg |
|---|
A naive timer adds up its own tick interval — "100ms just passed, add 100ms" — repeated hundreds of times a
second. The problem is that no tick ever takes exactly 100ms; browser throttling, garbage collection,
and background tabs all add small delays, and a naive timer has no way to know that happened. Every mode
here instead computes elapsed time as now − startTime using a single fixed reference point, so
individual tick jitter can never accumulate into real drift — verified against a simulated realistic
tick-overhead scenario where the naive approach drifted almost two full seconds over one minute, while this
approach stayed exact by construction. The metronome goes a step further, using the Web Audio API's own
clock to schedule beats slightly ahead of time — the standard fix for the well-documented problem that
JavaScript's event loop alone isn't precise enough for musical timing.
A naive stopwatch ticking every 100ms, each tick actually taking 103ms under realistic load, reports
exactly 60.00s after 600 ticks — but only 58.20s of
wall-clock time has actually elapsed, a 1.8-second error in under a minute. The
now − startTime approach used here reports 58.20s correctly, every
time, regardless of how uneven the individual ticks are.
Green means that lap was faster than your running average, red means slower — a quick visual read on whether you're speeding up, slowing down, or holding a steady pace, without doing the maths yourself.
It's 100% minus the coefficient of variation across your laps — the standard deviation of your splits relative to their average. A high score means every lap took about the same time; a low score means your pace swung around a lot, even if the average looked fine.
A plain setInterval can only promise "at least this long," never "exactly this long" — the
browser is free to delay a callback for other work. Music timing needs the opposite guarantee, so the
metronome schedules each beat against the audio hardware's own clock a little ahead of time, the
standard technique real digital audio workstations use.
Clicking before the colour changes means you were guessing the timing, not reacting to it — genuinely fast reaction times only mean something if the stimulus came first. Real reaction-time research discards early responses for the same reason.
Tabata (20s work/10s rest ×8) is the original protocol from Izumi Tabata's 1996 study on high-intensity intermittent exercise; the HIIT and boxing-round presets follow widely-used conventional training formats. Custom rounds let you build any protocol beyond these defaults.
That your device reports time honestly, and that a few milliseconds either way does not matter. Precision is bounded by browser event timing and screen refresh rate, so treat the last digit as indicative. Browsers deliberately throttle background tabs — elapsed time stays correct because it is measured against a fixed reference, but on-screen updates and alerts may lag until you return to the tab. Audio cues carry their own output latency, and reaction-time results include your keyboard, mouse and display lag as well as your own.
This page has changed in 46 archived releases, but each of those was a site-wide pass, so none is attributable to this tool on its own and none is listed here. That is not a claim that the tool never changed — a release that reworked many pages at once may well have altered this one too. The changelog has them.