Intent to Experiment: battery-savings meta tag

166 views
Skip to first unread message

Khushal Sagar

unread,
Aug 11, 2020, 5:01:40 PM8/11/20
to blink-dev

Contact emails

khusha...@chromium.org, chri...@chromium.org


Explainer


https://github.com/chrishtr/battery-savings/blob/master/explainer.md


Design docs


https://github.com/chrishtr/battery-savings/blob/master/explainer.md


TAG review

There is no TAG review yet because we're still exploring the space and want to gather real-world data to justify APIs.


Summary

Adds a meta tag allowing a site to recommend measures for the user agent to apply in order to save battery life and optimize CPU usage. The mitigation targeted for this experiment is reducing the rendering frame rate.


Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/PQ9aDeWGUE0/m/qf07C9FDAgAJ


Risks

Interoperability and Compatibility

User agent measures to save battery and CPU may vary by agent, since this API is a hint rather than a description of an exact policy.


Gecko: No signal


WebKit: No signal


Web developers: Positive. Pre-prototype testing in the lab yielded positive results for video-heavy sites.


Ergonomics

It should be very easy to adopt.


Activation

It should be very easy to adopt.


Security

None



Goals for experimentation

This origin trial will allow the site to opt-in to the "allow-reduced-framerate" mitigation, enabled based on browser heuristics. We will be partnering with developers (like Google Meet) who can run field trials and collect A/B data on the real-world impact on overall CPU utilization from the feature. These results will inform future spec discussions.


Experimental timeline

M86-M87


Reason this experiment is being extended

NA


Ongoing technical constraints

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Currently implemented on desktop only but can be supported for Android as well.


Is this feature fully tested by web-platform-tests?

No None as yet


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5653874167775232


Mounir Lamouri

unread,
Aug 12, 2020, 1:18:56 PM8/12/20
to Khushal Sagar, blink-dev
Hi Khushal,

I'm very excited to see this coming together :) I believe that the Blink process requires you to request for an early TAG review even at this stage. You can file a request at https://github.com/w3ctag/design-reviews/issues/new/choose and pick "early design review".

-- Mounir

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMLuWUx%3DCsCQdSMKeb30aPLNr0MKLL_BX2mf_BoQQJ3tY8VPkw%40mail.gmail.com.

Mike West

unread,
Aug 13, 2020, 5:00:54 AM8/13/20
to Khushal Sagar, blink-dev, Mounir Lamouri
LGTM to experiment.

That said:

1.  I agree with Mounir's suggestion that asking the TAG for input would be excellent.

2.  I would encourage y'all to evaluate alternatives to the `<meta>` delivery mechanism. Did you consider an imperative API, for instance? That avoids questions about the processing model for `<meta>` (changes to the attribute value, insertion of new tags, `<head>` vs `<body>`, etc), and seems simpler to explain.

3.  What is the inheritance story? Is there an interaction with Document Policy/Feature Policy that could require embedded frames to respect the same policy as the embedder? 

-mike


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH_CTVcukyFhXFW9CsPBifNFzMaTratHPP1pbQAQscwdBA%40mail.gmail.com.

Khushal Sagar

unread,
Aug 13, 2020, 3:53:35 PM8/13/20
to Mike West, Khushal Sagar, blink-dev, Mounir Lamouri, chri...@chromium.org
Thanks Mike and Mounir!

On Thu, Aug 13, 2020 at 2:00 AM Mike West <mk...@chromium.org> wrote:
LGTM to experiment.

That said:

1.  I agree with Mounir's suggestion that asking the TAG for input would be excellent.

I have filed a request for an early design TAG review here.
 

2.  I would encourage y'all to evaluate alternatives to the `<meta>` delivery mechanism. Did you consider an imperative API, for instance? That avoids questions about the processing model for `<meta>` (changes to the attribute value, insertion of new tags, `<head>` vs `<body>`, etc), and seems simpler to explain.
 

My knowledge of the potential API surfaces here and associated implications is limited, I think chrishtr@ would be able to answer this better.
 
3.  What is the inheritance story? Is there an interaction with Document Policy/Feature Policy that could require embedded frames to respect the same policy as the embedder? 
 

I can't speak for interaction with Document Policy/Feature Policy but the general principle of whether the settings should apply to embedded frames is interesting. This hasn't come up in the use-cases we've considered so far but I expect we'll have more concrete thoughts on this as we explore more use-cases.

Ian Clelland

unread,
Aug 14, 2020, 11:40:10 AM8/14/20
to Khushal Sagar, Mike West, blink-dev, Mounir Lamouri, Chris Harrelson
On Thu, Aug 13, 2020 at 3:53 PM Khushal Sagar <khusha...@chromium.org> wrote:
Thanks Mike and Mounir!

On Thu, Aug 13, 2020 at 2:00 AM Mike West <mk...@chromium.org> wrote:
LGTM to experiment.

That said:

1.  I agree with Mounir's suggestion that asking the TAG for input would be excellent.

I have filed a request for an early design TAG review here.
 

2.  I would encourage y'all to evaluate alternatives to the `<meta>` delivery mechanism. Did you consider an imperative API, for instance? That avoids questions about the processing model for `<meta>` (changes to the attribute value, insertion of new tags, `<head>` vs `<body>`, etc), and seems simpler to explain.
 

My knowledge of the potential API surfaces here and associated implications is limited, I think chrishtr@ would be able to answer this better.
 
3.  What is the inheritance story? Is there an interaction with Document Policy/Feature Policy that could require embedded frames to respect the same policy as the embedder? 
 

I can't speak for interaction with Document Policy/Feature Policy but the general principle of whether the settings should apply to embedded frames is interesting. This hasn't come up in the use-cases we've considered so far but I expect we'll have more concrete thoughts on this as we explore more use-cases.

Part of this calculation will need to be the question "how important is it that subframes can't override their parent frame's setting?" If the answer is "not at all", then Document Policy could be a good fit for this API, as pages can generally set their policies independently of each other. If it is critical that a page with battery-saving mode enabled not have that setting reversed in any embedded content, then we could use Permissions Policy, declaring "can-use-excessive-battery" as a powerful feature, and granting that to all sites by default.

I'm happy to discuss the different options if you want, on this thread, or in GitHub issues, or whatever makes the most sense.

Ian

Thomas Steiner

unread,
Aug 14, 2020, 12:04:26 PM8/14/20
to Ian Clelland, Khushal Sagar, Mike West, blink-dev, Mounir Lamouri, Chris Harrelson
On Fri, Aug 14, 2020 at 5:40 PM Ian Clelland <icle...@chromium.org> wrote:
Part of this calculation will need to be the question "how important is it that subframes can't override their parent frame's setting?" If the answer is "not at all", then Document Policy could be a good fit for this API, as pages can generally set their policies independently of each other. If it is critical that a page with battery-saving mode enabled not have that setting reversed in any embedded content, then we could use Permissions Policy, declaring "can-use-excessive-battery" as a powerful feature, and granting that to all sites by default.

I'm happy to discuss the different options if you want, on this thread, or in GitHub issues, or whatever makes the most sense.

Not sure if folks have seen this, but I have also asked whether a CSS media feature or a (Client Hint?) HTTP header could be a fit for the use case: https://github.com/chrishtr/battery-savings/issues/2.
Reply all
Reply to author
Forward
0 new messages