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

221–230 of 403 posts

Re: Chrome will aggressively throttle background tabs

#221

Post by dajohnson89 »

pkamb wrote: post #216
ysavir wrote: post #196

Earlier quoted context omitted.

Not the greatest solution, considering Pinning isn't documented anywhere and most Chrome users have no idea it exists. Which is a shame, as pinning is probably my favorite browser feature.

I'd use Pinning a lot more if it didn't shrink the tab down to its Favicon size. Wish it would also prevent you from closing the tab.

+1. I just now found out about it. Tried it, saw the tab reduced to a favicon, and will probably never use it till that's fixed. Especially with how a Gmail Tab blinks when I get a hangout message.

Re: Chrome will aggressively throttle background tabs

#223

Post by bluGill »

tyingq wrote: post #119
koheripbal wrote: post #91

Earlier quoted context omitted.

A common use-case is tabs that are streaming music. I'm not sure if most users are even aware of pinned tabs.

They are making an exception for tabs that are playing audio. You can see the discussion back and forth, here: https://groups.google.com/a/chromium.org/forum/#!topic/blink... I can see where that will end up though. Everyone who's app was broken by this change will start playing zero volume audio, then the exception will be yanked back. With the web poised to be the new platform for applications, there really needs t…

No tab should get the audio exception unless it started playing audio while I was looking at it. (reopen yesterdays tabs counts as looking at it...) If you play audio to get around throttling - you should get zero CPU, not just throttled. If you have work to do in the background that is fine - there is legitimate work to do. However once you are playing audio it must mean the other work is done.

What do I know though? I don't normally listen to audio on the web...

Re: Chrome will aggressively throttle background tabs

#224

Post by srigi »

ysavir wrote: post #196
mjburgess wrote: post #187

Earlier quoted context omitted.

Pinning a tab should disable throttling. Gives user straightforward control over which tabs are important.

Not the greatest solution, considering Pinning isn't documented anywhere and most Chrome users have no idea it exists. Which is a shame, as pinning is probably my favorite browser feature.

I like the idea of pinned tab, but since they cannot be moved freely it is only halfway useful for me.

Re: Chrome will aggressively throttle background tabs

#225

Post by srigi »

webwalker wrote: post #203
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…

> In response to concerns voiced we will disable aggressive throttling when active websocket connection is present. Does this extend to SSE?

+1 for active SSE connection as an another signal

Re: Chrome will aggressively throttle background tabs

#226

Post by STRML »

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.

Re: Chrome will aggressively throttle background tabs

#227

Post by tyingq »

bluGill wrote: post #223
tyingq wrote: post #119

Earlier quoted context omitted.

They are making an exception for tabs that are playing audio. You can see the discussion back and forth, here: https://groups.google.com/a/chromium.org/forum/#!topic/blink... I can see where that will end up though. Everyone who's app was broken by this change will start playing zero volume audio, then the exception will be yanked back. With the web poised to be the new platform for applications, there really needs t…

No tab should get the audio exception unless it started playing audio while I was looking at it. (reopen yesterdays tabs counts as looking at it...) If you play audio to get around throttling - you should get zero CPU, not just throttled. If you have work to do in the background that is fine - there is legitimate work to do. However once you are playing audio it must mean the other work is done. What do I know though…

I think they are somewhat stuck with conflicting goals. Online games, for example, play audio while doing other work. But it's probably reasonable to pause everything, including the audio, if you move away from the tab.

On the other hand, if they are using Pandora or similar, the end user probably wants the background tab playing and doing other work (showing current album cover art or whatever so it's there if you switch back to that tab).

Re: Chrome will aggressively throttle background tabs

#228

Post by kuschku »

euyyn wrote: post #200
dumbmatter wrote: post #145

Earlier quoted context omitted.

In some ways it's limiting, but overall it's a good thing. Less complexity, less network transfer, works offline, etc. It's just more challenging to do in JS/HTML than in your choice of traditional desktop app dev tools.

GMail and Google Docs work offline too. Surely with things like Firebase it's less complex than inter-tab communication?

Oh, you’re volunteering to pay for it? How nice of you!

Cost is a real concern for these things. The tradeoff is running things on client or expensive backend or spending ages building a custom, efficient backend.

Re: Chrome will aggressively throttle background tabs

#229

Post by nialv7 »

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…

What about split the simulation into small, < 30 seconds chunks?

Re: Chrome will aggressively throttle background tabs

#230

Post by codazoda »

chrissnell wrote: post #212
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…

If a page signals it's desire to opt-out of aggressive throttling, the user should be notified of this, perhaps by an icon in the tab, so that we can either close it or force the throttling. I'm a laptop user and CPU-hungry background tabs are a huge drain on my battery life. If something is opting out of or otherwise excluded from throttling, I want to know about it. Thanks.

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.
Post reply on HN