9 ms·

Reducing power consumption for background tabs

160 points by happy-go-lucky 10y ago

zerr 10y ago
The Great Suspender is a great plugin to achieve this.
- bdamm 10y ago
  This looks nice! As I enabled it, I got the normal warning about "This plugin can view all data" etc, and I started looking for a plugin that can show me what servers plugins are connecting to... it seems there is no such thing. Perhaps time to re-enable little snitch.
  - Filligree 10y ago
    OneTab is another one to look at. It bundles the tabs into a list instead of leaving them open.
    - sudoscript 10y ago
      You can also turn tabs into a webpage of a list of links. Very useful for sharing.
  - DiabloD3 10y ago
    For those who don't know: the warning is on any extension that can read and write to the DOM or the page state. The Great Suspender swaps the entire page out for a placeholder until you re-activate the page.
- kilroy123 10y ago
  This is an amazing tool, IMO. It saves my laptop's battery and memory. A big +1 for the great suspender. Also link for the lazy like me: https://chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg https://chrome.google.com/webstore/detail/the-great-suspende...
- rtnyftxx 10y ago
  Nice. I also have blocked JS global in Chrome and activate it on a per site basis.
- frontier 10y ago
  I have switched to The Great Discarder, by the same developer. Advantages over The Great Suspender: - More memory savings - Compatible with chrome tab syncing - Super lightweight extension that uses no content scripts or persistent background scripts Disadvantages over The Great Suspender: - No visibility on which tabs have been suspended - Unable to prevent a tab from reloading when it gains focus https://chrome.google.com/webstore/detail/the-great-discarder/jlipbpadkjcklpeiajndiijbeieicbdh?hl=en https://chrome.google.com/webstore/detail/the-great-discarde...
  - hawski 10y ago
    Word of warning! I just switched to The Great Discarder from The Great Suspender. You probably want to resume all suspended tabs back, because if you will remove The Great Suspender extension suspended tabs will get closed. Other then that it was what I always wanted from The Great Suspender (or the browser) in the first place.
vdnkh 10y ago
I wish this could be (maybe it already can be?) disabled for environments where I don't care about battery life/power consumption. This change probably saves me a fraction of a cent per month at the cost of a worse web experience (I'm a bit of a tab hoarder).
- gnicholas 10y ago
  Good point, although I find that performance is always an issue—even when I'm plugged in. I'm also a tab hoarder (though more in Firefox, thanks to Tree Style Tabs), and I find that my Mac's sluggishness is always caused by having too many tabs open. Sadly, my workaround has been to quit and re-launch browsers, which presumably has a similar effect to this update. Looking forward to seeing if the new version keeps things snappier...
- erikdesjardins 10y ago
  Seems that it can be turned off at: chrome://flags/#expensive-background-timer-throttling ...though they may eventually remove the flag.
  - joshstrange 10y ago
    Good for debugging an issue for sure but if you do any web-dev I'd shy away from disabling it for fear you might miss something that breaks on one of your sites because of it.
hueving 10y ago
>Tabs playing audio or maintaining real-time connections like WebSockets or WebRTC How long before a "performance best practices" guide suggests leaving a websocket open to ensure snappier page responses when users switch to your tab.
- fauigerzigerk 10y ago
  I had a similar thought. I think browsers should require user permission for a tab to use more than 1% of a core on average.
  - Someone 10y ago
    That would get annoying soon. You won't want your browser to ask for that permission or throttle page layout to use 1% of a single core during page loads or the moment that browser-based shooting game gets lively and requires fast reactions, for example. I think it would be better to give each tab a power budget that, initially, allows it to run for S seconds at full power, and that give it new budget at a rate of x < 100% of max power every second. However, I fear that still won't be enough. The list of heuristics and exceptions could get so long that the resulting benaviour becomes difficult to explain.
    - fauigerzigerk 10y ago
      Initial page load and rendering should be excluded from any quota. After that the browser should automatically throttle and provide an API to let the web app ask for permission to use more CPU, similar to how geolocation works today. I don't see why this should be too complicated from the user's point of view. We're not talking about hard limits or real time guarantees. Browsers have a lot of wiggle room on the implementation side.
      - branchless 10y ago
        Would love this, or the ability to "throttle" similar to limits set on network bandwidth. So many times I come back to my server to find cpu high and it's caused by one or two web pages doing god-knows what. They don't even appear complex pages.
algesten 10y ago
> like WebSockets Does that mean simply using vanilla socket.io means the page will not benefit from this?
- zbuttram 10y ago
  Pretty sure socket.io will be fine unless it falls back to HTTP polling, which iirc it shouldn't do in the newest version of Chrome unless something is misconfigured on one end.
_delirium 10y ago
Extensive previous discussion, from when the feature was first floated: https://news.ycombinator.com/item?id=13471543 https://news.ycombinator.com/item?id=13471543
alkonaut 10y ago
How much benefit is there in doing anything at all on a background tab? Would there be many use cases where simply suspending the background tab threads would lead to a much worse user experience? I wouldn't mind having my background Netflix just stop, or having to wait a few secs for an interval refresh after bringing a tab to front. But seeing as this seems an active area of research and debate I have a feeling that this solution has drawbacks I'm not considering...
- advisedwang 10y ago
  There are use cases such as a webmail client still fetching messages so it can notify (e.g. via browser tab icons), or so that a collaborative editor keeps up with changes. Even consider the typical hackernews demo of a javascript genetic algorithm: you probably want to be able to leave it to run for a while while you do other things without being required to keep the tab visible.
  - r00fus 10y ago
    So let the user promote these with pinned tabs. I think that's a reasonable compromise.
  - chongli 10y ago
    Browsers have notification APIs now, from what I've seen. No need to run a full background tab just to handle the occasional notification.
    - apetresc 10y ago
      Those notification APIs still get triggered by Javascript running in those tabs. As far as I know, there's no equivalent to the mobile notification APIs where there's a single dedicated socket listening to a central server.
      - kalleboo 10y ago
        Safari's notifications can use the Apple push notifications server the same way iOS apps do.
joe_the_user 10y ago
I'd honestly like to be able to "freeze" a page entirely once it fully appeared in the browser window. A good percentage of web pages both take all my CPU and become unreadable halfway through the page. A big factors seems to be that the pages that are built out of layers of active advertising devices - a given advertiser isn't concerned that they're one of ten monetizing devices pasted onto a gvien page. And there's the way pages have disincentive to play nice - a page that barely works with only it open trains users to avoid other pages.
- Terribledactyl 10y ago
  I'm not sure this would have the outcome you'd want. A HN page is simple, loads and the DOM isn't really altered, so no real gain. Some pages alter the DOM significantly just when scrolling, or even wait to request content until you get there. The harmful sites would probably just break, but in a different way.
- e40 10y ago
  Try uMatrix (in Chrome). 95% of sites are readable with no modifications. Videos often don't play, but I consider this a feature not a bug.
  - a3_nm 10y ago
    The problem with uMatrix is that many sites that rely on third-party Javascript will silently fail (i.e., not load, or show a "loading" animation that never ends), so you need to remember to turn it off for such websites.
    - vanderZwan 10y ago
      It helps if you open uMatrix every time, see what third-party CDNs are used, give them necessary permissions but not more (only images if they don't need a script, no cookies unless it's necessary, etc), and put them in the whitelist. It's a bit of work in the beginning but after a while almost all new pages you'll come across will run fine.
- 10y ago
surement 10y ago
For others interested in the performance of Chrome, there is a great chapter on it in The Performance of Open Source Applications: http://aosabook.org/en/posa/high-performance-networking-in-chrome.html http://aosabook.org/en/posa/high-performance-networking-in-c...
overcast 10y ago
Not sure if any of you use "okcupid.com", but a single tab of that site will consume 4-5GB of RAM in a matter of an hour. Eventually grinding the entire browser to a halt, and nearly killing the OS in the process. There is a SERIOUS memory issue on that site, and it's always been that way for me. Safari, Chrome, Firefox on a Mac.
- hermitdev 10y ago
  I don't use okcupid.com, but gmail, for me, leaks ~4KB per second, even under Chrome 57. Years ago I reported the issue, but it remains unresolved, and I've never received a response. It's not clear to me if it's a gmail issue or a Chrome issue. Either way, leaking 4KB per second is not a good thing. I've only had gmail open for about 2 hours, and it's already using about 325MB of RAM - and there's only 5 messages in my inbox.
- teknologist 10y ago
  They were always boasting about building okcupid in C++. Guess they needed garbage collection after all.
  - umanwizard 10y ago
    I doubt the client-side web pages are written in C++ -- they were probably talking about the server, unless you have a source to the contrary.
- yladiz 10y ago
  Maybe Safari handles it differently, but I've left Okcupid on accidentally for hours at a time in the background and I've never noticed anything specifically memory hungry with it.
  - overcast 10y ago
    Safari seems to be the worst affected for me. I thought maybe it was adblockers or something, disabled all plugins, and still persists.
abalone 10y ago
Safari has been doing something like this since Mavericks. Any idea how it compares?
robotmagician 10y ago
Not super familiar with how the components of iPython/Jupyter notebooks function, so I'll go ahead and ask a potentially stupid question: How might this affect notebooks open in tabs that are running tasks in the background?
- goodside 10y ago
  Long-running tasks run on the server, not on the client where JS timers matter. You'd get the same results, just maybe a fraction of a second later.
  - robotmagician 10y ago
    Ah, I see what you mean. Chrome is throttling client-side operations. Because the python kernel of an iPython notebook is running as server-side code (even if that 'server' is local), it couldn't be subject to throttling by Chrome.
Keverw 10y ago
From the linked Google doc: ------------------------------------------------------ Suspend all background tabs (~2018) Fully pause a tab in the background after N minutes unless a web developer states that the tab should continue to run via an explicit opt-out. Remove opt-outs (~2020+) Remove the opt-out and pause all pages. We’ll be able to do this once we’ve (1) ensured that the web platform provides the APIs needed for major use cases and (2) given developers a sufficient deprecation period. ------------------------------------------------------ That sounds a bit scary, and would require a lot of rewriting or refactor existing code. I'm assuming not all the APIs are even ready yet to proactively start doing this already. But sounds like the iOS model, which has it's pros and cons. Probably has a lot of benefits though in the long run. I hope by pause, means if they switch back it resumes instead of reloading/refreshing. Maybe even emit an event to know it resumed, if the app wants to check if new notifications, etc for it's view... Maybe you were filling out a complex game form - losing state would really be sucky if it reloads, instead of resuming.
mcbits 10y ago
It would be nice if page authors (perhaps with user permission) could disable throttling on background tabs in some cases. I made a Morse code tutor with the Web Audio API, and playback breaks as soon as you switch tabs because the timeouts go to 1 second minimum. And it's practically unusable on mobile, even in the foreground, due to the horrible timing and/or excessive audio buffer sizes (not sure which).
Jaruzel 10y ago
Right now WebRTC and WebSockets are not a solution to wholesale replace Ajax based javascript polling; A LOT of established software and hardware HTTP proxies used by large corporates do not support the HTTP CONNECT protocol, and thus WebRTC and WebSockets fail. I have a service that's used daily by a small community of people who are behind such a proxy. The service uses 10 second javascript timeouts to fetch new data from the server - This change in Chrome(ium) is going to totally break it. I do agree that sockets are the way to go, I just don't think the rest of the internet infrastructure is completely there yet.

160 points by happy-go-lucky 10y ago

zerr 10y ago

The Great Suspender is a great plugin to achieve this.

bdamm 10y ago
This looks nice! As I enabled it, I got the normal warning about "This plugin can view all data" etc, and I started looking for a plugin that can show me what servers plugins are connecting to... it seems there is no such thing. Perhaps time to re-enable little snitch.
- Filligree 10y ago
  OneTab is another one to look at. It bundles the tabs into a list instead of leaving them open.
  - sudoscript 10y ago
    You can also turn tabs into a webpage of a list of links. Very useful for sharing.
- DiabloD3 10y ago
  For those who don't know: the warning is on any extension that can read and write to the DOM or the page state. The Great Suspender swaps the entire page out for a placeholder until you re-activate the page.
kilroy123 10y ago
This is an amazing tool, IMO. It saves my laptop's battery and memory. A big +1 for the great suspender. Also link for the lazy like me: https://chrome.google.com/webstore/detail/the-great-suspender/klbibkeccnjlkjkiokjodocebajanakg https://chrome.google.com/webstore/detail/the-great-suspende...
rtnyftxx 10y ago
Nice. I also have blocked JS global in Chrome and activate it on a per site basis.
frontier 10y ago
I have switched to The Great Discarder, by the same developer. Advantages over The Great Suspender: - More memory savings - Compatible with chrome tab syncing - Super lightweight extension that uses no content scripts or persistent background scripts Disadvantages over The Great Suspender: - No visibility on which tabs have been suspended - Unable to prevent a tab from reloading when it gains focus https://chrome.google.com/webstore/detail/the-great-discarder/jlipbpadkjcklpeiajndiijbeieicbdh?hl=en https://chrome.google.com/webstore/detail/the-great-discarde...
- hawski 10y ago
  Word of warning! I just switched to The Great Discarder from The Great Suspender. You probably want to resume all suspended tabs back, because if you will remove The Great Suspender extension suspended tabs will get closed. Other then that it was what I always wanted from The Great Suspender (or the browser) in the first place.

vdnkh 10y ago

I wish this could be (maybe it already can be?) disabled for environments where I don't care about battery life/power consumption. This change probably saves me a fraction of a cent per month at the cost of a worse web experience (I'm a bit of a tab hoarder).

gnicholas 10y ago
Good point, although I find that performance is always an issue—even when I'm plugged in. I'm also a tab hoarder (though more in Firefox, thanks to Tree Style Tabs), and I find that my Mac's sluggishness is always caused by having too many tabs open. Sadly, my workaround has been to quit and re-launch browsers, which presumably has a similar effect to this update. Looking forward to seeing if the new version keeps things snappier...
erikdesjardins 10y ago
Seems that it can be turned off at: chrome://flags/#expensive-background-timer-throttling ...though they may eventually remove the flag.
- joshstrange 10y ago
  Good for debugging an issue for sure but if you do any web-dev I'd shy away from disabling it for fear you might miss something that breaks on one of your sites because of it.

hueving 10y ago

>Tabs playing audio or maintaining real-time connections like WebSockets or WebRTC How long before a "performance best practices" guide suggests leaving a websocket open to ensure snappier page responses when users switch to your tab.

fauigerzigerk 10y ago
I had a similar thought. I think browsers should require user permission for a tab to use more than 1% of a core on average.
- Someone 10y ago
  That would get annoying soon. You won't want your browser to ask for that permission or throttle page layout to use 1% of a single core during page loads or the moment that browser-based shooting game gets lively and requires fast reactions, for example. I think it would be better to give each tab a power budget that, initially, allows it to run for S seconds at full power, and that give it new budget at a rate of x < 100% of max power every second. However, I fear that still won't be enough. The list of heuristics and exceptions could get so long that the resulting benaviour becomes difficult to explain.
  - fauigerzigerk 10y ago
    Initial page load and rendering should be excluded from any quota. After that the browser should automatically throttle and provide an API to let the web app ask for permission to use more CPU, similar to how geolocation works today. I don't see why this should be too complicated from the user's point of view. We're not talking about hard limits or real time guarantees. Browsers have a lot of wiggle room on the implementation side.
    - branchless 10y ago
      Would love this, or the ability to "throttle" similar to limits set on network bandwidth. So many times I come back to my server to find cpu high and it's caused by one or two web pages doing god-knows what. They don't even appear complex pages.

algesten 10y ago

> like WebSockets Does that mean simply using vanilla socket.io means the page will not benefit from this?

zbuttram 10y ago
Pretty sure socket.io will be fine unless it falls back to HTTP polling, which iirc it shouldn't do in the newest version of Chrome unless something is misconfigured on one end.

_delirium 10y ago

Extensive previous discussion, from when the feature was first floated: https://news.ycombinator.com/item?id=13471543 https://news.ycombinator.com/item?id=13471543

alkonaut 10y ago

How much benefit is there in doing anything at all on a background tab? Would there be many use cases where simply suspending the background tab threads would lead to a much worse user experience? I wouldn't mind having my background Netflix just stop, or having to wait a few secs for an interval refresh after bringing a tab to front. But seeing as this seems an active area of research and debate I have a feeling that this solution has drawbacks I'm not considering...

advisedwang 10y ago
There are use cases such as a webmail client still fetching messages so it can notify (e.g. via browser tab icons), or so that a collaborative editor keeps up with changes. Even consider the typical hackernews demo of a javascript genetic algorithm: you probably want to be able to leave it to run for a while while you do other things without being required to keep the tab visible.
- r00fus 10y ago
  So let the user promote these with pinned tabs. I think that's a reasonable compromise.
- chongli 10y ago
  Browsers have notification APIs now, from what I've seen. No need to run a full background tab just to handle the occasional notification.
  - apetresc 10y ago
    Those notification APIs still get triggered by Javascript running in those tabs. As far as I know, there's no equivalent to the mobile notification APIs where there's a single dedicated socket listening to a central server.
    - kalleboo 10y ago
      Safari's notifications can use the Apple push notifications server the same way iOS apps do.

joe_the_user 10y ago

I'd honestly like to be able to "freeze" a page entirely once it fully appeared in the browser window. A good percentage of web pages both take all my CPU and become unreadable halfway through the page. A big factors seems to be that the pages that are built out of layers of active advertising devices - a given advertiser isn't concerned that they're one of ten monetizing devices pasted onto a gvien page. And there's the way pages have disincentive to play nice - a page that barely works with only it open trains users to avoid other pages.

Terribledactyl 10y ago
I'm not sure this would have the outcome you'd want. A HN page is simple, loads and the DOM isn't really altered, so no real gain. Some pages alter the DOM significantly just when scrolling, or even wait to request content until you get there. The harmful sites would probably just break, but in a different way.
e40 10y ago
Try uMatrix (in Chrome). 95% of sites are readable with no modifications. Videos often don't play, but I consider this a feature not a bug.
- a3_nm 10y ago
  The problem with uMatrix is that many sites that rely on third-party Javascript will silently fail (i.e., not load, or show a "loading" animation that never ends), so you need to remember to turn it off for such websites.
  - vanderZwan 10y ago
    It helps if you open uMatrix every time, see what third-party CDNs are used, give them necessary permissions but not more (only images if they don't need a script, no cookies unless it's necessary, etc), and put them in the whitelist. It's a bit of work in the beginning but after a while almost all new pages you'll come across will run fine.
10y ago

surement 10y ago

For others interested in the performance of Chrome, there is a great chapter on it in The Performance of Open Source Applications: http://aosabook.org/en/posa/high-performance-networking-in-chrome.html http://aosabook.org/en/posa/high-performance-networking-in-c...

overcast 10y ago

Not sure if any of you use "okcupid.com", but a single tab of that site will consume 4-5GB of RAM in a matter of an hour. Eventually grinding the entire browser to a halt, and nearly killing the OS in the process. There is a SERIOUS memory issue on that site, and it's always been that way for me. Safari, Chrome, Firefox on a Mac.

hermitdev 10y ago
I don't use okcupid.com, but gmail, for me, leaks ~4KB per second, even under Chrome 57. Years ago I reported the issue, but it remains unresolved, and I've never received a response. It's not clear to me if it's a gmail issue or a Chrome issue. Either way, leaking 4KB per second is not a good thing. I've only had gmail open for about 2 hours, and it's already using about 325MB of RAM - and there's only 5 messages in my inbox.
teknologist 10y ago
They were always boasting about building okcupid in C++. Guess they needed garbage collection after all.
- umanwizard 10y ago
  I doubt the client-side web pages are written in C++ -- they were probably talking about the server, unless you have a source to the contrary.
yladiz 10y ago
Maybe Safari handles it differently, but I've left Okcupid on accidentally for hours at a time in the background and I've never noticed anything specifically memory hungry with it.
- overcast 10y ago
  Safari seems to be the worst affected for me. I thought maybe it was adblockers or something, disabled all plugins, and still persists.

abalone 10y ago

Safari has been doing something like this since Mavericks. Any idea how it compares?

robotmagician 10y ago

Not super familiar with how the components of iPython/Jupyter notebooks function, so I'll go ahead and ask a potentially stupid question: How might this affect notebooks open in tabs that are running tasks in the background?

goodside 10y ago
Long-running tasks run on the server, not on the client where JS timers matter. You'd get the same results, just maybe a fraction of a second later.
- robotmagician 10y ago
  Ah, I see what you mean. Chrome is throttling client-side operations. Because the python kernel of an iPython notebook is running as server-side code (even if that 'server' is local), it couldn't be subject to throttling by Chrome.

Keverw 10y ago

From the linked Google doc: ------------------------------------------------------ Suspend all background tabs (~2018) Fully pause a tab in the background after N minutes unless a web developer states that the tab should continue to run via an explicit opt-out. Remove opt-outs (~2020+) Remove the opt-out and pause all pages. We’ll be able to do this once we’ve (1) ensured that the web platform provides the APIs needed for major use cases and (2) given developers a sufficient deprecation period. ------------------------------------------------------ That sounds a bit scary, and would require a lot of rewriting or refactor existing code. I'm assuming not all the APIs are even ready yet to proactively start doing this already. But sounds like the iOS model, which has it's pros and cons. Probably has a lot of benefits though in the long run. I hope by pause, means if they switch back it resumes instead of reloading/refreshing. Maybe even emit an event to know it resumed, if the app wants to check if new notifications, etc for it's view... Maybe you were filling out a complex game form - losing state would really be sucky if it reloads, instead of resuming.

mcbits 10y ago

It would be nice if page authors (perhaps with user permission) could disable throttling on background tabs in some cases. I made a Morse code tutor with the Web Audio API, and playback breaks as soon as you switch tabs because the timeouts go to 1 second minimum. And it's practically unusable on mobile, even in the foreground, due to the horrible timing and/or excessive audio buffer sizes (not sure which).

Jaruzel 10y ago

Right now WebRTC and WebSockets are not a solution to wholesale replace Ajax based javascript polling; A LOT of established software and hardware HTTP proxies used by large corporates do not support the HTTP CONNECT protocol, and thus WebRTC and WebSockets fail. I have a service that's used daily by a small community of people who are behind such a proxy. The service uses 10 second javascript timeouts to fetch new data from the server - This change in Chrome(ium) is going to totally break it. I do agree that sockets are the way to go, I just don't think the rest of the internet infrastructure is completely there yet.