
Reducing power consumption for background tabs - happy-go-lucky
https://blog.chromium.org/2017/03/reducing-power-consumption-for.html
======
joe_the_user
I'd honestly like to be able to "freeze" a page entirely once it fully
appeared in the browser window. A good percentage of web pages both take all
my CPU and become unreadable halfway through the page.

A big factors seems to be that the pages that are built out of layers of
active advertising devices - a given advertiser isn't concerned that they're
one of ten monetizing devices pasted onto a gvien page.

And there's the way pages have disincentive to play nice - a page that barely
works with only it open trains users to avoid other pages.

~~~
aeontech
Check out The Great Suspender [1] - not quite what you mean, but it basically
unloads the tab and replaces it with a bare bones placeholder after it's been
inactive for a bit. When you come back to it, you just click the link and it
reloads the url that it had. Super handy if you're in the habit of leaving a
few windows with a few dozen tabs each laying around, as I do.

[1]: [https://chrome.google.com/webstore/detail/the-great-
suspende...](https://chrome.google.com/webstore/detail/the-great-
suspender/klbibkeccnjlkjkiokjodocebajanakg?hl=en)

~~~
joe_the_user
Yeah no,

That just replaces the page with blank placeholder. How hard would it be to
replace the page with an image of it's contents?

I was thinking about a plugin.

~~~
aeontech
In my case, that would frequently be 200+ images in the background tabs. Not
as cheap as a blank page.

For me, the title, favicon and URL are plenty to identify the page, I think
it's a good tradeoff.

------
hueving
>Tabs playing audio or maintaining real-time connections like WebSockets or
WebRTC

How long before a "performance best practices" guide suggests leaving a
websocket open to ensure snappier page responses when users switch to your
tab.

~~~
fauigerzigerk
I had a similar thought. I think browsers should require user permission for a
tab to use more than 1% of a core on average.

~~~
Someone
That would get annoying soon. You won't want your browser to ask for that
permission or throttle page layout to use 1% of a single core during page
loads or the moment that browser-based shooting game gets lively and requires
fast reactions, for example.

I think it would be better to give each tab a power budget that, initially,
allows it to run for S seconds at full power, and that give it new budget at a
rate of x < 100% of max power every second.

However, I fear that still won't be enough. The list of heuristics and
exceptions could get so long that the resulting benaviour becomes difficult to
explain.

~~~
fauigerzigerk
Initial page load and rendering should be excluded from any quota.

After that the browser should automatically throttle and provide an API to let
the web app ask for permission to use more CPU, similar to how geolocation
works today.

I don't see why this should be too complicated from the user's point of view.
We're not talking about hard limits or real time guarantees. Browsers have a
lot of wiggle room on the implementation side.

~~~
Someone
Define where "initial page load and rendering" ends for a single-page web
application. When the DOM becomes stable at the login screen? After the login?
The moment the user starts interacting with the page?

Also, how does one control what set of pages a given permission applies to?
Exact URL often will be too limited, entire domain too coarse.

Allowing a page to use lots of CPU after every user interaction may be a way
out, but if you do that, you don't need the explicit permission system.

[I also think the way browsers handle those geolocation permissions already is
too complex for many users. They will simply learn "click _' allow'_, and
things will work; click _' forbid'_ and things may break"]

~~~
fauigerzigerk
_> Define where "initial page load and rendering" ends for a single-page web
application_

It's not hugely important. It could be DOMContentLoaded + x seconds. It could
be onload unless it doesn't fire within a reasonable amount of time. As long
as the browser starts throttling within seconds I don't care much about the
details. Login is not a concept I find relevant in this context.

 _> Also, how does one control what set of pages a given permission applies
to?_

It should apply on a per-domain basis. That may be too coarse in some cases
but nothing is perfect. Let's go for good enough.

------
zerr
The Great Suspender is a great plugin to achieve this.

~~~
bdamm
This looks nice!

As I enabled it, I got the normal warning about "This plugin can view all
data" etc, and I started looking for a plugin that can show me what servers
plugins are connecting to... it seems there is no such thing. Perhaps time to
re-enable little snitch.

~~~
Filligree
OneTab is another one to look at. It bundles the tabs into a list instead of
leaving them open.

~~~
sudoscript
You can also turn tabs into a webpage of a list of links. Very useful for
sharing.

------
vdnkh
I wish this could be (maybe it already can be?) disabled for environments
where I don't care about battery life/power consumption. This change probably
saves me a fraction of a cent per month at the cost of a worse web experience
(I'm a bit of a tab hoarder).

~~~
erikdesjardins
Seems that it can be turned off at:

    
    
      chrome://flags/#expensive-background-timer-throttling
    

...though they may eventually remove the flag.

~~~
joshstrange
Good for debugging an issue for sure but if you do any web-dev I'd shy away
from disabling it for fear you might miss something that breaks on one of your
sites because of it.

------
overcast
Not sure if any of you use "okcupid.com", but a single tab of that site will
consume 4-5GB of RAM in a matter of an hour. Eventually grinding the entire
browser to a halt, and nearly killing the OS in the process. There is a
SERIOUS memory issue on that site, and it's always been that way for me.
Safari, Chrome, Firefox on a Mac.

~~~
yladiz
Maybe Safari handles it differently, but I've left Okcupid on accidentally for
hours at a time in the background and I've never noticed anything specifically
memory hungry with it.

~~~
overcast
Safari seems to be the worst affected for me. I thought maybe it was
adblockers or something, disabled all plugins, and still persists.

------
_delirium
Extensive previous discussion, from when the feature was first floated:
[https://news.ycombinator.com/item?id=13471543](https://news.ycombinator.com/item?id=13471543)

------
alkonaut
How much benefit is there in doing anything at all on a background tab? Would
there be many use cases where simply suspending the background tab threads
would lead to a much worse user experience?

I wouldn't mind having my background Netflix just stop, or having to wait a
few secs for an interval refresh after bringing a tab to front.

But seeing as this seems an active area of research and debate I have a
feeling that this solution has drawbacks I'm not considering...

~~~
advisedwang
There are use cases such as a webmail client still fetching messages so it can
notify (e.g. via browser tab icons), or so that a collaborative editor keeps
up with changes.

Even consider the typical hackernews demo of a javascript genetic algorithm:
you probably want to be able to leave it to run for a while while you do other
things without being required to keep the tab visible.

~~~
chongli
Browsers have notification APIs now, from what I've seen. No need to run a
full background tab just to handle the occasional notification.

~~~
apetresc
Those notification APIs still get triggered by Javascript running in those
tabs. As far as I know, there's no equivalent to the mobile notification APIs
where there's a single dedicated socket listening to a central server.

~~~
kalleboo
Safari's notifications can use the Apple push notifications server the same
way iOS apps do.

~~~
apetresc
Ah, that's pretty cool. Still, I don't think any of the other browsers have it
that way, and Safari's desktop market share is ~2%.

------
mcbits
It would be nice if page authors (perhaps with user permission) could disable
throttling on background tabs in some cases. I made a Morse code tutor with
the Web Audio API, and playback breaks as soon as you switch tabs because the
timeouts go to 1 second minimum. And it's practically unusable on mobile, even
in the foreground, due to the horrible timing and/or excessive audio buffer
sizes (not sure which).

------
Keverw
From the linked Google doc:

\------------------------------------------------------

Suspend all background tabs (~2018) Fully pause a tab in the background after
N minutes unless a web developer states that the tab should continue to run
via an explicit opt-out.

Remove opt-outs (~2020+) Remove the opt-out and pause all pages. We’ll be able
to do this once we’ve (1) ensured that the web platform provides the APIs
needed for major use cases and (2) given developers a sufficient deprecation
period.

\------------------------------------------------------

That sounds a bit scary, and would require a lot of rewriting or refactor
existing code. I'm assuming not all the APIs are even ready yet to proactively
start doing this already. But sounds like the iOS model, which has it's pros
and cons. Probably has a lot of benefits though in the long run.

I hope by pause, means if they switch back it resumes instead of
reloading/refreshing. Maybe even emit an event to know it resumed, if the app
wants to check if new notifications, etc for it's view... Maybe you were
filling out a complex game form - losing state would really be sucky if it
reloads, instead of resuming.

------
Jaruzel
Right now WebRTC and WebSockets are not a solution to wholesale replace Ajax
based javascript polling; A LOT of established software and hardware HTTP
proxies used by large corporates do not support the HTTP CONNECT protocol, and
thus WebRTC and WebSockets fail.

I have a service that's used daily by a small community of people who are
behind such a proxy. The service uses 10 second javascript timeouts to fetch
new data from the server - This change in Chrome(ium) is going to totally
break it.

I do agree that sockets are the way to go, I just don't think the rest of the
internet infrastructure is completely there yet.

------
surement
For others interested in the performance of Chrome, there is a great chapter
on it in The Performance of Open Source Applications:
[http://aosabook.org/en/posa/high-performance-networking-
in-c...](http://aosabook.org/en/posa/high-performance-networking-in-
chrome.html)

------
robotmagician
Not super familiar with how the components of iPython/Jupyter notebooks
function, so I'll go ahead and ask a potentially stupid question: How might
this affect notebooks open in tabs that are running tasks in the background?

~~~
goodside
Long-running tasks run on the server, not on the client where JS timers
matter. You'd get the same results, just maybe a fraction of a second later.

~~~
robotmagician
Ah, I see what you mean. Chrome is throttling client-side operations. Because
the python kernel of an iPython notebook is running as server-side code (even
if that 'server' is local), it couldn't be subject to throttling by Chrome.

------
abalone
Safari has been doing something like this since Mavericks. Any idea how it
compares?

------
algesten
> like WebSockets

Does that mean simply using vanilla socket.io means the page will not benefit
from this?

~~~
zbuttram
Pretty sure socket.io will be fine unless it falls back to HTTP polling, which
iirc it shouldn't do in the newest version of Chrome unless something is
misconfigured on one end.

