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

251–260 of 403 posts

Re: Chrome will aggressively throttle background tabs

#251

Post by fixermark »

dumbmatter wrote: post #4

What are we supposed to do about stuff this? Like I wrote a video game https://play.basketball-gm.com/ that lets you open multiple tabs for viewing multiple screens even while simulation is occurring in another tab. But Chrome recently stopped running the simulation if it's in a background tab. Putting my simulation code in a Shared Worker would be nice, except Safari and IE will never support it and it seems likely…

Nowadays, one writes ad-supported mobile games that nobody will pay for. ;)

Would it be possible to just declare "Best played in Firefox?" It's a bit gauche, but if a browser's engine has a behavior that isn't really compatible with what you intend to do, that's the browser's fault.

Re: Chrome will aggressively throttle background tabs

#252

Post by MisterKent »

Ajedi32 wrote: post #181
lucb1e wrote: post #20

I like the change as a general idea but there obviously needs to be a manual override. Like, I don't want websites to access my camera without permission but obviously I want to allow some websites to do that. A similar permission could be used here and is perfectly backwards compatible: 1. a tab exceeds its quota and throttling kicks in; 2. you visit the tab to check why it stopped working; 3. you get a permission p…

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.

Re: Chrome will aggressively throttle background tabs

#254

Post by artursapek »

STRML wrote: post #226
artursapek wrote: post #205

I run a real time charting platform for Bitcoin traders (like those using BitMEX) and the app does a lot of updating/refreshing. I recently learned of the visibilitychange API and managed to make huge improvements in the app's performance when running in the background - on the order of ~75% reduction in CPU usage when running in the background. [1] var doVisualUpdates = true; document.addEventListener('visibilitycha…

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.

Re: Chrome will aggressively throttle background tabs

#255

Post by therealmarv »

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)

Re: Chrome will aggressively throttle background tabs

#256

Post by skilgarriff »

artursapek wrote: post #205

I run a real time charting platform for Bitcoin traders (like those using BitMEX) and the app does a lot of updating/refreshing. I recently learned of the visibilitychange API and managed to make huge improvements in the app's performance when running in the background - on the order of ~75% reduction in CPU usage when running in the background. [1] var doVisualUpdates = true; document.addEventListener('visibilitycha…

If you happen to use React, I built a React component that helps you manage this! :) Hopefully it helps a bit! It also reports whether or not a user is idle, such that you can reduce cpu usage during that as well.

https://github.com/Skilgarriff/react-user-focus

Re: Chrome will aggressively throttle background tabs

#257

Post by Florin_Andrei »

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…

Is this some sort of reaction to Microsoft's over the top desktop ads campaign against Chrome?

Make no mistake, I do believe Chrome could benefit from this, and I do believe what Microsoft is doing is skirting the edge between ethical and non-ethical (okay, I think it's sleazy). But it just seems like a curious coincidence.

Re: Chrome will aggressively throttle background tabs

#258

Post by artursapek »

benjaminjackman wrote: post #237
artursapek wrote: post #205

I run a real time charting platform for Bitcoin traders (like those using BitMEX) and the app does a lot of updating/refreshing. I recently learned of the visibilitychange API and managed to make huge improvements in the app's performance when running in the background - on the order of ~75% reduction in CPU usage when running in the background. [1] var doVisualUpdates = true; document.addEventListener('visibilitycha…

Wow that's a great tip, I did not know about that one, but it's going to be very useful for a UI I am about to start working on. In addition to requestAnimationFrame this could be very handy! Are there any gotchas you have experienced in using this API that I should look out for?

Just look out for this not being supported and make sure your stuff still works. Eg, document.hidden might be undefined so don't initialize like this:

    doVisualUpdates = (document.hidden === true);

Re: Chrome will aggressively throttle background tabs

#259

Post by fixermark »

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 in (especially since there are events to tell when you've gone background).

Re: Chrome will aggressively throttle background tabs

#260

Post by diminoten »

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…

Bookmarks, man!
Post reply on HN