top | item 13877120

Reducing power consumption for background tabs

160 points| happy-go-lucky | 9 years ago |blog.chromium.org

60 comments

order
[+] joe_the_user|9 years ago|reply
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.

[+] aeontech|9 years ago|reply
Check out The Great Suspender [1] - not quite what you mean, but it basically unloads the tab and replaces it with a bare bones placeholder after it's been inactive for a bit. When you come back to it, you just click the link and it reloads the url that it had. Super handy if you're in the habit of leaving a few windows with a few dozen tabs each laying around, as I do.

[1]: https://chrome.google.com/webstore/detail/the-great-suspende...

[+] e40|9 years ago|reply
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.
[+] Terribledactyl|9 years ago|reply
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.
[+] cmurf|9 years ago|reply
Privacy Badger helps a ton once you go through a dozen sites and it starts blocking ads and trackers.
[+] hueving|9 years ago|reply
>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|9 years ago|reply
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.
[+] woliveirajr|9 years ago|reply
Then after some years will come a Google AMP for background tabs, then there will be complain that it went too far, then .... everything goes in loops. :)
[+] zerr|9 years ago|reply
The Great Suspender is a great plugin to achieve this.
[+] frontier|9 years ago|reply
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-discarde...

[+] bdamm|9 years ago|reply
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.

[+] rtnyftxx|9 years ago|reply
Nice. I also have blocked JS global in Chrome and activate it on a per site basis.
[+] vdnkh|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
Seems that it can be turned off at:

  chrome://flags/#expensive-background-timer-throttling
...though they may eventually remove the flag.
[+] overcast|9 years ago|reply
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|9 years ago|reply
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.
[+] yladiz|9 years ago|reply
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.
[+] teknologist|9 years ago|reply
They were always boasting about building okcupid in C++. Guess they needed garbage collection after all.
[+] alkonaut|9 years ago|reply
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|9 years ago|reply
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.

[+] bri3d|9 years ago|reply
Productivity application clients like a spreadsheet or document editor tend to do best when they can receive commands/updates to the document in the background via something like a WebSocket.

Otherwise, each time you switched tabs to your spreadsheet, doc, slide show, etc., it would have to poll for changes from the server in some fashion, and wait for a response. This gets pretty frustrating when you're trying to do something like copy from one document to another.

[+] mdpopescu|9 years ago|reply
During competitions I sometimes watch two twitch streams in two different tabs, turning just the sound on and off depending on which one is more interesting. (I had up to four open at the same time.)
[+] mcbits|9 years ago|reply
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).
[+] Keverw|9 years ago|reply
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.

[+] Jaruzel|9 years ago|reply
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.

[+] robotmagician|9 years ago|reply
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|9 years ago|reply
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.
[+] abalone|9 years ago|reply
Safari has been doing something like this since Mavericks. Any idea how it compares?
[+] algesten|9 years ago|reply
> like WebSockets

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

[+] zbuttram|9 years ago|reply
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.