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

191–200 of 403 posts

Re: Chrome will aggressively throttle background tabs

#191

Post by the_watcher »

mjburgess wrote: post #187
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…

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

I second this. I'm generally a fan of efforts to reduce the CPU usage of background tabs (as one who constantly finds himself with an embarrassing number of open tabs), but I need to be able to control which tabs I absolutely don't want throttled.

Re: Chrome will aggressively throttle background tabs

#192

Post by [deleted] »

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…

[deleted]

Re: Chrome will aggressively throttle background tabs

#193

Post by timdorr »

ogig wrote: post #16

Can't we use serviceWorkers to workaround this? That's what they were created for. I have a webaudio side project that works nicely even on the background using serviceWorkers for timing. I'm hoping it will be the same on 56.

Service Workers are specifically designed to be short-lived and temporary [1]. They should be tied to events coming from the main script, which is subject to these new timing limits in the background. You should check your app against Chrome 56, as you might be in for a surprise.

[1]: https://www.w3.org/TR/service-workers/#service-worker-lifeti...

Re: Chrome will aggressively throttle background tabs

#195

Post by artursapek »

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…

There should be a way to opt out of this per domain, the way a user opts into Notifications API, Webcam API, etc. A website should be able to ask permission to not be throttled this aggressively.

Re: Chrome will aggressively throttle background tabs

#196

Post by ysavir »

mjburgess wrote: post #187
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…

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.

Re: Chrome will aggressively throttle background tabs

#197

Post by ogig »

judah wrote: post #69
ogig wrote: post #16

Can't we use serviceWorkers to workaround this? That's what they were created for. I have a webaudio side project that works nicely even on the background using serviceWorkers for timing. I'm hoping it will be the same on 56.

Can you elaborate? What does service workers give you for your web audio project that doesn't work without service works? I'm curious because I have a HTML5 audio web app that works great, except when running on mobile in the background.

In my project the serviceWorker only has a setInterval that will trigger the main loop.

When the setInterval was in the main code it would slow down, a lot, when the tab was on background. That made the generated music go slow aswell. With the serviceWorker the clock is rock solid, even when the background app can't keep up, the timing is solid.

Re: Chrome will aggressively throttle background tabs

#198

Post by the_watcher »

blauditore wrote: post #110
mcescalante wrote: post #8

It's awesome to see Chrome trying to improve performance for people with many tabs open, which is many of us. I use a LOT of tabs, and the best plugin has been The Great Suspender. Highly recommend it for anyone who wants memory & CPU back and keeps many tabs/windows open at once: https://chrome.google.com/webstore/detail/the-great-suspende...

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.

For me, it's more that I use my tabs as reminders for things I need to do or things I want to read (I know, this is a pretty bad system, and I try to use a better to do list and tools like Pocket on top of tabs, but I always seem to drift back to just tabs simply because it's the lowest effort system for me to ensure I remember). If I'm working, I'll generally just open a new window and keep the tabs I'm actively using there and get to the backlog later.

Re: Chrome will aggressively throttle background tabs

#199

Post by bootloop »

blauditore wrote: post #110
mcescalante wrote: post #8

It's awesome to see Chrome trying to improve performance for people with many tabs open, which is many of us. I use a LOT of tabs, and the best plugin has been The Great Suspender. Highly recommend it for anyone who wants memory & CPU back and keeps many tabs/windows open at once: https://chrome.google.com/webstore/detail/the-great-suspende...

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.

I am a tab hoarder I guess. I use them to organize my work. Every window is a project (right now I have 5 of them) and all the tabs (20-30) are mostly resources I need to fulfill them. If I have completed a project or decided to stop working on it I close the window and get rid of all project related pages at once.

I don't use favorites or bookmarks because usually I don't need a link permanently.

Edit: I actively try not to get too many. If it starts to hide the title/favicon completely I start to close them again until I can recognize them by title without clicking through them.

Re: Chrome will aggressively throttle background tabs

#200

Post by euyyn »

dumbmatter wrote: post #145
xigency wrote: post #111

Earlier quoted context omitted.

The fact that you don't have a backend is the limiting factor here.

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