Centisecond precision, lap times, and a built-in countdown timer. Wake-lock keeps the screen alive while it runs.
Timing is sampled from performance.now() — sub-millisecond monotonic clock. The visible display refreshes via requestAnimationFrame, but the elapsed-time math is unaffected by frame stutter or background throttling.
We tick off performance.now() which is monotonic and sub-millisecond on modern browsers. The displayed precision is hundredths of a second. For sub-second comparisons between people (race timing) you also need to account for human reaction time when pressing start, which is typically 150–250ms — that's the dominant error, not the browser clock.
By default phones lock the screen after 15–60 seconds of inactivity, which would stop the visible counter (the math keeps running but the display freezes). We request a Screen Wake Lock via navigator.wakeLock — the same API a video player uses to keep the screen on while you're watching. When you stop the stopwatch or switch tabs, we release the lock so you don't drain battery.
Yes — once the page is loaded the stopwatch runs entirely in the browser and needs no network. If you've installed the page as a Progressive Web App (Chrome menu → Add to Home Screen) it will open and run with no signal at all. Useful in transit, on planes, or in the gym basement.
Two reasons. (1) Bigger display — we render the numerals at 12+vw so they're legible from across a room or in a video frame, where the phone Clock app's stopwatch is small. (2) On desktops and laptops the OS rarely ships a stopwatch at all, and the browser version is the fastest way to time something without alt-tabbing through apps.
Stopwatch counts up from zero — for timing how long something takes when you don't know the end. Timer counts down from a number you enter — for cooking, intervals, exam practice, anything with a known duration. The timer rings (audio beep, page flash, vibration on Android) when it reaches zero. Both share the same wake-lock and tick engine.
Two possible causes. (1) Browser tab is in the background — most browsers throttle requestAnimationFrame to 1Hz when a tab isn't visible. The math is still correct (we use performance.now() deltas, not frame counts), it just refreshes once a second until you return. (2) On very old phones the rendering thread itself can stutter; closing other tabs usually fixes it. Numbers are always accurate to performance.now(), even if the visible update lags.