Why browser timers drift in background tabs

01

The digits lag after you switch tabs

You set a 10 minute timer, work in another tab for about five minutes, and return to find the timer showing seven minutes left. It should say five. After a few rounds of that you stop trusting web timers. The behaviour is not a bug on one particular site. It comes from how browsers are designed, and once you know the design you can work around it.

02

Browsers slow down tabs you cannot see

A web page asks the browser to "run this code in one second" through setTimeout and setInterval. Nearly every timer that updates its display each second is built on those two calls. But the browser only honours the request faithfully while the tab is visible.

The reason is battery and CPU. Dozens of open tabs each running code every second in the background makes laptops hot and drains batteries. So browsers have progressively restricted hidden tabs.

• 2017, Chrome 57Timers in background tabs were limited to waking about once per second on average. Pages that updated faster than that began lagging as soon as they were hidden.
• 2021, Chrome 88After a tab has been hidden for five minutes, chained timers wake at most once per minute. A timer that used to tick every second now moves once a minute in the background.
• Firefox and SafariThe exact rules differ but the direction is the same. Hidden tabs get slowed, and on mobile they can be paused outright.

These rules will only get stricter. A timer therefore has to be written so that it stays correct even when the browser slows it down.

03

Why a timer that subtracts one second per tick goes wrong

The simplest timer works like this: store 600 seconds remaining, subtract one every second, and show the result as minutes and seconds. While the tab is in front, it works.

The trouble begins when the tab goes to the back. If the browser turns "every second" into "every minute", the code still subtracts one each time it wakes. Sixty seconds have passed; the timer believes one has. Come back after five minutes and it will have counted about five seconds, because it was counting wake-ups, not measuring time.

It drifts slightly even in the foreground. "In one second" means "in at least one second", so on a busy machine the callback lands at 1.02 seconds. Over an hour that adds up to tens of seconds. Harmless for cooking, not for timing an exam.

04

Store the end time and recompute on every tick

The fix is simple. When start is pressed, record the moment the timer should end. If it is 14:00:00 and the timer is ten minutes, the end time is 14:10:00. From then on, each time the code wakes it does one thing: subtract the current time from the end time and draw the result.

Now it does not matter whether the browser wakes the code every second or every minute; the result is the same, because the current time at the moment of waking is exact. The display does update only once a minute while the tab is hidden, but the instant you return it recalculates and shows the true remaining time. The display was late; the time was never wrong.

PipTim works this way. Long stretches in another tab, or a laptop dozing and waking, do not push the countdown off. There are limits it still cannot cross, listed below.

05

The limits that remain

• Closing the tab ends itAn end time only means something while the page is alive. Close the tab or the browser and there is nowhere for the code to run. Reopening can show where the timer would be, but if it ended in between, no alarm sounded.
• When the device sleeps, so does the codeClose the laptop lid or let it go into standby and the browser itself stops. On waking, end-time arithmetic corrects the display immediately, but if the timer ended during sleep the sound plays only after wake-up.
• Mobile is stricterMobile browsers frequently stop JavaScript entirely when the app goes to the background. Without the screen on or a PiP window open, the moment of the alarm cannot be guaranteed.

For exam endings, medication, parking meters and anything else where missing the end is expensive, set an operating-system alarm as well. A web timer is good at showing remaining time; a system alarm is good at going off at a fixed moment no matter what. They are not rivals.

06

Silent alarms are a different problem

Sometimes the timer is accurate but makes no sound. That is not throttling; it is the autoplay policy. Browsers block audio from pages the user has never interacted with, a rule aimed at advertisements that play sound uninvited, and timer alarms fall under the same rule.

In PipTim, pressing the start button yourself is that interaction. A timer started by clicking will sound; settings loaded from a shared link need the start button pressed before sound is allowed. Beyond that, check tab mute, device volume and do-not-disturb, in that order. The help page lists them.

07

How a PiP window sidesteps the problem

Throttling is decided by visibility. A picture-in-picture window is always visible: it floats above other windows and the user is looking at it, so the browser has no reason to slow its updates. Even if the original tab is slowed in the background, a timer built on end-time arithmetic corrects itself on the next update and the PiP window's digits move every second.

There is a more practical reason too. Half of the background problem is not technical but forgetting. An accurate timer nobody looks at is no use. A small window inside your field of view keeps time on your mind regardless of how precise the clock is. The ways of getting one are compared in four ways to keep a timer on top of other windows.