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

371–380 of 403 posts

Re: Chrome will aggressively throttle background tabs

#371

Post by yAnonymous »

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.

Then you have a fav icon, the page title, possibly a mute icon, a close icon and a throttle icon? The mute icon and page title aren't visible anymore as it is with many tabs open, so adding another icon doesn't sound like a good idea, especially if visibility is important.

Re: Chrome will aggressively throttle background tabs

#372

Post by lexicality »

Zarel wrote: post #249
wutbrodo wrote: post #236

Earlier quoted context omitted.

> Especially with how a Gmail Tab blinks when I get a hangout message. The pinned tab for GMail has a blue dot for "attention needed". Though this is suboptimal because I think it represents both IMs and new mail.

Are you sure that's not an extension? On macOS, at least, it's a very subtle gradient color change animation that's hard to notice.

I get a blue dot on my mac

Re: Chrome will aggressively throttle background tabs

#373

Post by pkd »

kakarot wrote: post #144
baby wrote: 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.

Tree Style Tabs is a nice idea, but I found the balance of aesthetic and speed for me to be with pressing Ctrl+L and then inputting a few letters relating to the open tab I seek, then just pressing Enter and switching to the tab.

You can also type % followed by the query in the search bar to only search within open tabs.

Re: Chrome will aggressively throttle background tabs

#374

Post by minitech »

ErikBjare wrote: post #367
minitech wrote: post #322

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.

`!document.hidden` would work, and it’s what most people would normally write already. `document.hidden == false` would not work; `false != undefined`.

Re: Chrome will aggressively throttle background tabs

#375

Post by dspillett »

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…

> We will also consider more signals to use in exempting a page from this throttling

The main problems I have with background tabs and resource use is advertising iframes on otherwise inert pages. iflscience.com and sometimes imgur.com are two notable offenders here in my experience.

Advertisers will opt of anything that might throttle their content whether they need to or not, without testing if they need to, just in case. so if there is an opt out I expect it to be abused such that this pain point will not go away.

As well as asking if a particular domain should be allowed to unthrottle itself as others have suggested (or instead of if there is a fear that extra UI interactions will confuse the user) perhaps you could only allow it if the top level frame also opts out? This would give control back to the main page maintainer and if used in combination with the prompts could confuse less technical users less (the request for unthrottling comes from a recognised name like iflscience.com not content.idofmachineinfarm.r438957432t43.somecompanyyouveneverheardof.com)

> disable aggressive throttling when active websocket connection is present.

How is "active" defined here? I foresee advertisers opening a websocket that does as little as possible in order to get a prompt-less lifting of the throttle...

> Tabs playing audio are already unthrottled

I'd love to reverse this and punish tabs that play audio in the background! (or to allow for genuinely useful uses, such as message alerts, punish those that play more then 5 seconds of audio in a minute, unless tey are whitelisted).

Re: Chrome will aggressively throttle background tabs

#376

Post by glenscott1 »

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…

This is a great tip. To make it compatible with most modern browsers (Chrome, Firefox, Opera, Safari and MS), you'll need to use the following checks:

        if (typeof window.document.hidden !== 'undefined') {
            hidden = 'hidden';
        }
        else if (typeof window.document.msHidden !== 'undefined') {
            hidden = 'msHidden';
        }
        else if (typeof window.document.webkitHidden !== 'undefined') {
            hidden = 'webkitHidden';
        }

        doVisualUpdates = !window.document[hidden];
reference: https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibi...

Re: Chrome will aggressively throttle background tabs

#378

Post by andybak »

dspillett wrote: post #375
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…

> We will also consider more signals to use in exempting a page from this throttling The main problems I have with background tabs and resource use is advertising iframes on otherwise inert pages. iflscience.com and sometimes imgur.com are two notable offenders here in my experience. Advertisers will opt of anything that might throttle their content whether they need to or not, without testing if they need to, just i…

I think the heart of it is that "using my resources in the background" needs to be 100% opt-in. All webpages should be frozen and use 0 CPU/RAM unless the user grants them permission. I can think of only a handful of sites I would grant this permission to - mainly "apps" such as Google Inbox, Slack etc.

Re: Chrome will aggressively throttle background tabs

#379

Post by swah »

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…

You site is beautiful, very much like HN in the sense of showing lots of information vs following design trends: https://cryptowat.ch/

Re: Chrome will aggressively throttle background tabs

#380

Post by tomaskafka »

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.

The tabs are transient todo list. This is something I need to finish researching, this is a documentation to what I'm working on, these are 3 great articled I want to read in the evening.
Post reply on HN