Intent to Implement and Ship: Timer throttling for hidden cross-origin frames

211 views
Skip to first unread message

Sami Kyostila

unread,
Jun 27, 2016, 12:55:37 PM6/27/16
to blink-dev

Contact emails

skyo...@chromium.org


Spec

Discussion at WICG: https://github.com/WICG/interventions/issues/9

Design doc: https://docs.google.com/document/d/1Xa8sd2M_Eh6hGSWeKTy_akzKdxcVZjCk4PQMqV8yXXw/edit#


Summary

As an intervention we want to limit the rate at which timers in out-of-view, cross-origin frames are able to fire.


Motivation

Until very recently it wasn't possible for script authors to easily determine whether their content was visible to the user or not. A common pattern therefore is to use a continuous setTimeout() loop for driving animations without considering visibility, which can be very costly for performance.


Most modern browsers already intervene to lower the update rate of timers in background tabs (e.g., 1 Hz in Chromium). We propose to extend this intervention to cross-origin iframes that are outside the visual viewport in a foreground tab. This helps to conserve power and reduce input jank caused by third party content.


Interoperability and Compatibility Risk

A potential compatibility risk is that a site can observe timers firing out-of-order if the they are scheduled from a mix of visible and hidden frames. To reduce this risk, we propose to only throttle timers in cross-origin frames.


Safari 9 ships a similar intervention which throttles timers in all out-of-view frames (instead of only cross-origin ones).


Edge is also investigating throttling timers in cross-origin frames.


There is a Firefox bug to do something similar, although so far Firefox only throttles the requestAnimationFrame API in out-of-view frames.


Ongoing technical constraints

None.


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

Yes.


Demo link

http://jsfiddle.net/3L9c9uyc/3/embedded/result/


OWP launch tracking bug

crbug.com/623610


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5701844080787456


Requesting approval to ship?

Yes.

Chris Harrelson

unread,
Jun 27, 2016, 1:26:40 PM6/27/16
to Sami Kyostila, blink-dev
LGTM1

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

Dimitri Glazkov

unread,
Jun 27, 2016, 1:27:34 PM6/27/16
to Chris Harrelson, Sami Kyostila, blink-dev
LGTM2.

Philip Jägenstedt

unread,
Jun 29, 2016, 5:55:49 AM6/29/16
to Dimitri Glazkov, Chris Harrelson, Sami Kyostila, blink-dev
LGTM3

Darin Fisher

unread,
Jun 29, 2016, 10:51:48 AM6/29/16
to Sami Kyostila, blink-dev
Will this (should this) apply to requestAnimationFrame and requestIdleCallback as well?
-Darin

On Mon, Jun 27, 2016 at 9:55 AM, Sami Kyostila <skyo...@chromium.org> wrote:

Sami Kyostila

unread,
Jun 29, 2016, 12:56:24 PM6/29/16
to Darin Fisher, blink-dev
We're already stopping requestAnimationFrame callbacks for out-of-view frames as of M52. We could throttle idle callbacks similarly, but I'm less worried about them since they run at lowest priority and are more well behaved thanks to the deadline contract.

- Sami

Darin Fisher

unread,
Jun 29, 2016, 12:57:30 PM6/29/16
to Sami Kyostila, blink-dev
Cool, thanks. That makes sense about idle callbacks.
Reply all
Reply to author
Forward
0 new messages