Contact emailsz...@chromium.org, chri...@chromium.org
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.
An origin trial for this API started in M86 and is scheduled to end in M90. The most relevant use-case for this API has come from video conferencing apps, with the primary partner we've engaged with being Meet. The ongoing trial in Meet has shown reduction in overall CPU utilization (~3%), less instances of video quality reduction to mitigate high CPU usage (~7%) and improvements in user ratings for video calls (~1.5%) across all desktop platforms.
Link to “Intent to Prototype” blink-dev discussion
Goals for experimentation
The API proposal here is geared towards letting the browser decide when to use battery-savings mode and apply the mitigation to reduce rendering frame rate. But the feedback from the origin trial has been that the decision to reduce an animation's frame rate is dependent on the UI and it would be reasonable for the app itself to do it consistently, instead of relying on browser heuristics.
However, in some scenarios the app can set up its animations to run at a low rate but the browser doesn't synchronize them to the same frame internally. This causes the browser to redraw at a higher rate than the individual animations. It's not clear whether this can be fixed internally in the browser or whether we still need API hints to synchronize all animating content. For the continuation of the origin trial, we want to compare the impact of an explicit hint provided by this API against internal browser changes.
We'd like to extend the Origin Trial to run to M91.
Any risks when the experiment finishes?
As this feature is only available via Origin Trials and doesn't affect any existing state, we don't believe there will be any risks once the experiment concludes.
Reason this experiment is being extended