7

I've noticed a problem with my webapp - when Chrome active tab isn't set to my app, Chrome stops running my JS code until I open tab again.

I guess it does to save CPU cycles. Else if you've 20 tabs open and each has code running, it will get slow quickly.

This is all good, but my app requires that it keeps running in the background. It updates graphs in real time and analyses data every few seconds.

If I move to another tab, graph updating and analysis stops (or becomes very slow - 1 second is now like 20 seconds). Then when I focus on tab again it resumes updating at normal speed but the graphs and data analysis gets weird because of this weird time dilution.

bodacydo
  • 75,521
  • 93
  • 229
  • 319
  • possible duplicate of [Chrome: timeouts/interval suspended in background tabs?](http://stackoverflow.com/questions/6032429/chrome-timeouts-interval-suspended-in-background-tabs) – Justinas Sep 04 '15 at 05:42
  • 3
    Timers are not going to run at normal intervals in background tabs (this is done to preserve performance for foreground tabs and to preserve battery on mobile devices). It is purposely done in a way that there is no simple way to work-around it because if everyone works around it, then it does no good. Your job at this point is to adapt the behavior of your app. I'm quite sure that if nothing in your page is visible, you can adapt to slower updates without the user even knowing what is going on. You should likely modify the design of your app to handle this. – jfriend00 Sep 04 '15 at 05:54
  • Worth reading this: [setInterval weirdness in background tab](http://stackoverflow.com/questions/6737067/jquery-setinterval-too-fast-when-coming-from-another-tab/6737154#6737154) and this [Chrome: timeouts/interval suspended in background tabs?](http://stackoverflow.com/questions/6032429/chrome-timeouts-interval-suspended-in-background-tabs). – jfriend00 Sep 04 '15 at 05:57
  • @Justinas It's a real time graph - you can switch to it at any time and it should be up to date. When users switch to it an hour later they should see all the updates that happened during that hour. There is a point in updating it even if it's not visible. What you're saying almost sounds like that we should go back to Windows 3.1 where only one active app could get cpu time. There is no point in any other apps running in background if they're not visible, right? – bodacydo Sep 04 '15 at 18:12
  • 1
    @jfriend00 Thanks for your comment. That's what I just did - I called a meeting and we're abandoning browser as a platform for our application and moving to C# where we actually can control timers even if they run in background. Real time graph needs real time updates. My users come 16 hours later at 9:00 in office and the moment they open their screens they have to have the latest info in front of them. Every minute re-downloading data for the last 16 hours and regenerating indicators can cost tens of thousands of dollars. Real time means real time. – bodacydo Sep 04 '15 at 18:23
  • @bodacydo What I mean is - you stop updating on `windows.blur()` and start updating `windows.focus()` – Justinas Sep 05 '15 at 08:02
  • @bodacydo, so you are no longer looking for an answer to this question, based on your comment that you will be dropping the browser clients? – KevBot Sep 07 '15 at 18:15
  • @KevBot I'd still like to know the answer, but I dropped browser client and we're working on C# app now. – bodacydo Sep 07 '15 at 21:29
  • @bodacydo your app should be able to catch up after a slowdown without the charts or analysis getting out of sync. This is a design issue. Just switching to C# will not solve it, it might just make the issues less obvious. – Gunchars Apr 05 '16 at 15:54
  • _The Chromium insider also clarified that aggressive throttling will be automatically disabled for all background tabs “playing audio” as well as for any page where an “active websocket connection is present.”_ If you've got real-time data coming in - you should probably be using a websocket to begin with, which would resolve your issue? – Peter Dolkens Mar 13 '18 at 14:21
  • @PeterDolkens working on a game, having a websocket connection, i.e., using Socket.io, doesn't change anything, however, playing a Sound indeed prevents throttling, so thank you for this discovery, I'll probably add an option to loop an empty sound file as a feature – Kaan Soral Jul 05 '18 at 10:30

1 Answers1

1

Playing a faint sound seems to unlock full javascript performance in the background, yet, using websockets does not

Here's a more lengthy answer I've written: https://stackoverflow.com/a/51191818/914546

Kaan Soral
  • 1,589
  • 1
  • 15
  • 31