DIY · precision timing

Precision Timer & Stopwatch

Drift-corrected timing, real lap statistics, and four more modes most apps skip.
Zero drift by construction
Stopwatch

Controls

00:00.00
Space start/stop · L lap · R reset

Export

Every lap time, split, and the running total — for pace analysis in a spreadsheet.

Lap statistics

no laps yet

Split chart

each lap, coloured by pace trend

Laps

#SplitTotalvs avg
Field notes

Why most timer apps are quietly wrong

How it works

Timing correctly is harder than it looks

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.

Worked example

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.

Why does the lap chart colour some bars red and some green?

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.

What's the "consistency" stat actually measuring?

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.

Why does the metronome use Web Audio instead of just setInterval?

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.

Why does clicking early reset the reaction test instead of just recording a fast time?

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.

Why do interval presets use those specific work/rest numbers?

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.

Accurate to your browser's own clock. All timing is drift-corrected and verified, but background-tab throttling on some devices can still coarsen update frequency (not accuracy) for very long-running timers. The reaction test measures click latency including your device's own input lag, not pure neurological reaction time.