Why a Website Ticker Stops Scrolling in a Background Tab

The short answer

Your ticker stops because the browser stopped giving its animation work any time while the tab was hidden. Browsers aggressively throttle, and often fully pause, the mechanisms that drive smooth motion in a tab you are not viewing. The animation does not crash; it is simply denied the frames or timer ticks it needs to advance.

What you see on return depends on how the ticker was built. If it animates by requesting frames, it typically freezes in place and then continues from where it was. If it runs on a timer and tries to catch up, it can lurch forward. Either way the root cause is the same: inactive tabs are throttled on purpose, and a correctly built ticker should expect that rather than fight it.

What a background tab is to the browser

To the browser, a tab you are not looking at is a candidate for savings. It is still loaded and alive, but it is no longer a priority for the CPU or the GPU, and there is no visible reason to paint it sixty times a second. The browser treats "hidden" as permission to do far less work on that document.

This is not a single on/off switch. Browsers apply escalating throttling: first they reduce how often background work runs, then after a tab has been hidden for a while they may clamp it much harder or freeze it almost entirely to reclaim resources. So a ticker might limp for a few minutes and then stop completely. The behavior is intentional and varies by browser and by how long the tab has been in the background.

requestAnimationFrame stops when hidden

Most smooth, motion-based UI is driven by requestAnimationFrame, which asks the browser to run a callback right before the next repaint. The key detail: the browser only repaints visible content. When a tab is hidden, there are no repaints, so those frame callbacks simply stop being called. The animation loop pauses because it is waiting for a frame that never comes.

This is actually the well-behaved case. Because the loop is tied to painting, it naturally halts when there is nothing to paint and resumes the instant the tab is visible again, usually without any visual jump. If your ticker uses this approach, "it froze in the background and continued when I came back" is the expected, correct behavior, not a bug to fix.

Do CSS animations pause too?

A pure CSS animation, like a transform that loops forever, is handled by the browser's compositor rather than your JavaScript. These are more resilient in the background and can keep their internal timeline running even when the tab is hidden, which is why a CSS-driven ticker sometimes appears to have advanced while you were away rather than frozen.

But "can keep running" is not a guarantee. Browsers may still throttle or pause compositor animations in long-hidden or heavily backgrounded tabs to save power, and behavior differs across browsers and versions. The honest summary is that CSS animations are less likely to hard-freeze than frame-based loops, but you cannot rely on perfectly smooth continuity in the background. Treat background motion as undefined and design so it does not matter.

Timers get clamped in the background

If a ticker steps on a timer, the behavior is different again. Browsers clamp background timers so they fire far less often than requested, commonly no more than about once per second and sometimes much slower after a tab has been hidden a while. A loop that expected to tick many times a second suddenly ticks rarely.

This is where the "lurch" comes from. A naive timer-based ticker that advances a fixed step per tick will fall behind in the background, and if it tries to catch up on return by computing elapsed time, it can jump a long distance at once. Timer clamping is a deliberate limit, not something you can opt out of, so any timer-driven motion needs to assume its ticks are unreliable while hidden.

Why browsers throttle at all

The throttling exists for good reasons. The biggest is power: animating offscreen tabs burns CPU and GPU for zero benefit, draining laptop and phone batteries. Multiply that by the dozens of tabs people leave open and the waste is enormous. Throttling idle tabs is one of the highest-impact battery optimizations a browser can make.

There is also an abuse angle. Without throttling, pages could keep doing heavy work, polling, or spinning animations in the background indefinitely, degrading the whole machine for a page you are not even looking at. Clamping background activity is a defense against both lazy code and deliberately abusive code. As a developer you are not being thwarted; you are being asked not to waste resources no one can see.

The Page Visibility API

If you want to respond to this instead of guessing, the browser tells you directly through the Page Visibility API. A property reports whether the document is currently visible or hidden, and an event fires whenever that changes. This is the clean hook for pausing and resuming your own logic exactly when the tab leaves and re-enters view.

The pattern is straightforward: when the document becomes hidden, stop any work that only matters on screen; when it becomes visible again, restart it from a sane state. Relying on this event is far more reliable than trying to detect throttling after the fact, because the browser is telling you precisely when the user looked away and when they came back.

Should you keep it moving in the background?

Almost always, no. A ticker is a visual flourish for someone who is looking at the page. If no one is looking, there is nothing to miss, and forcing it to keep scrolling just wastes the battery the browser was trying to save. Fighting the throttling to animate an invisible element is effort spent making the experience slightly worse for everyone.

The right goal is not "never stop," it is "stop invisibly and resume cleanly." A viewer who tabs away and returns should see the ticker pick back up as if it had been waiting for them, with no frozen artifact and no jarring jump. Accepting that the background is paused, and designing for a graceful return, is the correct target rather than defeating a deliberate optimization.

Making a ticker resume cleanly

Lean on frame-based animation rather than timers, because a frame loop pauses and resumes naturally with no catch-up jump. If you must use a timer, compute motion from elapsed real time rather than assuming a fixed step per tick, so a long gap does not accumulate into a huge leap, and cap any single advance so the worst case is a small nudge, not a teleport.

Then wire it to visibility: pause your loop when the document goes hidden and restart it, resetting any timing reference, when it becomes visible. That reset is what prevents the lurch, because you discard the stale elapsed time from while the tab was away. A ticker built this way looks frozen in the background, which is fine, and glides on the moment the viewer returns.

What this means in practice, and the bottom line

The network ticker across these sites is built to accept background pausing rather than fight it. It uses a looping CSS animation for the motion, pauses on hover so it is readable, and honors reduced-motion preferences. If it freezes while a tab is in the background, that is the browser saving power exactly as designed, and it resumes when the tab is in view again.

The bottom line: a ticker stopping in a background tab is not a bug in your code or the site. Browsers throttle and pause offscreen tabs to protect battery and performance, which halts frame loops, clamps timers, and can even pause CSS animations. Build for it with frame-based motion, elapsed-time math, and the Page Visibility API, and aim for a clean resume rather than pointless background motion no one can see.