Hacker News new | comments | show | ask | jobs | submit login

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 disable aggressive throttling when active websocket connection is present. Tabs playing audio are already unthrottled.

We will also consider more signals to use in exempting a page from this throttling: metatag, pinned tabs, permission to show notifications from user. Please leave a comment in the bug (crbug.com/650594) if you have other suggestions.

Looking forward to your feedback, Alexander.




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.


To be honest neither is slack. They've got push notifications through web service workers. What for would they need aggressive background activity?

I'm not saying this to be pedantic, just trying to nip this entitled vendor mentality in the bud. "We're important so give give give without asking." It's a bit what you see with permissions on mobile: the more famous a company is, the more brazen a permission policy they can get away with. It's only tangentially related actual functionality of the app.

This is not about you personally, by the way, but about vendors. You just shouldn't let them get away with it. Even if they're slack :)


Bingo.

The user ultimately needs to retain control. And I'm especially interested in the exception for audio - that really should be user-controllable, otherwise it just encourages annoying page authors to be even more annoying.


The audio thing works because there is an obvious icon in the tab bar that shows the source of audio, so if developers use it in an annoying way the user can easily respond appropriately.


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


I already stopped visiting sites that had background audio autoplay. I don't think sites will get more traffic if they pick that up.


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."


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.


I don't want to switch to slack and wait several seconds before messages update. I'd rather the state be updated beforehand asynchronously.


While I agree with you in theory, this will only help a small fraction of us techie users. The average user is going to see a new, weird icon on their eBay Auction tab and call their computer company to ask them what it is and if they're being hacked.

When I did support for Apple Care, every single update if it had new or extra icons we always got lots of calls like this.


I'm sure some good UX could alleviate this. Maybe a spinning gear icon? Maybe a battery draining animation? Something to signify, 'this tab is doing some heavy lifting right now'.


It's actually a pretty rational response for someone who is only moderately aware of what is going on in their computer. If they are aware that malware and adware can cause unwanted changes on their computer, perhaps because they've been bitten before, then a new icon -- even one that is easily interpreted (which this one would not be) -- looks scary.


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.


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.


I'd like to see the user better informed of hot (active) tabs. Just like there's an audio icon to help the user track down which tab is making noise, there should also be some mechanism to let the user know that a tab is more active than usual.

I'd recommend a different background color for the tab, except that I'd also like to see (sign in) profiles have distinct background colors to aid the user in keeping their profiles straight.


Color change on the tab would be nice - maybe have it slowly grow more red (and perhaps add an option to change the color as well - for colorblind folks) - then start blinking - then burst into flame...


I think Samsung tried that approach


While I've only seen it once, when I looked at it upon learning of its existence- the Chrome 'task manager' might show CPU usage of each tab. When I look at all the chrome.exe processes in the Windows Task Manager, the CPU usage is clear, but I can never tell which process is which tab. Something like a glowing tab coloration animation would be an unobtrusive informational thing, that would work even when tabs are pinned & too tiny to display a meter type thing inside them. Maybe if there could be a 'pause' button that appears on hover to allow this throttling to be engaged or not. Sounds like something to this extent might be a successful extension, then maybe if it sees broad adoption it could be implemented permanently.


No: the Chrome task manager shows activity per process, not per tab; processes typically have many many tabs lumped together (which undermines the security advantage, particularly as commonly-opened tabs like e-mail tend to end up having at least one instance open in every single process). You can't use this feature to figure out which tabs are using CPU unless you are barely using the web browser in the first place.


Whether or not tabs are in a new process depends on how it was opened. For example, opening a new tab with a control-click or middle-click will result in the new tab share a process with the original, however, right-clicking and selecting "Open in new tab" will result in the new tab having its own process.


I know this, and have even complained about it in the past to Chrome engineers (as it allows an attacker way too much control over getting security sensitive tabs into the same process, further weakening the way overstated security benefits of having separate renderer processes, which is often muddled together with the actual/real benefit of separating processes by capability, as with rendering, networking, windowing, plugins, etc.), but there is also a limited number of processes: as I believe the default is 35, if you have more than 35 tabs open across all windows you are guaranteed to have some tabs sharing a process (by pidgeon hole principle).

Realistically, you just can't use the Chrome task manager to find slow tabs :/. I'd argue that Firefox's recent work in about:performance is actually more useful for this purpose (though isn't very good at dealing with large numbers of tabs that are each using only a small amount of CPU; the real solution to that, though, should just be tab suspension).


This made me picture one of the old school nintendo games where your character starts sprouting flames when on a hot streak. There are times I would like to see flames flying off tabs that are pegging my cpu.


Perhaps the icon could be a spinning fan?


This would be great - and the measurements used to do this throttling could be used to populate that data!


Two outstanding suggestions


> In response to concerns voiced we will disable aggressive throttling when active websocket connection is present. Tabs playing audio are already unthrottled.

The pages that are most aggressive in being a drain on resources, in my experience, are also using websockets to constantly load in new advertising and JavaScript and other garbage. Just "the page has a WS open" should not be enough to keep a page unthrottled without providing the user a chance to change that behavior.


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.


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.


>Not the greatest solution, considering Pinning isn't documented anywhere and most Chrome users have no idea it exists. -- I might say this is precisely why it'd be smart mode of control: Tying a power user-ish granular feature (throttling) to another power user feature (pinning) seems like a bit of self-selective optimization, while being quite elegant in its simplicity.

So, for me, +1 for pinned tabs != throttled.


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.


FYI: You can still close the tab, just not by clicking the (no longer visible) X. This may not fit your use case, but then again it might (I can't remember the last time I closed a tab by clicking instead of with ctrl+w).


he is saying that he wishing pinning tabs _prevented_ the tab from being closed (as opera does). I have closed pinned tabs my mistake before (ctrl+w too many times) and I agree.


Oh, my mistake


+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.


The "reduce to favicon" is my favorite part of pinned tabs: I pin all my slack tabs and other messaging tabs and just watch for the blue dot indicating activity and/or the red circle that indicates a private message (on slack)


> 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


Also there are some sites that don't work well with pinning, including G Suite. I'd love to have pinned tabs for work email, work calendar, personal email, and personal calendar. But every time my session expires, they all get redirected to login pages.


Am I the only one who uses pinning as pseudo-bookmarks? I would rather my pinned tabs be throttled more rather than less.


I do that too, sort of. My pinned tabs are either VK/Facebook messenger, or things I plan on getting to later (interesting software to install, movies to watch, ...)


That's funny... for me the pinned tabs are the ones that are always open (email, Slack, Spotify).


Am I the only one that finds pinning extremely buggy? I try it every year or two and always have the same result: pinned tabs work great at first, but eventually enter a state where tabs cannot be completely unpinned.

Unpinning and restarting my browser brings them right back in pinned state, and it seems like nothing I do short of reinstalling my browser profile corrects this.

I've seen this happen on multiple machines, so I feel like it can't just be me.


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


Including me, thanks for the tip! First time I've ever heard of this feature.


Pinned tabs definitely should be excluded from throttling. Pinning tab for me usually means that I want to keep track of something, which usually is my email, chat client, etc. I don't want to be notified about new email on my phone before I get that notification on PC, which is already happening too often. That's just unnecessary hassle.

Though I'm not sure how popular this feature is and I would vote for other ways to turn throttling off, especially for those which prompt user about it.


> 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).


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.


Tabs playing audio will include a lot of people listening to music on youtube.


Exactly. There are a few obvious things that want to be allowed and many others (sites playing adverts and such) that don't.

White-listing youtube would be one click for ever (potentially) and the same for other similar sites (vimeo, maybe facebook, ...) - in fact not even that as common sites like that could be on the list by default (as long as there is an easy way to de-list them).


There should be a way to force-enable this for tabs, even foreground tabs. Some sites are just terrible.

I'd also appreciate it if nothing the website can do can override that. If I mute the audio, then it shouldn't be a signal, and you'll want to avoid using signals which the websites can trigger without user action.

Honestly, I'd prefer if there was some way to entirely suspend event processing on a tab, or at least timers.


Hi Alex, I appreciate your work. My macbook air is getting pretty slow and this is the best free performance boost I could ask for. keep up the good work.


> 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


+1 for SSE!


Is this some sort of reaction to Microsoft's over the top desktop ads campaign against Chrome?

Make no mistake, I do believe Chrome could benefit from this, and I do believe what Microsoft is doing is skirting the edge between ethical and non-ethical (okay, I think it's sleazy). But it just seems like a curious coincidence.


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.


In addition to automatically inferred signals, it would be great to give the user optional complete control over throttling as well at a per-tab level. I.e. a switch somewhere that user can freely enable/disable for a given tab to mark it throttled vs. unthrottled, whatever the right terminology would be.


> permission to show notifications from user

I provide notification access to news sites, not sites I want constantly burning my CPU. This is "throttling", not "100% suspending forever", right? There's no good reason to give more CPU to these tabs that might be occasionally wanting to tell me something from the background: as they are in the background that's the only thing they should be doing, and if they are currently doing other things they should have a strong incentive to stop doing all that other stuff when they detect going into the background: there should be no exemption for tabs with notification access.


User should have a way to enforce throttling on all tabs. e.g. I always have my iPhone on low power mode. Its the users choice, not the developers. As much as I hate saying that as a developer.

As an example - I never listen to audio/video in a background tab, but I have to suffer battery loss because of features that I have no plans to use.


The Apple model of asking user for permission when it notices that a background app is reading your location could be a good model to follow. That way, when you notice a frequently battery hogging domain in the background, even if it uses web sockets, etc., you still prompt the user to throttle.


Pinning a tab has the side-effect of shrinking its title bar to just the icon. I use the text on there to communicate alerts / information to users. (Maybe pinned will enlarge if document.title is changed or something don't know never use it). So hopefully there is another way. To me `site settings` `Throttle this site when in the background, Warning: this may slow your machine and consume additional battery resources`

To me the fundamental issue is one of user control. If the user wants the site to run in the background, great. However a lot of times they don't even know that it is and, surprise! the battery is drained, or everything is running slow and it's time to press shift+esc and stare at the jumping percentages in the task manager.

So to that end, communicating what's going on to the users, is I think pretty important so hopefully:

* A Visual Indicator on the tab, similar in spirit to the speaker or red recording circle, that conveys

  1. Tab is fully utilizing its throttle.

  2. Tab has throttling disabled by user-request.
And then to give users control:

* The ability via `site settings` to disable the throttling, however if a site is using excessive background resources, some sort of ui should show indicate such.

(A lot of this would be almost trivial by showing little cpu use bars, with a line where the throttle is, but it might look kind of ugly)

Even though this is going to break some of my apps, I can see a greater good here, and I am 100% for helping out with battery life, and preventing my machine from being some sort of ad network computation shard. So I am fine with this being the default option even though it will break apps I have written. They are mostly in house tools so as long as I can instruct users to override the throttle, provided I am given that option, which it seems like I will be.

I would figure that for larger more public facing devs, the experience might be a bit more tedious. Perhaps a unthrottled-background permission request API can be done. And hopefully for legacy sites that won't be updated, the visual indicators above will clue users in as to fact that the browser is throttling the site. Perhaps ugh I hate even suggesting this, a nag bar could pop up when the user navigates back to the tab to inform them that the site was aggressively throttled.

Anyhow, I am glad you guys are getting out ahead of this, I think this stuff is going to get worse as sites seek to run more code on our machines in ways we cannot easily discern. So I actually don't like that workers / websockets / audio work around aggressive throttling, because the bad actors are just going to use that to burn cpu in the background without the users consent. Hopefully if executed well, with a helpful ui, this can be used to stop any unwanted and often unseen but still felt cpu waste while allowing sites the user actually does rely on to continue working.

ps, I'll cross post this to your tracker as well as you requested, I just know that leaving it here will get more eyeballs from a larger community to give their feedback as well.


Speaking of audio tabs, the mute setting should be inherited. If I have a muted tab and then open a link in a new tab, I should get a muted tab.


+1 for pinned tabs




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: