7 ms·

Tab throttling and more performance improvements in Chrome M87

59 points by headalgorithm 6y ago

miohtama 6y ago
Any way to disable this background tab throttling for web apps, or detect its presence and warn users?
Cactus2018 6y ago
> We investigated how background tabs use system resources and found that JavaScript Timers represent >40% of the work in background tabs. ... Beginning in M87, we’re throttling JavaScript timer wake-ups in background tabs to once per minute. This reduces CPU usage by up to 5x, and extends battery life up to 1.25 hours in our internal testing. We’ve done this without sacrificing the background features that users care about, like playing music and getting notifications.
- brundolf 6y ago
  ...what in the world are all of those background timers doing? Polling for things like element visibility or something? I rarely have use for timers, especially now that CSS animations are available everywhere
  - rasz 6y ago
    things like this: var tid = setInterval(function() { var bef = new Date().getTime(); debugger ;var af = new Date().getTime(); if (af - bef > 100) { clearInterval(tid); window.location.href = "/"; } }, 100);
    - brundolf 6y ago
      So, what... as soon as you open your dev tools you go into debugging mode in this random spot? Is this something people actually do? Especially on production?
      - rasz 6y ago
        https://x-c3ll.github.io/posts/javascript-antidebugging/ https://x-c3ll.github.io/posts/javascript-antidebugging/
  - chhamilton 6y ago
    (Chromium dev here) Yes, lots of sites are written with tight setInterval/setTimeout loops, checking for modifications to the DOM, visibility, doing animations, etc. In most cases there are modern web APIs that do these things for you that don't require polling (rAF, MutationObserver, IntersectionObserver, etc). Throttling is mostly about reducing the impact of these sites. We are not trying to penalize well-written sites, and if you have valid use cases that you feel are being unfairly penalized we're more than happy to accept feedback!
    - brundolf 6y ago
      Thanks for the added context! That makes sense. I've debugged one or two hastily-assembled marketing sites in my time and I've seen some atrocious practices along these lines. At one time you could charitably write it off as maximizing browser support, but much of it can't really be explained that way anymore. It's a shame that sites like these drag down the web experience as a whole.
etaioinshrdlu 6y ago
I wonder if this could cause background tabs to develop a large queue of unprocessed events, thus making the tab unresponsive for a while when switching back to it. I used to see this happen on native apps on macOS with App Nap for a while but it seems better on recent versions of macOS.
- antihero 6y ago
  I see this with the console at least when developing. You switch back to the tab and the console eats shit and locks up because of the back pressure.
  - asah 6y ago
    the nice thing with the web is that developers respond reasonably fast (much faster than desktop apps) to changes like this in major browsers...
- imtringued 6y ago
  This a good point. The application does x amount of work per second in the background. Your browser pauses it for y seconds. According to Google you have saved "x times y times energy per operation". Chrome devs say hurray 5x energy savings. Except when you switch back to the tab you end up spending the same amount of energy to catch up. The primary source of energy savings would be poorly written websites that constantly poll in the background. Games with complicated logic would still consume the same amount of energy.
  - chhamilton 6y ago
    (Chromium dev here.) For the most part, events can't really accumulate, because not running code means no new events are posted. The throttling applies to setTimeout/setInterval, and not to any external event (incoming network data, API callbacks, etc). Sites that legitimately have to do a fixed amount of work per unit time (via timers) will simply do that work with 1 wake-up per minute. All things being equal, this still means less battery usage because energy usage is a function of both wakeups and total CPU usage. > The primary source of energy savings would be poorly written websites that constantly poll in the background. This is the key insight here, and really what we're going after. There is a lot of this on the web.
ravenstine 6y ago
This seems like a good idea because APIs already exist to detect whether a page has been backgrounded, so it should be simple enough for a JS app to cease creating timers when they aren't necessary. (Since I'm guessing a lot of timers get created for the purposes of visual reactivity) https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API?redirectlocale=en-US&redirectslug=DOM%2FUsing_the_Page_Visibility_API https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibi... I wonder if this would effect Web Workers in the same way.
Aardwolf 6y ago
Does anyone know how to correctly deal with these paused tabs for computing incremental games with timer based events? It claims that it still ticks timers once a minute for background tabs, but I can measure that it ticks exactly zero times for background tabs (and from now on also for foreground tabs that are occluded...), and in addition may also lie in results of Date.now(). So what does the article even mean by "once per minute"? If I put a tab in background, it immediately stops any tick, if I bring the tab back in the foreground 24 real life hours later, it'll have been 24 real life hours since its last update, not one minute, as I can see by printing events in the console. That makes it difficult to correctly update how much resources were produced in the game, etc....
- fabian2k 6y ago
  You can never rely on the timers firing exactly as you request, so you always have to take the delta since the last timer and use that in your calculations. This is a very basic issues with doing stuff on a timer, and not that hard to do properly. It shouldn't make a difference if your timer is called once per second, once per minute or once in 10 hours in the background, you always calculate based on the delta to the last time your timer fired.
  - Aardwolf 6y ago
    It can be an issue if the game can do complex actions at any time: if you then need to do all of it in one gigantic update after e.g. 24 hours of being in the background, it may take too long to compute that one long tick. Depending on what type of game it is. If it just has to compute "so many resources per second produced" it's easy of course and you can use the delta between last tick (if Date.now() works correctly), but if the game can auto-build various things with complex interactions, it can become computationally complex if it has to do all at once.
    - intellix 6y ago
      It sounds like the tab throttling is working as intended then. If I've moved from your game and haven't looked at it then why shouldn't all of that extra computation happen until the next time I'm interested?
jeffbee 6y ago
Sometimes I put a tab away because I don't want to watch whatever stupid animation it wants to do. When I switch back to the tab later, I want it to be done fucking around. With this change that's not going to work, right?
Cactus2018 6y ago
If you are looking for a way to deal with a multitude of Chrome tabs, I recommend the Chrome extension The Great Suspender, which suspends tabs after x minutes.

59 points by headalgorithm 6y ago

Any way to disable this background tab throttling for web apps, or detect its presence and warn users?

Cactus2018 6y ago

> We investigated how background tabs use system resources and found that JavaScript Timers represent >40% of the work in background tabs. ... Beginning in M87, we’re throttling JavaScript timer wake-ups in background tabs to once per minute. This reduces CPU usage by up to 5x, and extends battery life up to 1.25 hours in our internal testing. We’ve done this without sacrificing the background features that users care about, like playing music and getting notifications.

brundolf 6y ago
...what in the world are all of those background timers doing? Polling for things like element visibility or something? I rarely have use for timers, especially now that CSS animations are available everywhere
- rasz 6y ago
  things like this: var tid = setInterval(function() { var bef = new Date().getTime(); debugger ;var af = new Date().getTime(); if (af - bef > 100) { clearInterval(tid); window.location.href = "/"; } }, 100);
  - brundolf 6y ago
    So, what... as soon as you open your dev tools you go into debugging mode in this random spot? Is this something people actually do? Especially on production?
    - rasz 6y ago
      https://x-c3ll.github.io/posts/javascript-antidebugging/ https://x-c3ll.github.io/posts/javascript-antidebugging/
- chhamilton 6y ago
  (Chromium dev here) Yes, lots of sites are written with tight setInterval/setTimeout loops, checking for modifications to the DOM, visibility, doing animations, etc. In most cases there are modern web APIs that do these things for you that don't require polling (rAF, MutationObserver, IntersectionObserver, etc). Throttling is mostly about reducing the impact of these sites. We are not trying to penalize well-written sites, and if you have valid use cases that you feel are being unfairly penalized we're more than happy to accept feedback!
  - brundolf 6y ago
    Thanks for the added context! That makes sense. I've debugged one or two hastily-assembled marketing sites in my time and I've seen some atrocious practices along these lines. At one time you could charitably write it off as maximizing browser support, but much of it can't really be explained that way anymore. It's a shame that sites like these drag down the web experience as a whole.

etaioinshrdlu 6y ago

I wonder if this could cause background tabs to develop a large queue of unprocessed events, thus making the tab unresponsive for a while when switching back to it. I used to see this happen on native apps on macOS with App Nap for a while but it seems better on recent versions of macOS.

antihero 6y ago
I see this with the console at least when developing. You switch back to the tab and the console eats shit and locks up because of the back pressure.
- asah 6y ago
  the nice thing with the web is that developers respond reasonably fast (much faster than desktop apps) to changes like this in major browsers...
imtringued 6y ago
This a good point. The application does x amount of work per second in the background. Your browser pauses it for y seconds. According to Google you have saved "x times y times energy per operation". Chrome devs say hurray 5x energy savings. Except when you switch back to the tab you end up spending the same amount of energy to catch up. The primary source of energy savings would be poorly written websites that constantly poll in the background. Games with complicated logic would still consume the same amount of energy.
- chhamilton 6y ago
  (Chromium dev here.) For the most part, events can't really accumulate, because not running code means no new events are posted. The throttling applies to setTimeout/setInterval, and not to any external event (incoming network data, API callbacks, etc). Sites that legitimately have to do a fixed amount of work per unit time (via timers) will simply do that work with 1 wake-up per minute. All things being equal, this still means less battery usage because energy usage is a function of both wakeups and total CPU usage. > The primary source of energy savings would be poorly written websites that constantly poll in the background. This is the key insight here, and really what we're going after. There is a lot of this on the web.

ravenstine 6y ago

This seems like a good idea because APIs already exist to detect whether a page has been backgrounded, so it should be simple enough for a JS app to cease creating timers when they aren't necessary. (Since I'm guessing a lot of timers get created for the purposes of visual reactivity) https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API?redirectlocale=en-US&redirectslug=DOM%2FUsing_the_Page_Visibility_API https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibi... I wonder if this would effect Web Workers in the same way.

Aardwolf 6y ago

Does anyone know how to correctly deal with these paused tabs for computing incremental games with timer based events? It claims that it still ticks timers once a minute for background tabs, but I can measure that it ticks exactly zero times for background tabs (and from now on also for foreground tabs that are occluded...), and in addition may also lie in results of Date.now(). So what does the article even mean by "once per minute"? If I put a tab in background, it immediately stops any tick, if I bring the tab back in the foreground 24 real life hours later, it'll have been 24 real life hours since its last update, not one minute, as I can see by printing events in the console. That makes it difficult to correctly update how much resources were produced in the game, etc....

fabian2k 6y ago
You can never rely on the timers firing exactly as you request, so you always have to take the delta since the last timer and use that in your calculations. This is a very basic issues with doing stuff on a timer, and not that hard to do properly. It shouldn't make a difference if your timer is called once per second, once per minute or once in 10 hours in the background, you always calculate based on the delta to the last time your timer fired.
- Aardwolf 6y ago
  It can be an issue if the game can do complex actions at any time: if you then need to do all of it in one gigantic update after e.g. 24 hours of being in the background, it may take too long to compute that one long tick. Depending on what type of game it is. If it just has to compute "so many resources per second produced" it's easy of course and you can use the delta between last tick (if Date.now() works correctly), but if the game can auto-build various things with complex interactions, it can become computationally complex if it has to do all at once.
  - intellix 6y ago
    It sounds like the tab throttling is working as intended then. If I've moved from your game and haven't looked at it then why shouldn't all of that extra computation happen until the next time I'm interested?

jeffbee 6y ago

Sometimes I put a tab away because I don't want to watch whatever stupid animation it wants to do. When I switch back to the tab later, I want it to be done fucking around. With this change that's not going to work, right?

Cactus2018 6y ago

If you are looking for a way to deal with a multitude of Chrome tabs, I recommend the Chrome extension The Great Suspender, which suspends tabs after x minutes.