Chrome will aggressively throttle background tabs | Hacker News Reader

Chrome will aggressively throttle background tabs

blog.strml.net

811 pointscallumlocke389 comments

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('visibilitychange', function(){
      doVisualUpdates = !document.hidden;
    });

Basically, you can use this to determine if your tab is running "in the background" and avoid redrawing/refreshing components to show updates that won't ever be seen.

[1] https://twitter.com/cryptowat_ch/status/817502626896089090

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.

This is where batched rendering really comes in handy. For example:

https://gist.github.com/STRML/cc368c46c2d7de8679196e69ddbcae...

The key is, even in your case (with price alerts), you'll still want to tick occasionally, thus the `FORCE_TICK_INTERVAL`.

React's own batching is smart enough to merge the work. For example, before the next tick, one component calls setState() 20 times, another calls it once. Only one rerender will actually be done.

Some more discussion on rAF batching here: https://github.com/petehunt/react-raf-batching/issues/8

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

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);
    });

Yes, this happens in my browser games. When the user clicks back to the tab it fires off all the frames that have been queued up, moving everything in hyperspeed until it's up to date. I don't really mind though, since it's multiplayer it's supposed to catch up but doesn't need to render when unfocused.

Wow that's a great tip, I did not know about that one, but it's going to be very useful for a UI I am about to start working on.

In addition to requestAnimationFrame this could be very handy!

Are there any gotchas you have experienced in using this API that I should look out for?

Just look out for this not being supported and make sure your stuff still works. Eg, document.hidden might be undefined so don't initialize like this:

    doVisualUpdates = (document.hidden === true);

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

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.

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.

It seems like React could listen for visibilitychange itself to throttle its own events or virtual DOM processing. It wouldn't necessarily need to expose visibilitychange as a library API.

Because there is no sufficient magic for that. App developers have to think about when they do work, how much work they do, and if and when it should be rendered. For any rule you can give, I can give you an example of an app that would break.

In general, the mantra for people who find this tough to fix should be, "Why didn't I use MVC, what a cretin I was!"

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.

It doesn't need to do the final step of rendering - but it still needs to reflow the page whenever you change the DOM, because information from that reflow is accessible to javascript.

It depends on how you define "Visibility changes".

What might he be talking about? Well, it works something like this...

- The app fetches data from a server.

- The data is processed. This may be cheap, or expensive.

- The DOM is updated.

- The page layout is recomputed.

- The browser window is redrawn.

Certainly, the browser could skip the last step for invisible tabs. It can't skip redoing the layout, as the JS can read the computed layout back out; at most it could do the computation lazily, but that would be extra code and complexity. Everything prior to that step isn't under the browser's control.

The web-app coder could act on every single step in the chain, starting by throttling data fetches.

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.

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.

Very nice.

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

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

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

For animations/any sort of render loop, you can also make use of the requestAnimationFrame API, which auto-pauses when the tab is out of focus.

https://developer.mozilla.org/en-US/docs/Web/API/window/requ...

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.

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.

Including me, thanks for the tip! First time I've ever heard of this 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.

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

> 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

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)

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

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.

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

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

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

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

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.

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.

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.

+1 for pinned tabs

> 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!

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.

Two outstanding suggestions

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

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.

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

Perhaps the icon could be a spinning fan?

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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

Seconded. Chrome used to crash ~1/month on me but ever since I started using The Great Suspender I haven't had a single incident and it's been well over a year.

Fantastic tip, thx!

+1 recommendation for The Great Suspender. Works like a charm, noticeable difference on overall system performance.

same here using The great suspender, how does this throttle thing relate to the suspender?

If you are using The Great Suspender, chances are that background tabs are going to be fully suspended so the aggressive throttling isn't even needed.

tl;dr - Great suspender is even "more aggressive" than the outlined throttling, as it fully suspends the page and returns all CPU and RAM to you, so it's a great solution for people interested in throttling background tabs.

I use the GS and love it however I'm not sure it returns even most of the ram. Maybe 50pc. Certainly Javascript CPU usage is reduced however chrome seems to slow down based on how many tabs you have open regardless of what they have in them.

Yeah I just use this. I works very well. Its annoying how much JavaScript pages are running now days.

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.

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.

I don't understand why this seems to only be a thing in Firefox - it's awesome.

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.

How do you get this feature? I know I've seen it, but it's not doing it on Mac Chrome.

Firefox. Maybe chrome has it as well, but Firefox does look like Chrome if you're not looking closely these days.

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

Hmm, looks interesting. I've tried out several tools for organizing tabs, but none of them really worked as well as aggressive manual "garbage collection" for me. Usually the problem was that switching between groups (or whatever concept) was too complicated, or part of the tabs were hidden too much. Maybe I should give this one a try.

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?

If you have to deal with a lot of task switching, blindly closing browser tabs would be a huge waste of time. You can individually check each tab before closing the ones you don't need, but that takes time and cognitive load.

So I leave them open until the computer can't handle it.

Finding the right tab is much harder if you got a whole bunch of them.

I always close them, most aren't needed for a long time.

But if I need stuff I closed I just hit 'reopen closed tab' a few times.

Much easier in Firefox since you just start typing the name of the site then choose to switch to that tab from the drop-down menu. Or you can pick it off the (down-arrow) drop-down list of your tabs, or just use the mouse-wheel to scroll quickly through all the tab headings....

I typically have 100 or so tabs in Firefox. I did get over 600 once, but that's too many ;-)

Well, it's quite similar to garbage collection, or disk defragmentation. It comes with some cost but improves performance, so it's all about finding the best trade-off.

When I am doing coding work, I often have a ton of tabs open. I will keep different documentation tabs open to the relevant sections. I will keep some tabs with answers on StackOverflow.

My open tabs are kinda like my working memory. I could close them and reopen them as needed, but it is easier to just click a tab then to try to find the thing again. In addition, sometimes the pages I am looking at have dynamic navigation, and closing and reopening the page will require a good deal of navigation to find the section I was looking at. Plus, the overall time to reload the content, where if I just have the tab open there is no download time.

Also, the tab icons help me remember what I was looking at. I will often keep tabs open for what I wanted to read later.

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.

I used this years ago, then tried to cure myself of tabs by forcing myself away from it. It didn't take, and I completely forgot about this, going back to The Great Suspender (which is also great). Thanks for reminding me about this!

Thanks, looks interesting! Link: http://www.one-tab.com/

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

Are you taking about tab center? That thingy had a number of issues last I checked, I especially remember there was something weird about the layout of it. I think it extended all the way up on the side of the menu bar. This looked weird to me (and I think UI is overrated) and makes the toolbars slide when I open/close the tab drawer.

I'd recommend using one of the extensions instead.

OneTab can make a huge difference. And being able to do a quick find on your list of old tabs certainly makes things easier for those of us who are, uh, a little over the top when it comes to opening tabs.

The only bad thing is realizing you have a couple hundred old tabs to go through and delete. They really add up over time.

One-tab doesn't sync or let you backup to another source (e.g. Dropbox). I use it, but taking manual backups is a pain.

> June 2016 Update: We're currently working on new features including an option for multi-PC cloud sync. This has taken quite a few months to put together due to the huge number of extension users that the cloud sync will need to support. Thank you for all of your feature suggestions, please keep the feedback coming. -OneTab

With Firefox you just open a new one and start typing part of the title or url and it finds the tab.

If I want to add a new tab instead of finding the old I can press shift (IIRC).

I'm using tabs in exactly the same way. For the read later tabs something like http://www.tabsnooze.com/ might help. I haven't tried it yet, but it sounds good. "Save to Inbox" is another option.

Bookmarks, man!

As I said in my comment, bookmarks don't work for sites with dynamic navigation - you won't end up in the same place when you load the page from a bookmark.

In addition, you have to take the time for the page to load, you have to delete the bookmark later if you dont want to clutter up your bookmarks, etc.

I don't know whether that exists for chrome too, but for firefox I find tree-style-tabs very useful to organize my open tabs when developing. A top-level tab for the different topics (e.g. one toplevel tab for a project's github issues, one each for the libraries I'm using, one for news,...). Then when switching tasks I can just minimize those.

I use my tabs as a task list. I close them once I have read the page, taken action on the knowledge in the page or decided it was too stale to matter anymore.

Same here, unless I am piling search results, which will be reviewed right afterwards, I hardly have more than five open.

On the other hand I rather use native apps, when given the option.

Which I also only keep the ones for the task at hand open.

Probably the same thinking that goes with storing everything on the desktop or having many windows open.

I'm more of a less is more guy, when it comes to windows/tabs.

There might be a more effective way to accomplish what I do with many tabs, but it works for me at the moment so I haven't attempted to find a browser plugin or extension to change the behavior.

I use many tabs as a stack of pages when debugging, researching, or reading aggregate news feeds (reddit, hn). It usually starts with a Google search or two, in which I open all links I think _might_ be relevant based off of what information google can provide me from the results page.

From there I read through each and open any further tabs if anything is linked too in the text (I hardly ever actually click navigate, it's most always a new tab). Generally this only goes about 3 deep (search, first page, sub links). I will close any pages that I find have no useful information, but if there is anything I think might be useful in the next 30 minutes I just leave it open. I do this for each of the results I originally opened. Somewhere in the 7-15 tabs generally is the answer I'm looking for or at least there is enough information I can answer my question. If any link is particularly beneficial, I will bookmark it. Generally the time span I have a large number of tabs open is no more than an hour before I'm finished and close everything out.

Chrome handles this nicely, if you are on a page and open a tab, it will place the new tab next to the current tab, instead of at the end of the tab list. Some sort of tree tab view would probably work much better for this, but Chromes behavior isn't bad for what I do.

For tree tab view, I suggest looking at Tabs Outliner. I can't use Chrome without it anymore.

I have this pattern. It plays really well with the 'close all tabs to the right' menu option, because once you've found whatever you were looking for, you can nuke all the leftover tabs.

What I'd really like, though, is a 'close all descendant tabs' option.

I tend to lean towards tab hoarding. I use Tab Corral to automatically close out old tabs, which works out pretty well. Rather than having to evaluate whether I still need a certain tab up, it quietly closes it after a bit, usually once I've forgotten about it.

Tabs are a todo list. I've currently got two pinned tabs open, JIRA and bitbucket tabs that act as placeholders, one unfinished email, one spotify playlist for work, one podcast, and 6 articles to read. And that's only because I recently restarted Chrome. I can easily have 20+ tabs open if Chrome has been running for a week or two.

For me, it's more that I use my tabs as reminders for things I need to do or things I want to read (I know, this is a pretty bad system, and I try to use a better to do list and tools like Pocket on top of tabs, but I always seem to drift back to just tabs simply because it's the lowest effort system for me to ensure I remember). If I'm working, I'll generally just open a new window and keep the tabs I'm actively using there and get to the backlog later.

I am a tab hoarder I guess. I use them to organize my work. Every window is a project (right now I have 5 of them) and all the tabs (20-30) are mostly resources I need to fulfill them. If I have completed a project or decided to stop working on it I close the window and get rid of all project related pages at once.

I don't use favorites or bookmarks because usually I don't need a link permanently.

Edit: I actively try not to get too many. If it starts to hide the title/favicon completely I start to close them again until I can recognize them by title without clicking through them.

I've given up on navigation.

I use my tabs like a generational garbage collector. Tabs to the left of the current tab are processed, tabs on the right are to-be-processed. I'll go to a page like reddit or HN and spin off a dozen tabs of things to read. Then I'll go through one by one and either process, delay or close.

Once I reach about 250 - 300 tabs, I'll do a longer generation sweep and go through all the tabs and try to get it down to less than 100 or so.

Basically, I'm never in need of finding any specific tab. If I want the content from that tab, I'll just open a new one and navigate back to that point. The tabs are really a lightweight to-read list.

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.

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

I use it like a kind of mental stack or breadcrumb. The tabs most relevant to my current task are on the right, usually no more than three. The rest of the tabs is how I got there, occasionally serving as references. Once I get to the point of making it hard to tell one from the other I tend to do a garbage collection sweep. Sometimes, when switching context, I just reopen Chrome to clear the stack.

Incidentally, the note papers floating around on my desk works in a similar way, although they are more of an unordered set. Only one or two are relevant, the rest were helpful at some point but no longer are. Cleaning my table usually results in me dumping the whole thing in the dustbin.

The combo of The Great Suspender + Session Buddy makes tab management so much better, and easier on resources.

Leave open the tabs you know you'll need soon(ish) and let the Great Suspender throttle them, and save (then close) groups of tabs/windows you won't need right away using Session Buddy.

https://chrome.google.com/webstore/detail/session-buddy/edac...

Any experience on how it compared to The Great Discarder from the same dev? https://chrome.google.com/webstore/detail/the-great-discarde...

The description for that extension in the store explains it pretty well:

"""

Advantages over The Great Suspender:

- More memory savings

- Compatible with chrome tab syncing

- Super lightweight extension that uses no content scripts or persistent background scripts

Disadvantages over The Great Suspender:

- No visibility on which tabs have been suspended

- Unable to prevent a tab from reloading when it gains focus

"""

Unfortunately, I find a lot of sites don't play nice with The Great Suspender. Lots of js-heavy sites would break when they were "resumed", resulting in my place in an article/podcast/video/etc being lost. I'm glad Google is addressing the issue; hopefully they'll do so in a way that's more transparent to the user.

Just white-list those sites.

Is there anything that does the opposite of this? A lot of our current tests run in a browser window, and generally I leave it in the background as I don't want to stare at my tests running. However, when they are backgrounded they slow down and sometimes fail due to timeouts. I haven't actually tried, but does opening a new window get around this even if it does not have focus?

I like the change as a general idea but there obviously needs to be a manual override. Like, I don't want websites to access my camera without permission but obviously I want to allow some websites to do that. A similar permission could be used here and is perfectly backwards compatible:

1. a tab exceeds its quota and throttling kicks in;

2. you visit the tab to check why it stopped working;

3. you get a permission pop up (like all others) once you visit the tab again, asking you whether you want to allow it unlimited resource usage, noting that it'll decrease battery life of your device.

This would be great. At the very least, I'd like the power to un-throttle a tab myself if I decide to do so - even if there's no prompt, it's important to me that I can let a process run full-speed in the background. Losing that would actually decrease the value of Chrome quite a bit for me.

It could also be a permission granted to a Progressive Web App once the user has decided to install it.

Or just ask for the permission when you first open the page, the same way uber asks for your location.

www.foobar.com wants to:

"Run in the background unthrottled"

I really don't want EVERY website I visit to do this (at least in a pop up).

The amount of people that will understand what that means is not very substantial. Usually asking for more permissions confuses users as well, people get permission fatigue.

That's less "backward compatible" than the suggestion to pop up a dialog on switching to the page, because the page needs to know to ask for the permission.

I'm not sure if that's a good thing or a bad thing. After all, backward compatibility is how we got the semantics of an alert() dialog stopping all JS execution.

These days, due to my annoyance with pages reloading themselves when switching to a tab, I'm really not interested in packing more functionality into the whole tab switching mechanism. Like the back button, it should not be visible to web developers.

i don't think that would work.

request for location doesn't require the page to explicitly indicate a desire, the request is triggered if the page attempts to use the location services of the JS API. sites that want to run unthrottled can't be identified simply by the usage of a certain API, so the developer would need to add something explicitly to their markup to indicate the desire.

i want control over the feature regardless of whether or not the site's developer deems it appropriate.

Every website would start showing such popup. Now (if you have enabled Javascript) many sites show popup to allow notifications the moment you open them. That is annoying when you search for something in Google and have to click "No" for every new page opened.

Pinned tabs would be an easy solution for this.

"Don't throttle pinned tabs"

A common use-case is tabs that are streaming music. I'm not sure if most users are even aware of pinned tabs.

I was not, what a great feature!

didn't they remove pinned tabs a while back, and then re-add them?

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 to be some more thought put into how to accomplish that goal. The chrome devs already sunset some solutions in that space, like the HTML5 app cache. Now this. Nobody likes a constantly moving target.

No tab should get the audio exception unless it started playing audio while I was looking at it. (reopen yesterdays tabs counts as looking at it...) If you play audio to get around throttling - you should get zero CPU, not just throttled. If you have work to do in the background that is fine - there is legitimate work to do. However once you are playing audio it must mean the other work is done.

What do I know though? I don't normally listen to audio on the web...

I think they are somewhat stuck with conflicting goals. Online games, for example, play audio while doing other work. But it's probably reasonable to pause everything, including the audio, if you move away from the tab.

On the other hand, if they are using Pandora or similar, the end user probably wants the background tab playing and doing other work (showing current album cover art or whatever so it's there if you switch back to that tab).

allow_exception = volume < audible_threshold

Super high pitch noise would get through?

It still drives me nuts there's no keyboard shortcut for it. `Command + Shift + P` would be sweeeeeeet.

It is silly to need an extension for this, but I don't know what I would do without `Command + Shift + X`

https://chrome.google.com/webstore/detail/tab-pinner-keyboar...

Awesome. Thanks!

I use pinned tabs extensively and I prefer that they are throttled even more aggressively than standard open tabs. As long as streaming doesn't break.

I have an option set in FF's about:config that disables loading of my pinned tabs on startup, so I regularly keep 200-300 tabs open and only activate the ones I need.

Sometimes it takes weeks to clear my tabs because I barely see a performance hit from having so many open.

Unfortunately this doesn't seem to be the way most users are using pinned tabs. Check out the great suspender. The only tabs it does not freeze are the pinned tabs.

Extending that functionality to throttling seems natural to me.

It looks cool. Browser memory isn't too much of an issue for me because I run NoScript and uMatrix and thus most of the tabs I have open aren't each running an instance of Google Analytics and stuff like that.

While this is elegant, its still dangerous. There are online payments that could check whether your booking is complete in the background by periodically firing ajax calls, bulk updates or uploads, etc.

The business decisions a website makes are none of my business, and if they want to use a polling model for billing because $REASONS then that's their problem.

How is that relevant to throttling?

If those sites are using more than 10% of a CPU to do it, then they've made a catastrophic error, and I'd be glad for Chrome to protect my battery from that.

I don't want to have to pin every single tab I want unthrottled - that's a mixing/piggybacking of otherwise orthogonal concerns. Just make it a separate option I can set per tab.

>3.

I swear to god if I see anything mentioning a battery on a desktop machine with no battery...

There's no way to know whether or not it has a battery. Maybe it's on a UPS, for example.

All I know is that my desktop runs at about 70W idle vs. 450W fully-loaded. Unnecessary use of the CPU wastes money regardless of whether or not you're using that money to charge a battery.

Sites can get your battery level from the browser.

IIRC, most of the browsers are going to do away with this functionality soon, however.

Even on a desktop machine, you don't want tabs spinning in the background (using electricity) if you don't need the work being done. That's bad for your wallet and bad for the environment.

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 `ServiceWorker`s.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Worker

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.

Yeah, sorry. I keep conflating service workers with the larger concept of web workers. For more intensive tasks you'd definitely use a regular dedicated worker, not a service worker.

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.

Far enough down this road, we're just reimplementing 'renice'.

... which may actually be the right solution.

What are we supposed to do about stuff this? Like I wrote a video game https://play.basketball-gm.com/ that lets you open multiple tabs for viewing multiple screens even while simulation is occurring in another tab. But Chrome recently stopped running the simulation if it's in a background tab. Putting my simulation code in a Shared Worker would be nice, except Safari and IE will never support it and it seems likely to be deprecated soon. Service Workers kill anything that takes over 30 seconds, so no long running processing allowed. What do I do? Go back to writing desktop apps that nobody will install?

What are you supposed to do? Implement it as a single page application.

It is. But then you open it in multiple tabs, because that's how people use websites.

Unless I'm supposed to re-implement tabs within my single page application and then force it to only let one tab run, which I guess is possible but horrible :)

If it opens in multiple tabs, then it isn't a pure SPA. (Relying on the browser tabs instead of tabs in your application.)

If you have several tabbed views, then you would include tabs in your application.

It is a pure SPA, you just have the option of opening multiple instances at the same time. Like I can open gmail in two tabs, but it's still an SPA.

And yeah tabs in JS are possible and I might go down that route, it'll just be a lot of extra work to replicate a UI that already exists fine.

Here's an example: http://orteil.dashnet.org/cookieclicker/

Opening another tab creates a new bakery, not a view into the same bakery. (This only works if you haven't played before or clear your cookies.)

Edit:

If you really want to keep the same functionality then you would need to bring server communication into the mix. It's possible to either run the simulation server-side, or at least communicate the state between tabs using a server.

If you send an email in one Gmail window and it shows up in the other window, then I would guess it receives a message from the server to update.

The point still being, with this change you can have only one tab doing server communication at "full throttle", which may kill whatever gameplay elements make the players open this game in multiple tabs.

I'm not sure on the Chrome implementation, but I think all of the visible tabs would be foreground, not background. So the issue would be refreshing when changing tabs. (And also communicating between visible tabs).

The last time I played, opening a new tab would create a view into the same bakery, but it each tab diverged based on RNG. This allows you to cheat by, for example, taking multiple risk free chances at wrinkler drops.

Yes? I mean, you have to admit what you built is the epitome of edge case when it comes to how a browser is typically used, and is actually exactly the type of thing they want to optimize because basically if you aren't looking at the tab, it's not being used (generally).

Maybe use electron or something?

I don't think that replacing a traditional desktop app with a web app is an edge case. That's one of the main points of HTML5.

I think what was meant by edge case is how you've architected this. Going by a statement in another comment of yours:

> It is a pure SPA, you just have the option of opening multiple instances at the same time. Like I can open gmail in two tabs, but it's still an SPA.

Gmail just runs the UI in the browser though, the actual work of processing, receiving and sending mail is not done in a tab. The tabs are just views into the system.

It sounds like you are having one tab as both the client and the server, and separate tabs as clients to that other tab, which is pretty edge case.

As someone else suggested, you could move the processing to the server, but I imagine that's not feasible because then you are centralizing the processing and you're paying for processing, not the people visiting.

The more appropriate way to architect this (to my eyes, so take it for whatever you think it's worth) would be to use JS to manage tabs within the application (which you mentioned elsewhere already). The really simple way to implement this might be to have the JS tabs just contain an iframe to the prior implementation's real separate tab URL (since it already works that way, there's not likely to be any security issues you have to deal with).

The way you architected it is uncommon, though. For example, with GMail, that you mentioned as achieving a similar effect, server communication is involved.

Make it a single page thing and spread the image out over multiple desktops. Make it a real desktop app instead. I do think Chrome / Google is (if they go through with this) actively going to fight against using the browser as an application platform though. At the very least they should give notifications to webapps that they are about to go to low-power mode, act differently when on a power cable, and check whether the tab is visible or not.

This isn't a full solution, but perhaps inter-tab communication would work? Use whichever tab is focused as the master, then other tabs send messages to the primary as they need work done. It wouldn't work when none of your tabs are focused, but perhaps that's an acceptable constraint.

That might work, but it's much more complicated and given the issues I'm already facing, I wouldn't want to rely on that communication actually happening (maybe background tab won't be able to send a signal to the foreground tab, since JS is apparently not running in the background tab).

Iframe them onto one page and make the browser window huge. Something like:

    <iframe src="the url" width="50%" height="50%">
    <iframe src="the url" width="50%" height="50%">
    <iframe src="the url" width="50%" height="50%">
    <iframe src="the url" width="50%" height="50%">

There's also the <frameset> and <frame> tags to divide pages between URLs.

chrome regulary breaks something, so we run tested versions of chrome for our internal webapp and block chrome updates.

but chrome does not like that and is always nagging and trying to trick you into installing the latest versions.

i looks like we will have to package it as electron app.

Could you create a tabbed interface that is just a dumb view of a server state communicated over websockets? Then the user could just open the page in n windows (each on its own tab) and have the same state represented in each?

Problem is, there is no server. All client side. So the tab on which you click "run simulation" is effectively the "server", except it stops running when the user switches tabs.

Put two of them in two iframes on the same page? No code changes should be needed

The fact that you don't have a backend is the limiting factor here.

In some ways it's limiting, but overall it's a good thing. Less complexity, less network transfer, works offline, etc. It's just more challenging to do in JS/HTML than in your choice of traditional desktop app dev tools.

GMail and Google Docs work offline too. Surely with things like Firebase it's less complex than inter-tab communication?

Oh, you’re volunteering to pay for it? How nice of you!

</sarcasm>

Cost is a real concern for these things. The tradeoff is running things on client or expensive backend or spending ages building a custom, efficient backend.

There are perfectly legitimate reasons to not have a backend. In fact, if something can be accomplished without user sending his data to some remote server (as opposed to just fetching data from the server), I believe it should be done this way.

As a workaround, in the meantime, have you tried using several windows, not just tabs? Of course, none of them can be minimized, but they can be covered by other windows and should still run.

It would be dodgy hack, but another HN comment made reference to a statement that tabs playing audio are always considered "foregrounded": https://groups.google.com/a/chromium.org/forum/#!topic/blink...

I think I might actually try this lol

...that would explain why flash files with no sound seem to 'pause' (or at least, run very, very slowly) when in a different tab.

Their own Google Play would be impacted otherwise. Good to hear, since the only thing I use Chrome for is Google Play (and any other, one-off, old-fashioned sites which require Flash). Why in the world does Google still require Flash for... anything?

Great, so we can now expect more and more sites to start playing "null" audio as a "workaround".

As a developer you need to decide whether or not to support a browser, and if that browser doesn't provide the APIs you need then you should drop support for that feature in that browser. In this case, if Chrome is making a change that you can't or won't change your game for then the solution is to detect Chrome and display a "This game only works in a single tab in Chrome. Try Firefox!" message if a user opens it in a second tab.

It's your customers that generally dictate what browser you support.

If you don't support a browser, how do you learn whether its users are your customers?

Not if you have content or apps they really want.

I prefer Firefox, but since Google broke Google Voice (now Hangouts) plugin for FF users, I've been grudgingly opening a Chrome browser each time I want to make a phone call to US number.

Some people are in the fortunate position where they can choose to ignore large sections of their potential customer base. Someone who writes a game as (presumably) a side project is in exactly that position.

What about split the simulation into small, < 30 seconds chunks?

Nowadays, one writes ad-supported mobile games that nobody will pay for. ;)

Would it be possible to just declare "Best played in Firefox?" It's a bit gauche, but if a browser's engine has a behavior that isn't really compatible with what you intend to do, that's the browser's fault.

How about displaying more info about the "weight" of a page, when it comes to downloaded assets, cookies / local storage, RAM and CPU usage? I know there are ass backwards and fugly ways to see all of that, but why can't I see a list of all open tabs, with columns of such info which I get to define and sort as I please? Why not have the option to that info pop up when hovering over a tab, and to show notification icons for certain thresholds, user definable with sensible defaults? There's a lot of things browsers should be doing. So what if 100 people don't care; the one person that does become more aware of what is going on more than makes up for it. *

And just let us allow tabs to grab all the resources they want on a opt-in basis. Why not?

* Before anyone brings up the inevitable economic argument - it wouldn't take a lot of man hours to do these things, I dare say it would just take one or two persons who are capable to be willing and allowed to do them. And compared to all sorts of things that browsers vendors made and get scrapped, you at least know tabs will always use ram, CPU and load assets over the network, so it's not ever going to be completely useless.

You do know that Chrome has a task manager that will display memory, CPU and network usage for each tab right?

Yeah, make that "allow docking the task manager". Though I still miss a total about how many bytes got downloaded, average speed etc. I also miss it in other browsers (though I should have made that more clear, I wasn't meaning to "bash Chrome" -- this frustrates me since the departure of old Opera, with all browsers, I love the powerful web API stuff but I hate the user interface directions).

And to repeat myself, I really do miss something akin to the icon that displays which tabs are playing sound -- not for myself, but because it would allow people to notice the difference between bloated and well crafted pages more easily.

I appreciate they prefer to automatically decide what is best, but I would prefer more gauges, at least as an accessible option. If you hide something behind an "advanced" label, it will just scare people off for no reason. It's not like configurations dialog aren't kinda barren and padded as is. Just fix that and then just put things there, neatly categorized and maybe even searchable, and explain them. People can drive cars and vote for politicians, but we can't trust them to read? Just about any image viewer or video player seems to think more highly of people than browsers of all things do.

Yes. The browser is slowly becoming it's own operating system. Like Oracle making a bare-metal version of their database, pretty soon, Google will just skip ChromeOS, bundle Chrome with a storage driver, input driver, and video and sound drivers, and be done with it.

It's not everything you asked for, but as it stands Chrome does have a task manager (Shift + Esc) that shows CPU usage, Memory, and also how the tabs are grouped process-wise.

I know, but you can use Chrome for a million years, and have resource hogging tabs crash your computer, without ever knowing about that. Even ("X seems to be slowing down your computer, press shift+ESC for a detailed breakdown") would help. The point is for abusive sites to stick out and have that imaginary free market, with the rational consumers and their informed decisions, do the rest.

By the by, why we can't switch to a tab from the task manager is a question for the ages.

What I'd like is popping up plain warnings aimed at regular, non-tech user. "These tabs are currently slowing down your computer: <list>." Or, "This tab uses a lot of battery power."

Besides directly providing information that is relevant to a typical user, I'd hope such a solution would finally put some pressure on the companies to optimize their webpages.

This is of course a really good thing, but I feel this is not enough.

The browser has increasingly become universal platform. On the one hand, this means applications written for browsers are automatically cross platform. But this also makes the browsers more and more complicated. Even the simplest webpage takes a significant hit in resource usage.

Maybe we need some sort of "reduced web". A browser that only supports the essential features to display webpages. No WebGL, canvas, notification, WebRTC, locations, WebMIDI, or WebUSB (seriously!). And I don't mean just disable these features, but rather design the browser without them. Then we could do most of our browsing in the minimal browser, and only fire up chrome for the more demanding web apps.

FYWD: https://ello.co/dredmorbius/post/ubkidr7yuc7azg9hdnl7lq

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.

> no website should have this for free.

Why not? Your applications on the desktop can run background tasks without your approval. Your phone's applications on iOS and Android can run background tasks without your approval. The web has tons of web applications some of which more complex than stand alone apps. So why wouldn't they be afforded the same?

Asking would be a bit of a UX nightmare. You'll have so few users enable it. It's a pattern they've never seen before.

Have you figured out the difference between webpages and apps yet? Let me know when you do and we can continue this discussion.

FYI, I switched to iOS because they're much more aggressive controlling about runaway background processes.

They aren't treated the same because web apps are a lot more resource intensive than their desktop counter parts.

> Your phone's applications on iOS and Android can run background tasks without your approval.

Apps on iOS can only do this for a short time interval before they will receive a SIGSTOP and are no longer allowed to execute at all; and while you can react to push notifications, you are given a very limited time interval in which you can do that locally. You can manage downloads in the background, but those are passed off to a dedicated download process to make sure you aren't doing anything complex (as a download should not be a major CPU drain: it is really just something that has to respond to I/O events). You can play audio or track location actively in the background, but the system makes this incredibly obvious by placing an omnipresent and highly intrusive banner at the top of the screen, telling you which application is doing that. You can manage bluetooth devices in the background, but if you are paired with a bluetooth device then the user probably understands what is happening.

Mobile OSes are already throttling and stopping background tabs and applications. Otherwise the battery would be drained in several hours.

This is going to destroy HLS playback in a background tab. Playing back HLS with JS is already a very cpu intensive, time-dependent process and we've already struggled with the current background tab throttling - a delay like this will all but kill playback or make it stutter to the point you'll wish it's dead instead. I commend Chrome for driving web standards but they've been a huge bully recently.

I don't believe it will. From https://groups.google.com/a/chromium.org/forum/#!topic/blink... :

Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded).

Is that a workaround/loophole then? A tab can play silent or very quiet audio and then run unthrottled?

Chrome's audio detection is quite smart if I'm not mistaken. A tiny amount of sound is usually seen as 'silent' too, since it'd be practically inaudible.

I believe users would quickly find that suspicious as Chrome shows you which tabs are playing sound.

One of the first comments on the link above mentions this as a potential exploit; they said they would watch for people attempting it and attempt to mitigate it if it becomes popular.

Can we aggressively throttle memory usage? Why does it require 300-500MB of ram PER TAB?

It probably doesn't. Measuring memory usage is hard on a modern OS.

I'd guess there's a lot of shared memory between tabs

    Measuring memory usage is hard on a modern OS.

Not in the slightest. OS's have to allocate virtual memory to each process or that process with SIG-FAULT when it touches invalid memory.

Tracking per-process memory usage is one of the most trivial things OS/Pref tools do.

Measuring it is easy. Defining it is what's hard. If three processes each have the same 10MB executable mapped into memory, plus 10MB of heap data, how much memory is each process using? There's no easy answer to that question.

    Defining it is what's hard.
    how much memory is each process using?

20MB.

    Oh but they are sharing the pages the executable is mapped into.
    So how can you can you say they are each using that much RAM?

Because that 10MB of RAM won't be freed until the last process exits. Each process is using 20MB of physical pages. If only 1 was running it would use 20MB.

The semantics that each process is sharing 5 HUGEPAGES of heap isn't really important as even if 1 was running alone it uses that much memory.

If you are sharing that much data with executables that you have this problem there is some low hanging fruit for memory optimizations you can do.

     Oh but you aren't *actually* using 60MB of Heap, only 40MB

Indeed. And in cases where these 3 children have the same parent you look at the ParentMem + 40MB (child binary+individual heaps) to report a better picture.

Shared/unshared semantics are not hard. Have you ever read /proc/$PID/maps ? Because it clearly labels what is/isn't shared physically. When you are optimizing for memory usage you rarely look at shared readonly pages as the kernel put them there for you.

   Defining it is what's hard.

Injecting an interpretation before taking a measurement is not sound science or engineering.

Measurements inform Interpretation. Not vice versa.

Sure, shared/unshared semantics are not hard. How do you map that to a generic concept of "usage"? There's no right way to do it.

It doesn't really make sense to ask "how much memory is this process using?" Instead, you want to ask questions like "how much memory are all of these processes using?" or "how much memory would be freed if I terminate these processes?" or "how much extra memory will be used if I start another process?"

What's hard is understanding which question you want to ask in any given situation.

     There's no right way to do it.
     What's hard is understanding which question you want to 
     ask in any given situation.

I don't see the issue. You admit that answering all of these questions is easy. The hard part is lawyering which question to ask.

This is not a data reporting problem.

This is a data interpretation problem.

A good reporting tool should not be interpreting (or forcing an opinion) on the end user.

You believe this problem is hard because you are forcing an interpretation to exist before you take a measurement. When you should not be interpreting until after measurement. Injecting an interpretation into a measurement process fundamentally changes that measurement.

Measurements inform your interpretation. Not the opposite.

TL;DR You put the cart in front of the horse.

"This is a data interpretation problem."

That's what I said. "Defining it is what's hard."

You seem to understand what I'm saying, and agree with me, but insist on arguing for some reason I cannot comprehend.

     You seem to understand what I'm saying
     and agree with me

Literally the opposite. Your initial statement was

      Measuring memory usage is hard on a modern OS.

Which you've agreed was false as /proc/$PID/maps is easy to read. Then said:

      Defining it is what's hard

But these statements are not mutually inclusive nor does the later imply the former.

I stated measuring is literally the simplest thing. You said ah but what you measuring. That isn't dependent on the tools, or OS. So why did you state it was?

Nooooo... somebody else made that initial statement. My initial statement was "Measuring it is easy. Defining it is what's hard."

Are you just arguing with me because you didn't realize I was somebody else?

Yeah, it depends on what exactly you're asking for. But one can provide different visualizations for different questions.

As a typical computer user, this is what I care about:

- who the frak is eating all my RAM?

- which processes should I kill to get some memory back?

Whatever the weird sharing things are going on, the memory is ultimately linear. So show me a large rectangle subdivided into sections, each one representing memory associated with a set of processes. One section for "this memory is used by Chrome.exe". One for "this memory is used by Chrome.exe, X.exe and Y.exe". One for "this memory is free".

When I click on a section, it should highlight all the processes that share this memory. When I click on a process, it should highlight all the sections this process uses or shares with others.

This way, I could quickly see who's wasting my RAM and how many processes do I need to kill to get some chunk of memory back.

> Measuring memory usage is hard ...

Exactly, I usually find that chrome is eating a little more than what it's displayed in task manager in windows ;) I have no idea how it can achieve that to be honest. Restarting it seems to bring back the 5-15% missing ram in my case.

If it doesn't, then why does it grind to a halt eventually on both Mac and Windows? Firefox suffers from the same nonsense as well. In fact, Safari seems to be the ONLY thing I can keep open for more than a day without a process restart.

You're doing something wrong. I use Chrome on Windows as my main now and I usually have more than 100 tabs open. I just switched a few months ago from Firefox on Linux, also usually with 100 tabs or more open. Both are very stable. Chrome is worse with handling tons of tabs, but I certainly don't have daily crashes.

People who have extremely unstable/inconsistent experiences with these platforms usually have a rogue extension or some other problem lurking beneath the surface.

Also consider occasionally VACUUMing your browser's DBs, and on Firefox, taking advantage of the profile reset option.

For every person that has my symptoms, there is someone to counter it. I'm not going to get into an argument about how I'm using my browser incorrectly. Every computer / browser combo I've ever used exhibits the same thing, and I'm pretty religious with keeping things trim and clean.

Using a lot of extensions?

Could be the sites themselves.

Why is it that whenever somebody has a problem that less than 100% of people experience, the response is always "you must be doing it wrong" rather than "I must be lucky"?

Because the quantity isn't just less than 100%, it's a small minority. Chrome and Firefox are among the most widely-used pieces of software in the world. I'm not saying they don't have weird bugs, but they don't crash daily for most users.

While the OP may not be doing anything "wrong", he is almost definitely doing something unusual, or has deeper issues like malware or malfunctioning hardware.

If the ratio were inverted and most users were experiencing daily crashes from normal use, I would consider myself lucky. That's just not been my experience with Chrome/Firefox.

Bugs which only affect a small minority of users don't exist, nor do unusual but perfectly legitimate usage patterns?

You probably want to re-read my post, as I said neither of these things.

You're right. I was confused because in your other comment you just said they were doing something wrong, and I didn't realize you'd reversed course on that.

I would suspect a majority of the world does not keep dozens of tabs open, on an computer that never shuts down. You have to remember which forum you're on here. Any software issue, usually rears its head relatively quickly from one of our machines around here.

That's the use case I'm most familiar with. I've done this on many different machines for many years and not had anything like a crash once a day. I stand by my belief that your negative experiences are likely caused by a rare collision of variables and not representative of the typical experience among similar use cases. As I said in my post, it's totally legitimate that such an atypical experience may be caused by real bugs, but it's still an unfair generalization to say that Chrome and Firefox crash daily.

Does Chrome only use RAM if it thinks it is available? (i.e. if it starts detecting that other process are running and eating up RAM, will it use less?)

Nope - it's fairly happy to choke everything else or even crash (tabs or the browser) when RAM gets too scarce. It does seem to have some capability to restrict usage, but it's not thorough enough to avoid performance/crashing issues.

Not in my experience.

With 4 GB ram, Chrome will happily give ~2GB to any tab that requests it in a couple of seconds, leaving me with an unresponsive Windows aggressively paging memory to disk, only to give whatever it finds... back to chrome

It does try to reduce what it can in low memory situations (less "pre" optimizations like prefetching, prerendering, even dns prefetches and stuff, V8 gets more eager to throw out "potentially unneeded" code, tabs get suspended and written to disk, heuristics can get shut off, etc...), but it can't change what the page does.

If a browser tab wants to store 300MB of data in RAM, or wants to throw a shitton of stuff at the DOM, Chrome needs to oblige.

Firefox on Linux used to many years ago, it even included swap space as available memory.

This is design issue, inefficient data structures, lazy programming etc.

Im affraid tabs taking 2MB(two megabytes for a page with javascript, not 20, not 200, two) like in the good old Opera 12.16 wont come back :(

I agree, the Presto engine was (and still is) super efficient.

We may see something similar come out of the Vivaldi project which is headed by folk who led the Opera <= v12 development who know very well what was lost when Opera moved to Chromium based web engine.

No. Vivaldi like new Opera is just a skinning project. They made UI slightly better, added some missing functionality (mostry tabs and gestures), but they do not touch core engine.

Case in point fresh Vivaldi on startup makes 4 connections to Google just to say hi, and will keep sending google delicious pieces of data throughout the day, not to mention hardcoded google DNS in case yours is too slow. How about spamming my local network with chromecast UDP garbage? or enumerating shares on startup? WTF would you even do that?

Ps I use Vivaldi :/.

I suspect that you know of this already, but here it is anyway: https://otter-browser.org/

Personally I still have Opera 12.18 installed on every computer as it still is the most swiss-army-knife browser out there for countless reasons. Most of the webpages can be made to work properly in it by adjusting the site preferences.

One thing I am yet to see any of the new browsers be capable of is complete popup blocking. Opera 12.x excelled at this and a complete blackout of popups is 100% achieveable.

Why can't Chrome add 'reload tabs only when focused' ??!!!

A simple, trivial feature that's in every browser on Earth, except bloody Chrome.

Its been requested pretty much forever and Chrome takes a perverse delight in ignoring the most requested features, because of course they know better than their users.

other examples - multi row tabs, customizable fonts, and actually giving a damn about memory usage.

Chrome is a memory hog and instead of optimizing that, the solution is to kill background tabs. This is very similar to Android's logic - instead of trying to fix rampant 'Android system' and 'Play services' wakelocks which cause massive battery drain, the fix was to forcefully suspend apps via Doze, which of course ignores the real problem entirely.

Archived copy that doesn't require JS:

https://archive.fo/3ph1z

Awesome service! Thanks for sharing :)

Excellent work! Kind of funny the article mentions

> This will break the web.

But apparently blogger requires javascript just to render static content.

Oh, it's awful, I agree. This is the nicest layout but the JS is terrible.

I've reverted to a plain-HTML layout.

To whoever downvoted this: I am the author of the post above, and in response I've removed the JS-centric layout.

could have been a fat finger someone had on the button. i upvoted you to help.

Thanks! Not a stickler, or one of the complainers, but I appreciate less scripting, and responsive devs. ;)

Apparently archive.fo also requires JS via CloudFlare:

  Please turn JavaScript on and reload the page.

  DDoS protection by CloudFlare 
  Ray ID: 326502e238204c96

This is great. Remember that most people will benefit from this change and I love that Google is being aggressive about it.

If your backgrounded browser app needs 100% of the CPU, you've made a mistake.

Why not have a "this page would like to perform work in the background [allow|block]" notification?

Without special APIs to request it, this would be as ubiquitous as cookie warnings, making it highly annoying (and thus a bad business decision for chrome). And at least for the case presented in the article proper APIs without this throttling already exist.

I'd guess it's because most users would have no idea what to choose, would have no idea what the affect of each choice would be, and if you add more text to explain it, most users will not read it. Pop up the notification too often and it becomes a nuisance.

Better IMO to bury the choice deep in settings or something, for power users, if you even offer the choice at all.

> I'd guess it's because most users would have no idea what to choose

Sounds like you could kill two birds with one stone: allow a non-lame web and encourage users to learn what that means. We can't complain about tech illiterate users with one corner of the mouth and then make them decide what goes with the other.

> if you add more text to explain it, most users will not read it

They're not users. They're the blight on the back of users. Why cater to them? Is someone who looks left and right before crossing the street a "power pedestrian", too?

"This tab wants to use a lot of [RAM/CPU/GPU] while it is in the background, is that cool with you?

If you don't know what this means, it's best to select no. Fuck that site anyway for using a lot of resources without making it obvious that it's doing something heavy, or asking first, or explaining what is going on. If they don't like users clicking no or even navigating away from the page, that's their problem. If you read this far, click here to claim your Avid Reader Achievement Trophy."

Not bad for a first draft?

> They're not users. They're the blight on the back of users. Why cater to them?

actually they are about 90%+ of users

https://www.nngroup.com/articles/computer-skill-levels/

Fine, and most "webmasters" are really just hack frauds. On my planet, it's their job to get a room and ours to burn it.

edit: Usage implies intentionality. Intentionality implies awareness. Not being some super guru, but more awareness than "is text, won't read". Therefore, while the drive to shovel hardware on people, to create needs you then get to fill, did indeed bring all sorts of people who now get called users to the table, I don't consider them such. It's like someone who has a seizure on dance floor is not dancing, or like someone you forced to be somewhere is not "visiting that place". And I know people don't find it rude to just ignore a claim of how something ought to be with "but this is how it is, which is why it can and must be that way", which is why I say what I say. If someone does bad things and won't discuss them, it's absolutely up to the people who are aware and care to act. If you don't understand poetic language unless it's flowery that's your problem. So yes, I stand by what I said, just not by what it might evoke in the minds of some readers.

This sounds a lot like the arguments in the 80s about how GUIs were bad because they let anyone use a computer. Empathy makes it easier to write good software.

Pretty annoying if you want a game to continue running in the background :/

Or what about having facebook messenger in a tab? Or really any site that's constantly polling.

many sites allow for push notifications

I've seen several waiting games already that choke on Chrome, and have settings to activate a worker that keeps them unthrottled. Looks like this will break all of those solutions.

Just what I was thinking. RIP Cookie Clicker.

Wouldn't Cookie Clicker be doing updates based on time deltas? There's no guarantees a timer will fire after the desired time even without this update. Or am I missing a feature that requires it to be able to continually process in the background?

CC only runs while you have its tab open. I'd assume there's some function that updates state regularly (even if it's only the regular auto-saves).

The Intent to Ship [1] writes that all six platforms will be affected (Windows, Mac, Linux, Chrome OS, Android, and Android WebView). Yet how does this affect Chrome OS background tabs, which "work entirely in the background and run even after you close the Chrome browser"? [2]

[1] https://groups.google.com/a/chromium.org/forum/#!msg/blink-d... [2] https://support.google.com/chrome/answer/1184722?hl=en

That's a pain in the butt, I wrote a cnc toolpath computer and I don't want the computation to stop while you browse reddit

Can't we use serviceWorkers to workaround this? That's what they were created for.

I have a webaudio side project that works nicely even on the background using serviceWorkers for timing. I'm hoping it will be the same on 56.

No. They aren't cross browser compatible or backwards compatible.

They work fine in latest Chrome and kinda work in Firefox. But Edge and mobile browsers? Not a chance.

Can you elaborate? What does service workers give you for your web audio project that doesn't work without service works?

I'm curious because I have a HTML5 audio web app that works great, except when running on mobile in the background.

In my project the serviceWorker only has a setInterval that will trigger the main loop.

When the setInterval was in the main code it would slow down, a lot, when the tab was on background. That made the generated music go slow aswell. With the serviceWorker the clock is rock solid, even when the background app can't keep up, the timing is solid.

IIRC service workers are shut off after something like 30 seconds of inactivity.

So it may work for some cases, but not for all.

Service Workers are specifically designed to be short-lived and temporary [1]. They should be tied to events coming from the main script, which is subject to these new timing limits in the background. You should check your app against Chrome 56, as you might be in for a surprise.

[1]: https://www.w3.org/TR/service-workers/#service-worker-lifeti...

Seems to me this is still just an intent-to-implement, i.e., the discussion about the feasibillity of the feature and the exact implementation details is still very much ongoing. It might be useful to contribute to the discussion at [1]. An outline about the implementation details is given in [2].

The dev team also acknowledges this is a breaking change for the web and considers it an "intervention" according to [3]. This admittedly doesn't mean much, but at least gives some basic standard of procedure that sites can follow to keep impact on a minimum.

Also noteable is this bit from the current discussion: We mitigate this by only throttling timer tasks; other tasks such as loading tasks will continue to run unthrottled.

Sounds to me as if this could mean that IO events are not effected. So sites that currently poll for notifications in the background might work around the throttle but using long polling or web socket push instead.

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink...

[2] https://docs.google.com/document/d/1vCUeGfr2xzZ67SFt2yZjNeaI...

This is probably a good thing in the long run. Timer-based callbacks can generally be replaced by events, which only trigger when there is actually work to be done. Many JS timers I've seen are needlessly busy-polling.

Whether this implementation affects just timer callbacks or all background processing (eg websocket data events) is a bit ambiguous - this blog post seems to suggest major apps like Slack and Discord will break, but surely they are using websockets and not continuously polling for new data.

There was an firefox extension that did this as well, but it's been discontinued: https://github.com/palant/suspendbackgroundtabs

I wrote my own script that does this: https://github.com/kahing/bin/blob/master/throttle

> Popular applications like Slack and Discord, as well as our own application (BitMEX, a Bitcoin trading site) will be hugely and adversely affected by this.

Good, if web apps will become less reliant on doing everything in the server, so I will be able to open up multiple tabs without slowing down a computer.

Finally, a reason to move to Chrome! (Currently a Firefox user)

About time. I have been using extensions such as one-tab to prevent background tabs from draining memory.

I've got some bad news for you. This change has nothing to do with memory consumption of background tabs.

I am surprised nobody mentioned battery saving mode in Opera. It throttles background tabs similar way, but not so aggressively.

This will be great thing. Right now my Chrome eats about 10% of CPU, mostly Skype, Slack, Calendar... With Opera it is bellow 1% and I get much better battery life.

Even in Opera it is less about throttling cpu usage, and more about coalescing wakeups/timer interrupts.

There should never be a situation where background tab cant even get a 1 second timer running reliably, unless its trying to compute pi at the same time.

> Unfortunately, this implementation is ignoring the new reality: the browser is no longer just a reading device; it is the world's largest application platform.

This is why browsers really need to focus more on letting web pages be applications. On mobile, you can "add to home screen" for a web page and that's expected behavior. That needs to be forefront on the desktop as well.

I have over half a dozen SSB applications using Epichrome on the Mac, but that requires a level of technical expertise (finding and downloading a third-party program, finding icons to use, knowing that this capability exists in the first place, and so on) that you can't expect from average computer users. (Epichrome is great btw.)

Honestly, we have to come to terms with what browsers are good for, and what they aren't good for.

For a lot of the situations that I see complaints about; I wonder if they really should have written traditional thick applications instead of a browser application.

Seems like Edge also plans to do this: https://github.com/WICG/interventions/issues/34

Love how the one commenter already found a workaround:

Olivier TilleJanuary 24, 2017 at 8:28 AM

>That shouldn't be a problem as apparently "tabs with audio are always considered foregrounded". Source: https://groups.google.com/a/chromium.org/forum/#!topic/blink...

UnknownJanuary 24, 2017 at 8:53 AM

>And there's your workaround. Loop a 1 second null audio file for as long as you need to (please don't).

Each tab should get a certain number of credits to use CPU cycles, like a ticking time bomb when it runs out it should detonate and self-close (or just stops updating.) Perhaps then the browser in the next request to the same URL sends a header notifying the server that its page ran out of credit in x amount of time so the author can optimize it.

Another idea is to look at other Chrome users activity pattern in regards to how often a given URL is kept hidden and revisited to determine how much throttling should be done to it, something like an AdBlock list.

A setting to only allow this when the machine is on battery would be nice.

I often use my laptop while it's connected to power.

I still want to throttle (or suspend) background tabs, because the laptop gets uncomfortably hot otherwise.

An option to disable this would be nice. Some people are using PCs and don't care about battery/temperature.

I just can't imagine tons of games that are out there working nicely. New release is estimated to land on 31 January[0], how the hell are people supposed to update their codebases?

[0]: https://www.chromium.org/developers/calendar

This has now been delayed:

Unfortunately, our current implementation throttles WebSockets. Because of this we ARE NOT SHIPPING this intervention in M56.

The current plan is to disable time-budget background timer throttling for the pages with active connection (websocket, webrtc and server-sent events) and to ship in M57 (subject to further feedback). We will keep you updated with the progress.

https://news.ycombinator.com/item?id=13504385

This sounds a lot like the problem Android had with background tasks.

Starting in KitKat, a batching mechanism was introduced, so that apps which declared that they wanted CPU or screen resources in the future didn't all have separate timers running, but instead became members of a class that wanted similar things.

One of the most effective features of Greenify, a battery-saving app, is to force all apps (or all apps minus a few that you designate) into the batching mechanism.

Yep, and Android 6.0 Doze even expanded this mechanism to be more aggressive which proved to provide huge battery savings.

They should have done it long time ago. The pages today contain a lot of third-party scripts (advertisement, tracking, etc) and they sometimes can use up to 100% of a CPU core.

Mobile browsers are already stopping background pages because otherwise the phone's battery would be drained in hours.

Unless a background page is doing something useful for user, it should not consume any CPU time.

As a bellweather, OSX has had something called App Nap for some time, which throttles hidden apps apart from certain activities like playing music or downloading. I would imagine it affects Chrome as well as Safari. Have there been any real problems with that in practice?

Safari, yes. Chrome no. (You can see it in the task manager)

There haven't been problems with it in Safari as far as we know. We also do additional throttling at our level in addition to participating in App Nap on a per-tab basis.

What if something like a QOS tag were established for the page author to declare their need for a higher priority? The browser would also need to display an icon on tabs that have requested higher priority so that users can close sites that are abusing the privilege.

I want most aggressive battery savings possible on macOS. AFAIK Safari is doing more aggressive things. We are still a huge step away from Safari battery consumption although I see step by step progress made by Chrome team.

I'd he happy to suspend (and even offload to swap) some tabs from time to time. Too many times I get almost unresponsive tabs where I want to do something but it is just too laggy due to other tabs occupying the cpu.

I wish Chrome would also allow changing tabs when a page issues an alert notification. Further, there is no reason that alert notifications other than document/data saving, should prevent closing a tab.

Related: is there a decent FF extension to stop all JS activity in firefox in background tabs?

I really don't want any JS to be running in background. This includes WebWorkers and ServiceWorkers.

"Browser vendors should be concerned about battery life"... On a desktop or laptop plugged into the wall? Sounds like an incomplete or counter-productive optimization.

The browser is the new OS. Some applications should run in the background, some shouldn't. The user should be able to control it. Make it a permission.

So you get to use 1% CPU, effectively. The timer test seems strange, why was your "simple setInterval" using so much more than 1% CPU?

No, you don't get to use 1% CPU. That would still work. The problem is that you get to use 100% of CPU but only 1% of the time.

Explain how that is different?

It's different because it can't just slow down a running task.

Say you use up 150ms of CPU time. Chrome isn't going to let another timer fire for 15s. Then, you're late on a whole bunch of work that needs to get done, so the next timer takes 500ms. Chrome then throttles the next timer by 50s. And so on and so forth...

But if your script had 1% of CPU, that 150ms workload would take 15s to complete. Then the next workload would be late in the same way and take 50s to complete.

How is this different?

It depends on what you're doing. If you split up tasks and interleaves them (such as: process a few items, stop, set another timer, process a few more), actual CPU% throttling would be better. It would be easier to have certain timers take priority, such as heartbeat responses or notifications.

A timer task is only allowed to run when the budget is non-negative.

After a timer has executed, its run time is subtracted from the budget.

The budget regenerates with time (at rate of 0.01 seconds per second).

I think that would imply that if in any given second, your timer code runs for <= 10 milliseconds, then you will never run out of budget. Right?

So for things like sending out heartbeat packets to keep connections alive, I'm assuming that doesn't count, because it happens asynchronously (waiting for the response, I mean)? If that's the case, and your 10 milliseconds only applies to running JavaScript on the CPU, then 10 milliseconds seems reasonable to me. It's a background tab, after all, it's disrespectful of your users to abuse their CPU more than that.

How appropriate the day after finding the Task Manger in Chrome for the first time yesterday. Finally got my fan to turn off on my laptop.

What if my page has getUserMedia/microphone access? Do I still get throttled even if I'm not playing any sound?

For people (like my parents) who open way to many tabs, this will be a big help. Obviously there are a ton of caveats.

Can't they just have an enable / disable button with a warning about battery life?

All browsers should have an option to do this.

As long as you can turn it on and off, no big deal.

Is this feature enabled on the beta channel of Chrome builds?

Sounds good, would be better if it's adjustable.

So long to listening to Spotify ad-free at work...

Switched to Safari, happier than ever.

finally~ But I would prefer if background tabs didn't pre-load at all.

Good.

YES!

I would like to see Chrome utilize what I think is the right solution for loading background tabs; I would like it to let you (when you want to) rather than OPEN a background tab, only ENQUEUE a background tab -- opening it only when that tab becomes active, meanwhile keeping it in the status of an "enqueued" (i.e. barebones) tab with that URL in the tabs menu until you actually make it active or it becomes active the way any other tab would, at which point it loads - in other words a lighter kind of background tab that does not load at all until it becomes active.[1]

If this were implemented then finally I could open 120 tabs in a window for a detailed query (and they're not all loaded, there's zero overhead), then after 11 minutes of reading a few of those tabs, closing the ones I've read and having others load in their place if they weren't already loaded, be left with 87 unopened tabs with which I could close, since I've learned everything there is to know about that subject and I don't feel the need to read the rest anymore: I feel I've found the answer.

As it stands I can become an expert in any subject accessible in a day or two, in twenty minutes - unless, as sometimes happens, Chrome gets in my way. I can do it by opening them in background tabs today - but Chrome will both slow down and also be at high risk of crashing completely, not just in the window I'm in but all windows. Because at the moment even the 99th background tab, which I want to open so as to potentially glance at, actively, fully loads even if I close that window before I ever want to glance at it.

Along the same lines, I strongly feel there needs to be a way (not necessarily the default way) to open private (incognito) windows in a way that opens them privately "Except for crashes" -- meaning that these tabs remain open until I close it, by clicking the X button, not whenever Chrome crashes - which usually happens when it's done using all my memory.

If you fundamentally disagree that there is a distinction between the user actively exiting and you crashing unexpectedly, then you might as well change the Incognito greeting text to "Pages you view in incognito tabs won’t stick around in your browser’s history, cookie store, or search history after you’ve closed all of your incognito tabs or Chrome crashes unexpectedly".

But that doesn't make much sense. So please make the functionality match what was promised to the user, and keep pages open until the user has closed closed all incognito tabs. Not you.

I feel that these changes would improve people's experiences drastically. Chrome's developers surely care about their users and want to give them the best possible experience, and in addition this would get Google more clicks, more traffic, more ads from Google search results, by letting people open more pages with abandon on a lark, or on some thread they want to explore. By letting people keep more pages and searches open or queued for opening.

For the second point (about keeping incognito tabs on disk until they are actively closed with an X, at which point deleting them) - this also gives their users what they've just been promised. Whereas, at the moment in Incognito stuff just disappears whenever Chrome decides to crash -- which is often, given that at the moment it aggressively eats memory for any tab anyone might want to follow. This substantially increases the cost of exploring the web by opening background tabs. It makes people really weigh whether they want to open a background tab: it adds friction.

The web is about links. I hope Chrome will start letting people follow more of them and not lose their trail if they don't want to keep it in their history. This would be a positive change for all users, but, especially, the heaviest and most thorough users of the web, who load and visit the most pages. Now they could open even more in a browsing session, without having to think about whether they really want to risk opening another tab. (In terms of resources.)

For all of these reasons, I hope Google will implement enqueued tabs. Separately, at the user's option, I hope tabs status will be kept on disk until the last incognito tab is closed manually by the user (at which point it's scrubbed with random data), so that upon a crash it can be re-opened unless the user presses an X to that window. It would improve the experience of using the web for anyone who wanted it and not deprive users of the reading they worked hard to assemble for themselves. And it would increase the velocity with which users could explore the web.

Thank you.

[1] Functionality. Right-click a link, click "enqueue", this should be the same as "open in background tab" except the tab is really kind of like a placeholder, just consisting of a URL. It's not a full background tab that opens, gets its window name, etc - instead, it is not loaded until you actually make the tab active.

Right-clicking the tab bar should give you the option (in addition to normal options) "Close all enqueued tabs", leaving just tabs you've fully normally opened.

Example usage: say I'm searching for an article. I can start by doing some obvious Google searches in a few different tabs. I can go through the results and enqueue each one. Then I can go through the first (when it becomes the active tab, it is loaded) and enqueue any links that might lead to what I want. Then I close the now full-fledged tab when I'm done reading and following links, the next tab becomes active (which might have been an enqueued tab in which case it becomes loaded for the first time) and I can keep doing my search. Eventually I've found the page I'm looking for and can close all of the enqueued pages, or perhaps drag the tab into a new window (as you can today) and then close the old window - disappearing all the enqueued pages but also the normal, fully loaded tabs, per the normal behavior closing a window. (An enqueued tab is just a semi-loaded tab, just a URL that never loads until the tab becomes active. If its window or itself is closed in the way you usually close a tab - by right-clicking and clicking "close tab" or by middle-clicking on it, before it was ever the selected tab, then it simply wouldn't have even loaded a single time.)

This is exactly what I do today: except I have to be careful that Chrome doesn't crash while I do it, because it doesn't do it gracefully. I would like to manually specify whether I want the background tab to be actually loaded.

Oh god, please change the title. It's about timers, not bandwidth. I was already imagining streaming music from Spotify and having hiccups all day.

They throttle timer activation frequency if you use too much CPU time (with the goal of throttling CPU usage). How is the title not accurate?

It is confusing. I thought it meant network throttle till I read the post.

Tabs playing sound are exempt from the limiting

https://groups.google.com/a/chromium.org/d/msg/blink-dev/XRq...

Spotify's web player uses flash anyway.

This is their plan. Google will charge companies for extra processing time on your own computer.

Why though? I run Chrome on my decently powered laptop and most of the time I am connected to AC power. I want the machine to run as close to full potential as possible. This is not a mobile phone that needs to preserve battery by killing every background process. It's frustrating because no other browser matches chrome in smoothness and bug-free-ness, so I have no option but to tolerate the trademark anti-user behavior from google.

Firefox y u sux so much?

I run Chrome on a decently-powered desktop, and too many tabs can still kill it.

This is a good default; too many websites are built under the assumption that they're the only thing open and they have infinite resources to burn. Granted, I'd like to see more configuration options before this hits primetime, but I think it's going in the right direction to force some discipline on pages if the developers don't code it in (especially since there are events to tell when you've gone background).

> too many tabs can still kill it

"Kill"? Does your desktop stop responding and show a BSOD? How many tabs do you have open when that happens?

I don't know how heavily people use their Chrome but for me, ~50-100 tabs across ~5 windows across 3-4 virtual desktops seems to not hinder my laptop at all. It's very responsive and no crashes. To be honest I've never seen a system getting "kill"ed due to too many tabs.

My usage does not involve many video/audio tabs though. It's mostly lots of text pages and the usual mailboxes etc.

I think browsers should follow a similar paradigm for background tabs as the OS follows for background apps, ie, both have an equal share on resources unless foreground apps start slowing down due to background activity.

Kill performance. It's 2017; if you're running Win10, BSODs nowadays almost always mean you have a legitimate hardware failure or you're actually working on developing drivers. The OS has gotten very robust against the kinds of crap application-level software can pull to crash the OS.

It is not yet bullet-proof against a process deciding that it deserves all of your CPU and so much RAM that the disk cache needs to thrash to support it.

If you want the machine to run close to it's full potential you should be steering well clear of web apps.

Reply on news.ycombinator.com