Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome will aggressively throttle background tabs

blog.strml.net

Post reply on HN
Print view View original

321–330 of 403 posts

Re: Chrome will aggressively throttle background tabs

#321

Post by saurik »

cdvonstinkpot wrote: post #314
mjevans wrote: post #209

Earlier quoted context omitted.

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 pr…

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 pi…

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.

Re: Chrome will aggressively throttle background tabs

#322

Post by minitech »

artursapek wrote: post #258
benjaminjackman wrote: post #237

Earlier quoted context omitted.

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.

Re: Chrome will aggressively throttle background tabs

#323

Post by saurik »

BinaryIdiot wrote: post #286
steego wrote: post #272

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 e…

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

Re: Chrome will aggressively throttle background tabs

#324

Post by SquareWheel »

ysavir wrote: post #196
mjburgess wrote: post #187

Earlier quoted context omitted.

Pinning a tab should disable throttling. Gives user straightforward control over which tabs are important.

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.

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.

Re: Chrome will aggressively throttle background tabs

#325

Post by ozataman »

altimin wrote: post #176

Hi, this is Alexander. I'm an engineer on Chromium team working on scheduling and on background tab throttling in particular. Firstly, I want to make clear that we are not shipping this in Chrome 56. We have enabled throttling as an experiment in beta channel to measure impact and collect feedback from web devs. We will aim to ship it in Chrome 57, subject to further feedback. In response to concerns voiced we will d…

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.

Re: Chrome will aggressively throttle background tabs

#326

Post by mlonkibjuyhv »

mjevans wrote: post #209
altimin wrote: post #176

Hi, this is Alexander. I'm an engineer on Chromium team working on scheduling and on background tab throttling in particular. Firstly, I want to make clear that we are not shipping this in Chrome 56. We have enabled throttling as an experiment in beta channel to measure impact and collect feedback from web devs. We will aim to ship it in Chrome 57, subject to further feedback. In response to concerns voiced we will d…

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 pr…

Perhaps the icon could be a spinning fan?

Re: Chrome will aggressively throttle background tabs

#327

Post by sengork »

rasz_pl wrote: post #296
overcast wrote: post #5

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

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.

Re: Chrome will aggressively throttle background tabs

#328

Post by ozataman »

jklinger410 wrote: post #78
lucb1e wrote: post #20

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 p…

Pinned tabs would be an easy solution for this. "Don't throttle pinned tabs"

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.

Re: Chrome will aggressively throttle background tabs

#329

Post by cortesoft »

diminoten wrote: post #260
cortesoft wrote: post #126

Earlier quoted context omitted.

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 navi…

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.

Re: Chrome will aggressively throttle background tabs

#330

Post by codedokode »

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.

Post reply on HN