Live data from Hacker News

Chrome will aggressively throttle background tabs

blog.strml.net

381–390 of 403 posts

Re: Chrome will aggressively throttle background tabs

#381

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.

> overview

Why do you need an overview? It's like stack frames: you can limit your scope to what you're currently doing. The other tabs represent stuff that's "parked" and you aspire to come back to.

(This is why tabs are better than windows for this, because they maintain a linear order while most systems will re-order window order if you visit the windows)

My tab-opening habits predate tabs, because I was raised on Netscape Navigator with a modem using "open in new window" instead. I would read down a page and open interesting-looking hyperlinks in the background, so I didn't have to wait for them to load. Another advantage of this technique on modems was that I could close down the line and carry on reading.

Re: Chrome will aggressively throttle background tabs

#382

Earlier quoted context omitted.

Note that you can always mute a tab in Chrome, which I suspect would remove the exemption as well.

I wouldn't be so sure. I'd be interested in a definitive answer.

Yes, muting a page means that this page is throttled again.

Re: Chrome will aggressively throttle background tabs

#383

Earlier quoted context omitted.

Icon: "speaker" for audio sites, icon: "Power cable" for background power usage?

Lightning bolt / Zap icon

Already used for amp pages, would be confusing. The power cord is probably the right symbol, probably with an explanation if you hover over it.

Re: Chrome will aggressively throttle background tabs

#384
post #347

Earlier quoted context omitted.

Why should the browser rely on the webpage developer to tell it to not redraw things in a tab that isn't the visible one? The browser by default shouldn't redraw content in a tab that isn't visible. This seems like the most obvious thing in the world.

Because some websites might still need to work when not in focus. E.g. If you are showing animations or videos in a window, but the user wants to answer an IM in another window without interrupting the animations.

But then if you switch windows or tabs, the timer for the animations in the tab that is now invisible can be stopped, surely??

Why redraw an invisible window? In any ordinary paint routine, you query for the invalidated rectangle and only redraw what you must. In the case of pages that are out of view, then nothing needs redrawing.

Processes that are busy doing things they need not (like redrawing on a timer, polling a mouse) is why Apple starting highlighting offenders in macOS (what is hogging the battery??) and why I don't use Chrome on it - it just gobbles power keeping all of those tabs alive.

Hopefully these new changes will help.

Re: Chrome will aggressively throttle background tabs

#385

Earlier quoted context omitted.

I remember looking for a similar Chrome extension, but I think Chrome doesn't provide the appropriate hooks, or something.

Interestingly, Mozilla is trying to move in the same direction by supporting the same extension APIs as Chrome because they are more maintainable/secure/universal/performant but continue to struggle with adoption because things like the Tree Style Tabs extension are not possible with that api https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...

And it sucks because it's the only reason I'm not moving to Chrome -- Tree Style Tab.

Re: Chrome will aggressively throttle background tabs

#386
post #206
post #120

Earlier quoted context omitted.

Not if you use Tree Style Tabs. I've been using it for years and I have no idea how other people can efficiently browse the web without it.

With Tree Style Tabs I just got to the same level of disorder with even more tabs open. It didn't actually help my behavior :)

Even by using nested tabs?

Re: Chrome will aggressively throttle background tabs

#387

Earlier quoted context omitted.

Just wait until background junk audio is included in a framework. We'll never be rid of it.

I think you'll have to wait a long time. I doubt it'll ever happen.

There is now an incentive to do this, so it will happen. Same as "with popup blockers everywhere, popups are now replaced with HTML5 above-content layers."

Re: Chrome will aggressively throttle background tabs

#388

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…

On the other hand, it gives us video ads that stop and resume when tabs are switched.

Re: Chrome will aggressively throttle background tabs

#389
post #347

Earlier quoted context omitted.

Because some websites might still need to work when not in focus. E.g. If you are showing animations or videos in a window, but the user wants to answer an IM in another window without interrupting the animations.

But then if you switch windows or tabs, the timer for the animations in the tab that is now invisible can be stopped, surely?? Why redraw an invisible window? In any ordinary paint routine, you query for the invalidated rectangle and only redraw what you must. In the case of pages that are out of view, then nothing needs redrawing. Processes that are busy doing things they need not (like redrawing on a timer, polling…

OP here. In my case, the CPU saved was mostly React updating its virtual DOM. Yes, the browser doesn't do repaints when the tab is in the background. But there's plenty of other work that is done before repaints when using a library like React.

Re: Chrome will aggressively throttle background tabs

#390

Earlier quoted context omitted.

Well, you’d typically want to do visual updates when document.hidden wasn’t true, which would work fine.

He probably meant `(browser.hidden === false)` which wouldn't work if browser.hidden is undefined. Use == instead of === and it will work fine.

No, the opposite of that. If document.hidden === undefined, you don't want to use this optimization at all. What I was saying is, if you initialize doVisualUpdates as "document.hidden === true", in the case where it's undefined, you will never do visual updates.
Post reply on HN