2

Since version 86 of Chromium, there is a new experimental feature called "Throttle Javascript timers in background" that is added to fix the high battery drain of Chromium browsers.

The description says:

In a Window whose top Window has been hidden for 5 minutes, timers can run:

  • aligned on 1-minute intervals, or,
  • if the Window is same-origin with the top Window, > 1 minute after the last timer has run in any Window in the tree that is same-origin with the top Window.

In a page that has been backgrounded for less than 5 minutes, keep the existing policy of aligning wake ups from timers on 1-second intervals.

Are they referring to the DOM functions setTimeout and setInterval? How exactly are those handled on these circumstances?

I imagine to have a setInterval for every 5 seconds that will be modified to 60 seconds as soon as the tab is hidden for 5 minutes. Doing the same for setTimeout might cause many jobs to run at the same time when returning to a tab. Skipping those could break logic, so simple job queues could cause other issues in the website.

So, how is the feature working, exactly? And, how can a developer make sure their logic won't break while the throttling is active?

Martin Braun
  • 10,906
  • 9
  • 64
  • 105
  • 2
    "*Skipping those could break logic*" - no, any logic using timers must always [deal with being delayed](https://stackoverflow.com/a/10740558/1048572) anyway. – Bergi Nov 14 '20 at 17:23
  • @Bergi _being delayed_ is not _skipping_, those are two different things. I agree with your points that no developer should ever rely on a timer being run at the right time, but I wasn't aware that a timer could be canceled by the host in normal circumstances, which this feature applies to do in the future. – Martin Braun Nov 14 '20 at 17:53
  • I thought you were referring to a queue implementation skipping jobs. No, timers should never get cancelled, I don't see how you got that. "Throttling" means "delaying" here. Can you link to the full article you were quoting from? – Bergi Nov 14 '20 at 17:54
  • @Bergi No, I didn't quote something in regards of "skipping". My point is: If timers aren't skipped / canceled, but instead delayed, they can cause a huge bottleneck if different timers wake up in that throttled time frame. If those are delayed, they will fire at the same time when you return to the tab or the minute time frame is over. This does not seem to be right to me, either. I wish to get a deeper explanation what throttling is doing, **exactly**. – Martin Braun Nov 15 '20 at 17:00
  • I'm not sure why you're calling that a bottleneck. It's actually the desired behaviour: running multiple timers at once is more efficient than waking up multiple times intermittently. – Bergi Nov 15 '20 at 17:03
  • *"Doing the same for setTimeout might cause many jobs to run at the same time when returning to a tab."* Are you thinking about recusrive setTimeout calls to perform an interval? There will always be only the same number of such loops running at one time: the next call won't get scheduled before the last one fired. So no risk of a bottleneck here. If you are talking about scheduling preemptively in a loop enough timeouts for it to be a problem, then just don't do that, it's bad with or without throttling. – Kaiido Nov 16 '20 at 01:34
  • @Bergi I called it a bottleneck, because I was thinking on the case that i.e. 5 (intensive) different tasks fire within one minute, now they will all fire at the same time when the minute is over. But this is all bad design nonetheless. I'm not doing that, of course (so don't worry, @Kaiido), but I am asking in a general matter, there might be ton of websites that follow such bad practices, so I was wondering what I have to expect by poor designed websites when turning on this feature, already. I really welcome the reduced battery drain that comes with it, though. – Martin Braun Nov 17 '20 at 13:38
  • 1
    [This document](https://docs.google.com/document/d/11FhKHRcABGS4SWPFGwoL6g0ALMqrFKapCk5ZTKKupEk/view) (linked from [the announcment post](https://blog.chromium.org/2020/11/tab-throttling-and-more-performance.html)) has more details – Bergi Nov 20 '20 at 13:15
  • You can use push equivalent like SSE or WEbSocket. https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#state-polling – Evgeny Ivanov Mar 11 '22 at 07:15

1 Answers1

2

It is what it says on the tin: background and hidden tabs don't get to run JS timers at high frequency. The shortest interval allowed becomes a full minute, so that your pages aren't burning through people's battery with code that's doing things that no one's even looking at.

The solution is to write proper page logic, and not run any code at all when no one's looking. This means having a blur and focus handler for your page so that your code can stop and resume things that need to run on timeouts or intervals. After all: if no one's looking, your page "needs" to do nothing, because the entire page is not needed.

Mike 'Pomax' Kamermans
  • 49,297
  • 16
  • 112
  • 153
  • Use [`visibilitychange`](https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API) instead of `blur` and `focus` – Bergi Nov 14 '20 at 17:27
  • Thanks, your solution is right for any stuff that only results in DOM manipulation of the body. But there are other ways to present results of wake-up calls, like playing sound, sending active notifications or updating the title's website. I believe that a developer (who is aware of this feature) can work amongst that, I just would love to know what **exactly** to expect from this feature. _"background and hidden tabs don't get to run JS timers at high frequency."_, so in conclusion, they are just skipped? – Martin Braun Nov 14 '20 at 17:31
  • "The lowest interval" did you mean "smallest interval"? Not a native speaker but IMM "low"/"high" sound more for *frequency* and they have the inverse relation, which makes this formulation quite unclear. – Kaiido Nov 16 '20 at 01:39