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

271–280 of 403 posts

Re: Chrome will aggressively throttle background tabs

#271

Post by just2n »

artursapek wrote: post #254
STRML wrote: post #226

Earlier quoted context omitted.

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.

Why not limit it to a single render queued with the latest information?

I see this done via debouncing for render operations that happen on repeated events, for instance typing (send query to server, then show matching results in a render of some list).

Re: Chrome will aggressively throttle background tabs

#272

Post by steego »

Personally speaking (That means I'm speaking for myself), I could absolutely care less about the plight of the developer who wants their page to run stuff in the background.

If you really think I should be running something in the background, you should ask Chrome for that permission so Chrome can ask me. If I say yes, then feel free, but no website should have this for free.

Re: Chrome will aggressively throttle background tabs

#273

Post by SapphireSun »

artursapek wrote: post #254
STRML wrote: post #226

Earlier quoted context omitted.

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.

I'm not a graphics expert, but one really easy change to make is a pattern like this:

    _needsrender = false;
    
    function render () {
        _needsrender = true;
    }

    requestAnimationFrame(function hardrender () {
         if (_needsrender) { 
          .... do stuff ....
          _needsrender = false;
         }
         requestAnimationFrame(hardrender);
    });

Re: Chrome will aggressively throttle background tabs

#275

Post by ysavir »

madgar wrote: post #220
pkamb wrote: post #216

Earlier quoted context omitted.

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.

Interestingly, I'd never use pinning if it didn't shrink the tab down. I never have any trouble with keeping my tabs ordered, so the main value pinning gives me is the shrinking.

Same here. The shrinking keeps my tabs so much more organized.

Re: Chrome will aggressively throttle background tabs

#276

Post by LeanderK »

skilgarriff wrote: post #256
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

i don't know anything about React, but why can't react itself try to manage this?

Re: Chrome will aggressively throttle background tabs

#277

Post by chowyuncat »

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…

allow_exception = volume < audible_threshold

Re: Chrome will aggressively throttle background tabs

#278

Post by Oblouk »

MisterKent wrote: post #252
Ajedi32 wrote: post #181

Earlier quoted context omitted.

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.

I am having a hard time finding where it states that web workers are treated the same as threads managing visual content. Currently timers in background threads are throttled to 1sec minimum interval however workers are not bound by this constraint. I may just be missing something, but I sure hope not. This would adversely impact many games and applications rendering many of them unusable without the web worker exclusion.

Re: Chrome will aggressively throttle background tabs

#279

Post by STRML »

LeanderK wrote: post #276
skilgarriff wrote: post #256

Earlier quoted context omitted.

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

i don't know anything about React, but why can't react itself try to manage this?

React is in the business of limiting its API surface, not increasing it. I think they have done a great job of it - libraries like this should exist in userland.

Re: Chrome will aggressively throttle background tabs

#280

Post by blauditore »

visakanv wrote: post #177
blauditore wrote: post #166

Earlier quoted context omitted.

Yeah, I basically do the same thing, but that hardly ever requires 10 tabs for me. When that happens, finding tabs becomes especially harder once their width starts to shrink. As for read-later, I usually pull them into the bookmarks bar (top level, directly visible) to free up some space.

I use one-tab.com; works fantastically for me. Not a huge stretch to say it changed my life.

For what it's worth, there's a similar feature currently available in Firefox Test Pilot: https://testpilot.firefox.com/experiments/tab-center
Post reply on HN