Web page settings to save battery

[khushalsagar]

Saluton TAG!

I'm requesting a TAG review of battery-savings.

Saving battery or CPU is important for computing devices that are not connected to an electrical source, or to better share common CPU & GPU resources among running processes. Web sites that are known to have high CPU or battery costs may want to request that the UA optimize for CPU or battery, even if the user has not requested it.

Explainer : https://github.com/chrishtr/battery-savings/blob/master/explainer.md Primary contacts (and their relationship to the specification):

• [Chris Harrelson] ([chrishtr]), [Chromium]
• [Khushal Sagar] ([khushalsagar]), [Chromium] GitHub repo (if you prefer feedback filed there): https://github.com/chrishtr/battery-savings/blob/master/explainer.md Organization/project driving the design: Chromium External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5653874167775232

We'd prefer the TAG provide feedback as (please delete all but the desired option): 🐛 open issues in our GitHub repo for each point of feedback

[hober]

Hi, @kenchris and I took a look at this during the TAG's virtual F2F this week.

It's not clear to me that there's much value in an explicit opt-in from a site for throttling. Most sites won't adopt, so user agents which engage in throttling are going to do so regardless of whether or not the site opts in. Maybe the idea is that, after a site opts in, the user agent could tell the site that it's being throttled in various ways, but it's unclear what the site could then be expected to usefuly do in that scenario. In the if (throttled) then { ... } else { ... } case, it seems authors are just as likely to make things worse in the then clause, since there's a lot of misinformation out there about how to optimize sites. So then user agents would stop sending the signal.

[kenchris]

I don't understand the video conferensing use-cases. If I operate such a service and want to save battery etc, I would lower resolution and frame rate for instance to 15 fps instead of 30. I really don't want the browser to throttle me so that I loose frames which can result in a terrible user experience.

If a site has some javascript tasks that might run long but do not directly impact UX, it's ok to run those tasks slower.

But this is a global thing so it would affect all tasks. It feels like the postTask scheduling proposal might fit this use-cases better.

[chrishtr]

It's not clear to me that there's much value in an explicit opt-in from a site for throttling. Most sites won't adopt, so user agents which engage in throttling are going to do so regardless of whether or not the site opts in.

The value for an opt-in is for a site to indicate that it values battery savings over high framerate. Without an opt-in, the browser cant' know whether throttling of framerate would harm user experience more than it helped battery life.

You're also referring to a goal of the browser improving battery life of the device overall. You are correct that if only certain sites opt in, then relying on the opt-in will not improve device battery life for users that do not heavily use the opting-in sites. Nevertheless this feature still helps those users who do heavily rely on it. Video conferencing sites are often very heavily used, so in fact just optimizing those sites will substantially improve battery life for many users.

An approach that throttles the framerate for all sites, either via user opt-in or based on a device battery life signal, are good to consider but are different use cases.

I don't understand the video conferensing use-cases. If I operate such a service and want to save battery etc, I would lower resolution and frame rate for instance to 15 fps instead of 30. I really don't want the browser to throttle me so that I loose frames which can result in a terrible user experience.

This doesn't work for CSS animations, which cannot control their own framerate. It's very common for video conferencing sites to have animations on top of the video that are implemented in HTML, for example to indicate who is speaking or whether a person is speaking. Even if the video drops to 15 or 30 FPS, the CSS animation is always at 60. Opting into reduced framerate allows the browser to match the video and CSS animation framerates when both are happening.

There are also use cases where developers do want 60 FPS CSS animations on top of a video or offscreen canvas, for example for gaming. Therefore I think an opt-in is needed.

But this is a global thing so it would affect all tasks. It feels like the postTask scheduling proposal might fit this use-cases better.

Yes, but putting the thread on a "little core" would have a much greater impact on power efficiency, be simpler to implement for browsers and developers, and have more predictable performance.

[LeaVerou]

Echoing @hober's thoughts, I also think an opt-in would end up ignored by browsers down the line. Given that the vast majority of sites will not declare anything, browsers need to be able to treat this as ok to throttle. Throttling on low battery is the common case, and declaring that you don't want it for some reason is the exception, so the Web platform feature should reflect that to be useful. Have you considered an opt-out instead, where websites can declare that it is important not to throttle certain operations?

I'm missing a more extensive list of operations beyond the two used as examples in the explainer (reduced framerate and reduced script speed). Are these the only ones?

The explainer mentions a reduced-framerate media query (as @reduced-framerate, which I assume is a typo? A media query would be @media (reduced-framerate)). This seems a bit too low-level and lacks flexibility. For example, if UAs start conserving battery in different ways in the future, does the MQ stop applying? Are there use cases where you want to handle specific throttling operations differently, or do authors really just need to know that battery savings mode is active? Perhaps a more general @media (energy-savings) media query would be more broadly useful?

[torgo]

@khushalsagar @chrishtr we are just picking this up again in our virtual f2f. We have some additional comments which Ken will write in. Additionally can you let us know the current status on this on your end? There seems to be some privacy & security considerations of this idea that need to be spelled out. Could I ask you to fill out the privacy & security self check and include a privacy & security considerations section in the explainer? Can you also let us know what the planned venue for this is? Is this destined for WICG? Will it potentially go to the devices & sensors working group? Can you let us know about any multi-implementer interest or support?

[kenchris]

@torgo, @LeaVerou, @rhiaro and me looked at this in our TAG Virtual F2F breakout

We believe we understand the video conferencing use-case now. Some sites get very quick user interaction and probably won't like to be throttled (A), but other sites like video conf would knows that their users have another hour of meeting left and they are low on battery so they may want to optimize for the battery to last as long as possible and hopefully until the meeting is over (B).

For (A) we think an opt in or opt out won't work, but instead a priority might, like you are going to get throttled so what matters the most to you, high framerate, background tasks, foreground tasks? Then the browser can consider those hints

For (B) an opt in might work, but we think an event that low battery mode is active makes more sense, then the vidconf site can lower video resolution etc and turn off live captions and many other things to save battery.

[chrishtr]

Echoing @hober's thoughts, I also think an opt-in would end up ignored by browsers down the line. Given that the vast majority of sites will not declare anything, browsers need to be able to treat this as ok to throttle.

I don't really agree with this reasoning. The problematic situation is one where

• the browser + site is in fact capable of reaching a higher frame rate, and
• the battery is not (yet) low, or the CPU impact on other applications is hard to trade off without further data

There are sites that are used often and can therefore have a large impact on battery life or responsiveness of the computer. Video conferencing is one class of sites.

Regarding the point about "vast majority" of sites not putting in a meta tag:

• Most sites have little effect on battery life because the user doesn't spend a long time on them
• Most battery life issues are associated with long-lived sites that are in the video / productivity / media space.

The sites that do cause battery impact will in fact want to provide hints to the browser to help it optimize battery life, because the user experience on the site will be better. And there are not a huge number of them.

Ultimately the problem is that it's difficult for the browser to correctly trade off performance with energy use or effect on performance of background apps, because the browser cannot know what exactly the site wants to be doing. If the browser makes the wrong decision and throttles animations too often, then some sites may be incorrectly throttled and have no recourse.

Throttling on low battery is the common case, and declaring that you don't want it for some reason is the exception, so the Web platform feature should reflect that to be useful. Have you considered an opt-out instead, where websites can declare that it is important not to throttle certain operations?

I agree that an opt out is reasonable to consider.

I'm missing a more extensive list of operations beyond the two used as examples in the explainer (reduced framerate and reduced script speed). Are these the only ones?

There might be others, but I don't know of any right now.

[chrishtr]

@torgo, @LeaVerou, @rhiaro and me looked at this in our TAG Virtual F2F breakout

We believe we understand the video conferencing use-case now. Some sites get very quick user interaction and probably won't like to be throttled (A), but other sites like video conf would knows that their users have another hour of meeting left and they are low on battery so they may want to optimize for the battery to last as long as possible and hopefully until the meeting is over (B).

Yep, that's it. Some sites really want smooth and fast performance, and some would prefer an extra hour of battery life over super-smooth animations. And the browser can't easily guess which is which.

For (A) we think an opt in or opt out won't work, but instead a priority might, like you are going to get throttled so what matters the most to you, high framerate, background tasks, foreground tasks? Then the browser can consider those hints

I think these use cases go into the category of: what to do when there is low battery or a user signal to use fewer resources? Anyway, +1 to your point here.

For (B) an opt in might work, but we think an event that low battery mode is active makes more sense, then the vidconf site can lower video resolution etc and turn off live captions and many other things to save battery.

Consider this situation: User enters a video conferencing site with battery at 100%, and stays on the call for multiple hours. The user would like to extend the length of the call. The best way to do so may be to save battery life along the entire timeline of the call, not just near the end when the battery is getting low.

I don't think the event you suggested would work for this case.

[chrishtr]

@khushalsagar @chrishtr we are just picking this up again in our virtual f2f. We have some additional comments which Ken will write in. Additionally can you let us know the current status on this on your end?

The current status is that we have an origin trial ongoing, with participation from Google Meet in particular. They have observed substantial battery life savings due to the trial. In parallel with the trial, there has been experimentation within Chromium to see if there are tricks and optimizations within the compositor, combined with measures on the website that intentionally throttle CSS animations via step annotations, that can result in a similar savings. So far it looks like the answer might be yes, at least for the specific workload in Google Meet. Other video conferencing sites are considering and/or also participating in the trial.

I'm concerned that these solutions are brittle, and there needs to be a more explicit way to indicate that "60fps CSS animations are not necessary on this site if they impact battery", which would allow these sites to not have to carefully audit and control their CSS animations, and leave it up to the browser to find ways to do so, e.g. by throttling the animations or synchronizing their compositor frames with video textures.

There seems to be some privacy & security considerations of this idea that need to be spelled out. Could I ask you to fill out the privacy & security self check and include a privacy & security considerations section in the explainer? Can you also let us know what the planned venue for this is? Is this destined for WICG? Will it potentially go to the devices & sensors working group? Can you let us know about any multi-implementer interest or support?

This TAG review was of the "early review" variety that comes at the Intent to Implement / Intent to Experiment stage of the Blink feature process (maybe we need to revise our process to indicate that more clearly?).

If and when we proceed further with the standards process, I agree there need to be reviews of any privacy and/or security concerns.

If/when we want to proceed further with this proposal, yes it'd be WICG + WebPerfWG I think.

[torgo]

Ok Chris thanks for that - we are going to close this for now as I think you have our feedback. Please open a new issue when you want to do a full review.