Useful Drawer

Why Do Browser Timers Drift in a Background Tab?

Web countdown timers often slow down when you switch tabs, because browsers throttle background timers. Here's why it happens, and how a clock-based timer stays accurate whatever tab you're on.

·5 min read

Browser timers drift in a background tab because browsers deliberately slow down timers in tabs you are not looking at, to save power. A timer that counts by adding up those slowed intervals falls behind. A timer that reads the system clock does not, because it measures how much time has actually passed rather than counting ticks.

What drift looks like

You start a five-minute timer, switch to another tab to pull up a slide or take attendance, and come back to find it reads four and a half minutes when it should read three. The clock on the wall moved on; the timer did not keep up. On a countdown that a whole room is watching, that gap is obvious and awkward.

Why browsers slow down background tabs

It is intentional. When a tab is hidden, browsers clamp how often its setInterval and setTimeout callbacks run — often to once a second or less — and pause animation frames entirely. The goal is battery life and performance: there is no point spending power updating a screen nobody is looking at. The side effect is that any timer built on how often its code runs loses time.

The two ways to build a timer

The naive way is to count: start at 5:00 and subtract a bit every time the interval fires. That is exactly the approach the throttling breaks — fewer fires means less subtracted, so the timer runs slow.

The reliable way is to record the moment the timer should end, then, on each update, show the difference between now and that end time. Throttle the updates all you like — the tab might only recompute once a second in the background — and the value is still correct, because it is read from the clock, not accumulated. When the tab becomes visible again, the very next update snaps to the true remaining time.

How to check a timer for drift

You do not need to read the code. Start a short timer, switch to another tab for a minute or two, and come back. If it lost time, it counts ticks. If it is exactly where the wall clock says it should be, it reads the clock. That single test tells you whether a timer can be trusted to run in the background during a lesson or a meeting.

Why this matters for a classroom timer

A classroom or event timer is almost never the only thing on screen — you are flipping to slides, a browser, a document, while the countdown runs on a projector. That is precisely the situation background throttling was built for, and precisely where a tick-counting timer fails. The full-screen countdown timer keeps time from the system clock for this reason, so it stays accurate even while it sits in a tab you have switched away from.

Something out of date or wrong here? Device specs and interface details shift with every release. Tell me and I'll fix it.

Related reading