Reducing power consumption for background tabs | Hacker News Reader

Reducing power consumption for background tabs

blog.chromium.org

160 pointshappy-go-lucky60 comments

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.

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.

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.

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.

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.

Privacy Badger helps a ton once you go through a dozen sites and it starts blocking ads and trackers.

Still hasn't been released as a Safari extension and that's an absolute must since other browsers murder macOS battery life, often cutting it short by 2-4 hours.

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...

Yeah no,

That just replaces the page with blank placeholder. How hard would it be to replace the page with an image of it's contents?

I was thinking about a plugin.

In my case, that would frequently be 200+ images in the background tabs. Not as cheap as a blank page.

For me, the title, favicon and URL are plenty to identify the page, I think it's a good tradeoff.

Just curious - I wonder why this hasn't been updated since 2015.

I suspect the development is now suspended (heh) in favor of The Great Discarder [1], which uses Chrome's new "discard" api's for improved performance.

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

>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.

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.

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.

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.

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.

Define where "initial page load and rendering" ends for a single-page web application. When the DOM becomes stable at the login screen? After the login? The moment the user starts interacting with the page?

Also, how does one control what set of pages a given permission applies to? Exact URL often will be too limited, entire domain too coarse.

Allowing a page to use lots of CPU after every user interaction may be a way out, but if you do that, you don't need the explicit permission system.

[I also think the way browsers handle those geolocation permissions already is too complex for many users. They will simply learn "click 'allow', and things will work; click 'forbid' and things may break"]

>Define where "initial page load and rendering" ends for a single-page web application

It's not hugely important. It could be DOMContentLoaded + x seconds. It could be onload unless it doesn't fire within a reasonable amount of time. As long as the browser starts throttling within seconds I don't care much about the details. Login is not a concept I find relevant in this context.

>Also, how does one control what set of pages a given permission applies to?

It should apply on a per-domain basis. That may be too coarse in some cases but nothing is perfect. Let's go for good enough.

Why not ask once then remember?

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. :)

The Great Suspender is a great plugin to achieve this.

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.

OneTab is another one to look at. It bundles the tabs into a list instead of leaving them open.

You can also turn tabs into a webpage of a list of links. Very useful for sharing.

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.

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-suspende...

Nice. I also have blocked JS global in Chrome and activate it on a per site basis.

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...

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.

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).

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...

Seems that it can be turned off at:

  chrome://flags/#expensive-background-timer-throttling

...though they may eventually remove the flag.

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.

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.

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.

They were always boasting about building okcupid in C++. Guess they needed garbage collection after all.

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.

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.

Safari seems to be the worst affected for me. I thought maybe it was adblockers or something, disabled all plugins, and still persists.

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

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...

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.

So let the user promote these with pinned tabs. I think that's a reasonable compromise.

Browsers have notification APIs now, from what I've seen. No need to run a full background tab just to handle the occasional notification.

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.

Safari's notifications can use the Apple push notifications server the same way iOS apps do.

Ah, that's pretty cool. Still, I don't think any of the other browsers have it that way, and Safari's desktop market share is ~2%.

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.

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.)

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).

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.

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.

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-c...

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?

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.

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.

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

> like WebSockets

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

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.

Reply on news.ycombinator.com