Intent to implement and ship: throttling requestAnimationFrame callbacks based on viewport visibility
Sami Kyostila
Contact emails
Spec
This aspect of requestAnimationFrame is defined by the HTML processing model, but we have not proposed any spec changes yet. Design doc.
Summary
We want to stop running requestAnimationFrame callbacks for frames which aren't visible in the viewport. This helps to avoid unnecessary work for animations which aren't going to be seen by the user.
Motivation
The requestAnimation mechanism is a great way for pages to synchronize their animations with the display and the browser's own rendering. However, because there isn't an easy way to find out which parts of a page are visible, most pages end up perpetually subscribing to animation frame updates, causing unnecessary processing for animations which aren't even on the screen. A typical example is a long page with several ads (e.g., 500962, 447731, 395245, 515517, case study -- sorry, internal only, I'll see if we can make this public).
We think the long term solution to this problem is to bring better visibility and viewability APIs to the web. Because that will take some time and require content to be updated, this Intent proposes an optimization for today's web: if the browser can determine that the document which is being animated is invisible (e.g., its frame is outside the viewport bounds), the animation callbacks for that document won't be executed until the document becomes visible again.
Compatibility Risk
To minimize the compatibility risk with existing content, we are only planning to throttle requestAnimationFrame callbacks for documents in cross
origin frames. Because cross origin frames can't synchronously interact with the outside world, there isn't a direct way to observe the exact timing of animation updates in the embedded document.
Note that pages already have to deal with requestAnimationFrame updates stopping completely when the tab is in the background.
Firefox: Shipped in Firefox 40 (however they throttle to 1 Hz instead of stopping completely and don't have the cross origin restriction.)
Internet Explorer: No public signals
Safari: No public signals
Web developers: No signals
Ongoing technical constraints
None.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
OWP launch tracking bug
None. (Implementation tracking bug: crbug.com/487937)
Link to entry on the feature dashboard
https://www.chromestatus.com/features/4514713492783104
Requesting approval to ship?
Yes.