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,
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.
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 :)
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.
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'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.
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).
So, for me, +1 for pinned tabs != throttled.
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.
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.
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.
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).
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).
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.
Does this extend to SSE?
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.
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.
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.
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.
* 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.