DEV Community: Om Vaghani

Keeping a browser timer accurate in background tabs (what I learned building ClockAura)

Om Vaghani — Sat, 17 Oct 2026 11:45:49 +0000

I run ClockAura, a free site of online timers: countdowns, a Pomodoro timer, a stopwatch, interval timers for the gym. The first versions had the bug I suspect every browser timer has at some point: start a countdown, switch to another tab, and it rings late. Sometimes minutes late.

The bug wasn't in one line of code. It came from an assumption: that the browser keeps running your code at the same pace when nobody is looking. It doesn't. This post covers what I changed and why. The code snippets are lightly trimmed from the real hook that runs every countdown on the site.

The naive version

My first countdown looked like most tutorials:

// Don't do this
const id = setInterval(() => {
  setRemaining((r) => r - 1000);
}, 1000);

Two separate things are wrong here.

First, setInterval(fn, 1000) doesn't promise a call every 1000 ms. It promises at least 1000 ms between calls. Every late call adds a little drift, and subtracting a fixed 1000 bakes that drift into the result. Over a 25-minute Pomodoro you can lose whole seconds even in a foreground tab.

Second, background tabs. Chrome limits timers in hidden tabs to roughly one wake-up per second, and after a page has been hidden for a few minutes it can batch chained timers much more aggressively, down to about once a minute. Firefox and Safari have their own versions of this. A countdown that counts ticks is at the mercy of how many ticks the browser lets you have.

Rule 1: store the end, not the remaining

The fix most people land on, and the one that matters most: when the timer starts, compute the moment it should end, and from then on derive everything from that moment.

useEffect(() => {
  if (running) {
    targetRef.current = performance.now() + remaining;
    liveRef.current = true;
    rafRef.current = requestAnimationFrame(tick);
    armBackup();
  }
  // cleanup cancels the frame and the timeout
}, [running, tick]);

Each tick then asks "how far are we from the end?" instead of "subtract one more second":

const tick = useCallback(() => {
  if (!liveRef.current) return;
  const left = Math.max(0, targetRef.current - performance.now());
  setRemaining(left);
  if (left <= 0) { /* finish: see Rule 3 */ return; }
  rafRef.current = requestAnimationFrame(tick);
}, []);

A late tick no longer causes drift. If a frame arrives 300 ms late, the display jumps 300 ms and is correct again. Nothing accumulates.

I use performance.now() here, not Date.now(). performance.now() is monotonic: it doesn't move when the user's clock syncs with a time server or when someone changes the system time. Date.now() can jump backwards or forwards, and a countdown that gains five minutes because Windows corrected the clock is a fun bug report to read.

There is one place where I do use Date.now(): when a running timer is saved to localStorage so it can be resumed after a reload. performance.now() restarts at zero on every page load, so it can't be stored. The saved record keeps a wall-clock endsAt, and the page turns it back into a duration when you come back:

const left = t.endsAt ? t.endsAt - Date.now() : t.left;

Rule 2: don't trust requestAnimationFrame to finish the job

I moved the display loop to requestAnimationFrame because it lines up with the screen refresh and makes the digits look smooth. The catch: browsers pause rAF entirely in hidden tabs. Not slow it down. Pause it.

With a rAF-only loop, the end-timestamp math is still correct, but nothing runs the check. So the timer "finishes" the moment you switch back to the tab, which might be ten minutes after it should have rung. That was most of the late-alarm reports.

The fix is a second, much simpler mechanism: one setTimeout aimed straight at the end time.

const armBackup = useCallback(() => {
  clearTimeout(backupRef.current);
  if (!liveRef.current) return;
  const left = targetRef.current - performance.now();
  backupRef.current = setTimeout(() => {
    if (!liveRef.current) return;
    if (targetRef.current - performance.now() <= 0) tick();
    else armBackup();
  }, Math.max(0, left) + 15);
}, [tick]);

A few details that took me more than one try:

One long timeout, not a ticking one. Background throttling hits chained timers hardest: timers that schedule timers, again and again. A single timeout set for 25 minutes is about the friendliest thing you can ask a throttled tab for. At worst it gets lined up with the next one-second boundary, which is fine for a kitchen timer and a Pomodoro.
The +15 ms. Timer callbacks and performance.now() don't share an exact clock, and performance.now() is deliberately coarsened for security reasons. Without the padding, the timeout sometimes fired a hair before the target, saw 2 ms left, and had to re-arm. The padding makes the common case a single wake-up.
Re-arm if early. If it does fire early anyway, it schedules itself again for the real remainder instead of giving up or ringing early.

When the user adds a minute with the +1 button, the end moves, so the backup has to move too:

const addMs = useCallback((deltaMs) => {
  setRemaining((prev) => {
    const next = Math.max(0, prev + deltaMs);
    targetRef.current += next - prev;
    return next;
  });
  setTimeout(armBackup, 0); // end time moved: re-aim the backstop
}, [armBackup]);

The setTimeout(armBackup, 0) is there because the state updater runs later than you might expect. Re-arming on the next turn means the backup reads the updated target.

Rule 3: two ways to finish means two ways to ring twice

Once both rAF and setTimeout can end the timer, you have a race. Come back to the tab at exactly the wrong moment and both fire within a few milliseconds. The user hears the alarm twice and the "focus minutes" stat would count the session twice.

The guard is one ref that both paths check, and the finishing path flips it first, before doing anything else:

if (left <= 0) {
  liveRef.current = false;          // close the door first
  clearTimeout(backupRef.current);  // cancel the other path
  cancelAnimationFrame(rafRef.current);
  setRunning(false);
  onDoneRef.current();              // ring exactly once
  return;
}

It has to be a ref, not state. State updates are batched and applied on the next render, so two callbacks in the same turn would both read the old running === true. A ref is just a mutable box, and the second caller sees false immediately.

onDone lives in a ref for a related reason: the page passes a fresh callback on every render, and I didn't want tick to be recreated 60 times a second because of it.

Rule 4: keep the screen on, but only when it matters

A lot of timers end up on a projector or a TV: classroom timers, workout timers across the room. Nothing kills that faster than the laptop dimming its screen at minute nine.

The Screen Wake Lock API fixes it in a few lines, with two catches. The lock is released automatically whenever the page is hidden, and it's not re-acquired when you come back. So the hook listens for visibilitychange and asks again:

const onVisible = () => {
  if (active && document.visibilityState === 'visible' && !lockRef.current) acquire();
};
document.addEventListener('visibilitychange', onVisible);

The other catch is about scope. The lock is held while a timer runs or while the page is full screen, and released otherwise. A wake lock that stays on after the timer ends drains a laptop battery for nothing.

Rule 5: the service worker must never serve an old timer

Timers are the kind of page people open with bad Wi-Fi: in a gym basement, a classroom, a kitchen. So the site has a service worker that caches the core timer pages after the first visit, and they open offline.

The thing I was most nervous about was the opposite problem: shipping a fix and having half my users stuck on the cached old page. The rules I settled on:

HTML is network-first. The cached copy is only used if the network fails, or on a repeat visit when the network hasn't answered within 700 ms.
Hashed assets are cache-first. /assets/index-a1b2c3d4.js never changes content, so caching it forever is safe.
The cache name includes the build id. Every deploy creates a new cache and the activate handler deletes the others, so a cached page always matches the scripts cached with it.

const VERSION = '__BUILD_ID__';           // replaced at build time
const CACHE = `clockaura-${VERSION}`;

self.addEventListener('activate', (event) => {
  event.waitUntil((async () => {
    const keys = await caches.keys();
    await Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k)));
    await self.clients.claim();
  })());
});

The service worker has nothing to do with timing accuracy, but it's part of the same promise: when you press Start, the timer works, whatever the tab or the network is doing.

One gap I found while writing this

The tab title ("04:59 · Countdown") and the little progress ring in the favicon were updated from the same render loop as the digits, and that loop is driven by rAF. In a background tab the ending was reliable, thanks to the backup timeout, but the title could sit still until you looked at the tab again. Ironically, a background tab is exactly when you'd look at the title. The fix is a one-second interval that only runs while document.hidden is true and only updates the title. Background throttling allows one wake-up per second, and that's all a title needs.

The short version

If you're building anything that counts down in a browser:

Store the end time and derive the remaining time from it. Never subtract fixed ticks.
Use performance.now() inside a page and Date.now() only for anything you save.
Drive the display with rAF, but back up the finish with one setTimeout aimed at the end.
Guard the finish with a ref so it can only happen once.
Re-acquire the wake lock on visibilitychange.

If you want to see it all working, start a Pomodoro timer, switch to another tab, and wait for the bell. Or open a link timer like clockaura.com/t/25m, which starts a 25-minute countdown straight from the URL.

I'm happy to answer questions in the comments, especially if you've found a browser where this still rings late.

I Built ClockAura: A Free Online Timer Platform with React + Vite (My Solo Dev Journey)

Om Vaghani — Wed, 13 May 2026 19:44:24 +0000

Update — October 2026: ClockAura has grown a lot since I first wrote this in May. It now has 190+ pages, 8 UI languages (English, Hindi, Gujarati, Spanish, Portuguese, French, German, Indonesian), link timers (type clockaura.com/t/5m and a 5-minute timer starts), and it opens offline after your first visit. Numbers below are marked as "at launch" where they changed.

TL;DR

I built ClockAura — a free online timer site with countdowns, a stopwatch, Pomodoro, alarm clock, interval timers and classroom tools. Built with React + Vite. No sign-up needed. Live at clockaura.com.

Why I Built ClockAura

As a solo developer, I kept running into the same problems with "free online timer" sites:

Dated, cluttered interfaces
Intrusive ads that cover the timer
Sign-up walls for basic features
Only one timer type per site

I wanted one clean place for all of it, so I built the timer site I wanted to use myself. About three months later, ClockAura went live.

What's Inside

Core tools

Pomodoro Timer — 25/5 cycles, auto-start, a task list and daily stats
Online Stopwatch — full screen, laps, CSV export
Countdown Timer — any duration, saved presets
Alarm Clock
Interval Timer — HIIT, Tabata, EMOM
World Clock and a meeting planner
Countdown to a date — events, exams, festivals

Things I'm proud of

Link timers: clockaura.com/t/90s, /t/1h30m, /t/until/17:00 start instantly — handy as bookmarks
Classroom mode for projectors, with a QR code to share the timer
Embeddable widget for blogs and LMS pages
OBS overlay mode for streamers (transparent background)
8 languages, with proper hreflang

The Tech Stack

{
  "frontend": "React 18",
  "build": "Vite",
  "styling": "Tailwind CSS",
  "routing": "React Router",
  "hosting": "Hostinger (static + .htaccess)",
  "analytics": "Google Analytics 4",
  "monetization": "Google AdSense"
}

SEO Challenges in a SPA

The biggest challenge was making every tool page crawlable. My first fix (at launch) was a static fallback inside index.html. Later I moved to prerendering every route at build time, so each URL ships its own HTML with title, description, canonical and structured data, and React takes over in the browser.

Lessons from that:

Keep the prerendered HTML and the runtime <head> in sync — it's easy for the two to drift.
Replace page-owned JSON-LD and hreflang on every client-side route change, not just on first load.
Treat redirects and the SPA router as one system, or a page can work on click but redirect on reload.

Keeping Timers Accurate

Browsers throttle requestAnimationFrame in background tabs, so a timer that counts frames drifts. ClockAura stores the end timestamp and computes the remaining time from it, with a single setTimeout as a backstop so the alarm still fires when the tab is hidden.

Performance

At launch, PageSpeed showed about 87 mobile / 94 desktop. After moving CSS out of the HTML, self-hosting fonts and deferring third-party scripts until interaction, the homepage scores 100 on mobile in Lighthouse (October 2026). Lab scores aren't a ranking guarantee, but a fast first load matters on cheap phones.

Lessons Learned

Start simple, then iterate. Launch with a few tools, then listen.
SEO takes time. Organic clicks were tiny for the first months and only started growing after real fixes and useful pages.
Thin pages don't help. I pruned dozens of near-empty pages and merged them into stronger ones.
Performance is UX.
Don't skip the boring stuff — Privacy, Terms, About and a clear contact page matter for trust.

What's Next

Better classroom workflows with real teacher feedback
More useful content around study and workout timing
A mobile app, eventually

Try It

🔗 clockaura.com — or just type clockaura.com/t/5m.

I'd love feedback: what timer feature is missing for you?

Connect

X: @ClockAuraApp
Website: clockaura.com

Thanks for reading!