Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome will aggressively throttle background tabs

blog.strml.net

Post reply on HN
Print view View original

261–270 of 403 posts

Re: Chrome will aggressively throttle background tabs

#261

Post by twic »

humblebee wrote: post #172
blauditore wrote: post #110

Earlier quoted context omitted.

I meet many tab hoarders (always open a new one, never close any, ending up with hundrets), but just can't wrap my head around it! I hate having more than 6-7 simultaneously open because it gets increasingly harder to keep an overview of what you're doing. The same applies for IDE tabs or windows. Too much of them and finding the right one becomes increasingly hard, and losing the thread more likely.

There might be a more effective way to accomplish what I do with many tabs, but it works for me at the moment so I haven't attempted to find a browser plugin or extension to change the behavior. I use many tabs as a stack of pages when debugging, researching, or reading aggregate news feeds (reddit, hn). It usually starts with a Google search or two, in which I open all links I think _might_ be relevant based off of…

I have this pattern. It plays really well with the 'close all tabs to the right' menu option, because once you've found whatever you were looking for, you can nuke all the leftover tabs.

What I'd really like, though, is a 'close all descendant tabs' option.

Re: Chrome will aggressively throttle background tabs

#262

Post by om2 »

therealmarv wrote: post #255
abalone wrote: post #238

As a bellweather, OSX has had something called App Nap for some time, which throttles hidden apps apart from certain activities like playing music or downloading. I would imagine it affects Chrome as well as Safari. Have there been any real problems with that in practice?

Safari, yes. Chrome no. (You can see it in the task manager)

There haven't been problems with it in Safari as far as we know. We also do additional throttling at our level in addition to participating in App Nap on a per-tab basis.

Re: Chrome will aggressively throttle background tabs

#263

Post by Ajedi32 »

MisterKent wrote: post #252
Ajedi32 wrote: post #181

Earlier quoted context omitted.

Seems like the current solution they're advocating for is for sites to do background processing in a [Worker][1]. This seems like a step towards the way things work with mobile apps currently, where the app's main thread gets suspended when its not in the foreground, and background processing happens in separate threads which the user has some degree of control over. Edit: I meant regular `Worker`s, not `ServiceWorke…

Except it should probably be web workers that are unthrottled. However, in the current implementation Web workers do get throttled. Service workers are supposed to be for networking and offline applications, not doing cpu related things. As such, service worker lifetimes are really messy since they don't have real guarantees as to if they will randomly restart.

Yeah, sorry. I keep conflating service workers with the larger concept of web workers. For more intensive tasks you'd definitely use a regular dedicated worker, not a service worker.

Re: Chrome will aggressively throttle background tabs

#265

Post by dhimes »

mjevans wrote: post #209
altimin wrote: post #176

Hi, this is Alexander. I'm an engineer on Chromium team working on scheduling and on background tab throttling in particular. Firstly, I want to make clear that we are not shipping this in Chrome 56. We have enabled throttling as an experiment in beta channel to measure impact and collect feedback from web devs. We will aim to ship it in Chrome 57, subject to further feedback. In response to concerns voiced we will d…

I'd like to see the user better informed of hot (active) tabs. Just like there's an audio icon to help the user track down which tab is making noise, there should also be some mechanism to let the user know that a tab is more active than usual. I'd recommend a different background color for the tab, except that I'd also like to see (sign in) profiles have distinct background colors to aid the user in keeping their pr…

Two outstanding suggestions

Re: Chrome will aggressively throttle background tabs

#266

Post by jankotek »

I am surprised nobody mentioned battery saving mode in Opera. It throttles background tabs similar way, but not so aggressively.

This will be great thing. Right now my Chrome eats about 10% of CPU, mostly Skype, Slack, Calendar... With Opera it is bellow 1% and I get much better battery life.

Re: Chrome will aggressively throttle background tabs

#267

Post by dingo_bat »

fixermark wrote: post #259
dingo_bat wrote: post #182

Why though? I run Chrome on my decently powered laptop and most of the time I am connected to AC power. I want the machine to run as close to full potential as possible. This is not a mobile phone that needs to preserve battery by killing every background process. It's frustrating because no other browser matches chrome in smoothness and bug-free-ness, so I have no option but to tolerate the trademark anti-user behav…

I run Chrome on a decently-powered desktop, and too many tabs can still kill it. This is a good default; too many websites are built under the assumption that they're the only thing open and they have infinite resources to burn. Granted, I'd like to see more configuration options before this hits primetime, but I think it's going in the right direction to force some discipline on pages if the developers don't code it…

> too many tabs can still kill it

"Kill"? Does your desktop stop responding and show a BSOD? How many tabs do you have open when that happens?

I don't know how heavily people use their Chrome but for me, ~50-100 tabs across ~5 windows across 3-4 virtual desktops seems to not hinder my laptop at all. It's very responsive and no crashes. To be honest I've never seen a system getting "kill"ed due to too many tabs.

My usage does not involve many video/audio tabs though. It's mostly lots of text pages and the usual mailboxes etc.

I think browsers should follow a similar paradigm for background tabs as the OS follows for background apps, ie, both have an equal share on resources unless foreground apps start slowing down due to background activity.

Re: Chrome will aggressively throttle background tabs

#268

Post by __jal »

nothrabannosir wrote: post #239
codazoda wrote: post #230

Earlier quoted context omitted.

I agree. I prefer it throttle everything but ask me if a page is important enough. A news site isn't important enough to ask for this but Slack is.

To be honest neither is slack. They've got push notifications through web service workers. What for would they need aggressive background activity? I'm not saying this to be pedantic, just trying to nip this entitled vendor mentality in the bud. "We're important so give give give without asking." It's a bit what you see with permissions on mobile: the more famous a company is, the more brazen a permission policy they…

Bingo.

The user ultimately needs to retain control. And I'm especially interested in the exception for audio - that really should be user-controllable, otherwise it just encourages annoying page authors to be even more annoying.

Re: Chrome will aggressively throttle background tabs

#269

Post by anarazel »

cortesoft wrote: post #126
blauditore wrote: post #110

Earlier quoted context omitted.

I meet many tab hoarders (always open a new one, never close any, ending up with hundrets), but just can't wrap my head around it! I hate having more than 6-7 simultaneously open because it gets increasingly harder to keep an overview of what you're doing. The same applies for IDE tabs or windows. Too much of them and finding the right one becomes increasingly hard, and losing the thread more likely.

When I am doing coding work, I often have a ton of tabs open. I will keep different documentation tabs open to the relevant sections. I will keep some tabs with answers on StackOverflow. My open tabs are kinda like my working memory. I could close them and reopen them as needed, but it is easier to just click a tab then to try to find the thing again. In addition, sometimes the pages I am looking at have dynamic navi…

I don't know whether that exists for chrome too, but for firefox I find tree-style-tabs very useful to organize my open tabs when developing. A top-level tab for the different topics (e.g. one toplevel tab for a project's github issues, one each for the libraries I'm using, one for news,...). Then when switching tasks I can just minimize those.

Re: Chrome will aggressively throttle background tabs

#270

Post by STRML »

artursapek wrote: post #254
STRML wrote: post #226

Earlier quoted context omitted.

Yeah - that's a really great trick! You can also get this somewhat "for free" by batching updates on `requestAnimationFrame`, which never fires when unfocused. https://www.npmjs.com/package/visibility is a nice little package that encapsulates some of the browser compat issues, if you have out-of-date clients.

But if you do this, isn't it possible that you'll queue up tons of re-renders that all go off when the tab comes back in focus? I'm thinking of React for example, where you might re-render a component with updated props several times per second. In my case, I've settled on just not re-rendering at all, and then doing so once with the latest props when "visibility" fires again with document.hidden === true.

This is where batched rendering really comes in handy. For example:

https://gist.github.com/STRML/cc368c46c2d7de8679196e69ddbcae...

The key is, even in your case (with price alerts), you'll still want to tick occasionally, thus the `FORCE_TICK_INTERVAL`.

React's own batching is smart enough to merge the work. For example, before the next tick, one component calls setState() 20 times, another calls it once. Only one rerender will actually be done.

Some more discussion on rAF batching here: https://github.com/petehunt/react-raf-batching/issues/8

Post reply on HN