What Happens to Timers in Background Tabs? We Measured It
We hid a real page and recorded when its timers actually fired: what throttling does to 1-second, 100 ms and chained callbacks over the first minute, and how timestamp-based timers survive it. Reproducible numbers, single platform, limitations stated.
Everyone knows a background tab "slows down". Fewer people know by how much, or exactly when. We measured it: we loaded a page in Chrome 154 on Linux, started three kinds of timer, then switched to another tab and logged every callback with a timestamp and the page's visibility state. This is one careful run, not a survey; treat the numbers as a clear observation of a documented behaviour, and the explanation of why a tick-counting timer loses time while a timestamp-based one does not.
The one-line answer
A hidden tab's timers do not stop — they get pushed onto a slower schedule almost immediately. A one-second callback quietly became a two-second one; a 100 ms callback was clamped to one second; and a chain of zero-delay callbacks eventually fell toward one firing per minute. A timer that counts callbacks loses time in proportion to what the browser withholds — the finer the interval you asked for, the worse it fares. One that recomputes from a timestamp does not care how often it is called; it is correct on whatever tick arrives.
How we measured
Each timer logged the value of performance.now() every time it fired, along with document.visibilityState. We then looked at the gap between one callback and the next, grouped by whether the page was visible or hidden at the moment each callback fired. performance.now() is monotonic — it advances steadily and does not jump when the system clock is adjusted — so it is a sound reference for elapsed time within the page. The run used headless Chrome 154 on a Linux desktop; the tab was opened, allowed to start, then backgrounded by activating a second tab — the same intent as clicking away from a tab, though not byte-for-byte identical to a real minimised window (see limitations).
Finding 1: a hidden tab's 1-second timer becomes a 2-second timer
The polite surprise: a plain setInterval(1000) kept firing while hidden — it was not frozen — but its period doubled. Every gap we recorded in the hidden state was 1.95–2.00 s, never the expected 1.00 s. For a stopwatch or countdown that counts these ticks, that is roughly one second of error for every two seconds of real time: a 10-minute timer left in the background would finish well over four minutes late.
| Tab state | Callbacks recorded | Median gap | Range |
|---|---|---|---|
| Visible | 1 | 1000 ms | 1000 ms |
| Hidden | 23 | 2000 ms | 1950–2000 ms |
Finding 2: fast timers are clamped to one second the moment the tab is hidden
A setInterval(100) is a ten-times-a-second timer while you are looking at it — our focused run measured a flat 100 ms period across 460 callbacks with no visible jitter. The instant the tab went to the background it was pulled to the same one-second floor: hidden gaps were 1000 ms, stretching to 60000 ms as the harsher tier engaged. Ten callbacks a second became roughly one.
| Timer | Visible tab | Hidden tab |
|---|---|---|
| setInterval(1000) | 1000 ms | 2000 ms |
| setInterval(100) | 100 ms | 1000 ms (up to 60000 ms) |
| setTimeout(0), chained | 4 ms | up to 60000 ms |
Finding 3: the second tier is real, and it is about once a minute
The one-second floor is only the first tier. A chain of setTimeout(..., 0) callbacks — how a self-scheduling loop runs — was the fastest thing in the whole test while focused: a steady 4 ms per hop, which is simply the browser's specified minimum nesting delay, the wall every fast loop hits by design. Hidden, that same chain degraded toward one callback per minute in our run. Chrome documents the same shape: after a tab has been hidden for a while, its chained timers fall under "intensive throttling" of roughly one wake-up per minute, from which only audio playback or an active connection is exempt. Worth being precise about what our data shows: the clamp to ~1/second appeared immediately, but the slide toward one-per-minute was only observed in the runs where the tab stayed hidden long enough to reach it, so treat the *onset* of the second tier as documented behaviour rather than a number we pinned down precisely.
Finding 4: this is why tick-counting timers fail and timestamp timers do not
Throttling does not corrupt the clock; it corrupts the delivery of callbacks. A timer built on "increment a counter every tick" trusts the delivery, so it loses time in step with the callbacks the browser stops sending — and it loses more, the finer the interval it was built on. A timer built on "remember the start time and subtract" never asks the browser to keep a schedule — it recomputes the truth on whatever tick arrives, however late. The callback being late stops mattering the moment your number comes from the clock instead of from the count.
How StopwatchHQ is built on these facts
The online stopwatch and countdown timer on this site use the second approach. To be clear about credit where it is due: recompute-from-a-timestamp is standard practice for any timer that cares about correctness, not a house invention. We follow it deliberately, which is why throttling changes our frame rate but not our numbers:
- Elapsed time is always
now − start. Throttled ticks change the frame rate, never the number. - The display is a view, not the clock. If the tab is hidden and the animation loop pauses, nothing is lost; switching back repaints the correct value instantly.
- Wake-ups are treated as best-effort. We do not pretend a hidden tab will alert on the exact second (see the caveat below).
What this means for you
- If you keep a timer in the foreground, browsers behave well — a 1-second or 100 ms timer fires on schedule to within well under a millisecond.
- If you will switch tabs, use a timer whose count comes from a timestamp. Counting ticks in a hidden tab silently loses time, and the faster the interval it counts, the more it loses.
- If you need an alarm to fire on time while the tab is hidden, a web page is the wrong tool; keep it visible or use your phone or OS alarm.
Limitations, stated plainly
- One platform, one run, headless. Every number is a single run of Chrome 154 on one Linux desktop, headless. Other browsers, operating systems and phones throttle differently — often more aggressively — and we have not measured them here. There are no repeat runs or error bars in this piece; read it as a clear observation, not a statistical result.
- A "second tab" is not a minimised window. We backgrounded the page by activating another tab. A genuinely minimised or fully occluded window can behave differently again, and headless Chrome's exact constants may differ from a normal window.
- The second tier's onset is documented, not measured precisely. Our runs covered roughly the first minute to ninety seconds of hidden time. The clamp to about one callback per second showed up at once; the slide to about one per minute is Chrome's documented behaviour, and its exact five-minute onset was not what we pinned down.
- Clocks measuring clocks.
performance.now()is monotonic and well suited to this, but it is still the browser's own clock, not an external reference, and it does not survive the machine sleeping. Timing across a laptop suspend is a different problem we did not test. - Timestamps fix the display, not the wake-up. A throttled tab can deliver its alarm callback late no matter how the elapsed time is computed. That is a separate problem, and we are explicit that this architecture does not solve it.
Frequently asked questions
Do background tabs stop timers entirely?
No. They reschedule them. The first tier slows a hidden tab to at most about one callback per second, and a later tier slows chained timers toward one per minute. They keep running — just far less often than you asked.
Why did my countdown lose time when I switched tabs?
Because it was counting ticks. If the tab delivered half as many callbacks, a tick counter lost half the time. Recomputing the remaining time from a stored end timestamp would have shown the correct value the whole time.
Does playing audio keep a timer accurate?
Chrome documents that audio playback keeps a tab in the less-throttled state and is exempt from intensive throttling, which is why some timer sites play silence to stay awake. That is documented behaviour rather than something we measured here. It helps delivery, but it still does not make the elapsed-time maths correct — that is a separate fix.
Will my alarm fire on time in a hidden tab?
Not reliably. Even a correctly built timer can be woken up late once a tab is throttled, and we say so plainly rather than promise otherwise. For a must-fire alert, keep the tab visible or use an OS-level alarm.
Try it yourself
Open the stopwatch, start it, then switch to another tab for a few minutes and come back. The reading will match your phone, because the display never depended on the browser delivering every tick on time.
Related tools and reading
For timing itself, the online stopwatch, countdown timer and pomodoro timer all use timestamp-based timing. For how we measured the focused case, read how reliable a browser timer is, and for putting accurate timers to work see the guides on study timers, cooking timers and workout timers.