Intent to Ship: Throttle render pipeline for loading iframes with pending sheets

79 views
Skip to first unread message

Elliott Sprehn

unread,
Nov 8, 2016, 4:31:32 PM11/8/16
to blink-dev, Ojan Vafai
Contact emails

Spec
This leverages the spec change done for render pipeline throttling we're currently using for off screen iframes.

Summary
Delay running the rendering pipeline (style, layout, paint) and executing requestAnimationFrame callbacks inside iframes until pending stylesheets have finished loading. Today we paint white until the pending sheets are done loading, this change makes requestAnimationFrame respect the decision to not actually paint anything. 

This makes the platform more rational by avoiding pumping requestAnimationFrame and starting animations when the iframe is not actually painting.

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

Interoperability and Compatibility Risk
Moderate.

Chrome has throttled the pipeline of the entire frame tree while the top level page is blocked on sheets for many years, but has not throttled iframes separately from the whole frame tree. Chrome is also throttling the pipeline for off screen third-party iframes today.

No other browser currently throttles requestAnimationFrame when pending sheets are loading. 

The primary risk is that content in parent frames depend on requestAnimationFrame running in nested same origin iframes while they're still waiting on external sheets. This situation should be rare because scripts block on external sheets, so the parent frame would either need to access the contentWindow of the iframe directly to call requestAnimationFrame, or a setTimeout/setInterval/event handler inside the iframe would need to run with precise timing so the requestAnimationFrame of the parent and the child would be together.

In person discussions with representatives from Edge and Firefox have expressed interest in rationalizing the platform this way if it's possible to ship without breaking content.

Demo link

This page demonstrates running requestAnimationFrame inside an iframe which is not painting because the sheets are still loading. After this change it will always report 1 frame for the iframe, the first paint where its pixels would actually be displayed.

OWP launch tracking bug

Entry on the feature dashboard

- E

Rune Lillesveen

unread,
Nov 8, 2016, 6:08:05 PM11/8/16
to Elliott Sprehn, blink-dev, Ojan Vafai
SGTM

Out of curiosity (and ignorance), do you need to make special
considerations for OOPIF? I just noticed in the CL[1] that you do a
check for non-throttled frames inside throttled ones which stops at
RemoteFrames, but that would already be an issue with throttling of
iframes in general?

[1] codereview.chromium.org/2401713003/
--
Rune Lillesveen

Elliott Sprehn

unread,
Nov 8, 2016, 6:11:11 PM11/8/16
to Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
On Tue, Nov 8, 2016 at 3:08 PM, Rune Lillesveen <ru...@opera.com> wrote:
SGTM

Out of curiosity (and ignorance), do you need to make special
considerations for OOPIF? I just noticed in the CL[1] that you do a
check for non-throttled frames inside throttled ones which stops at
RemoteFrames, but that would already be an issue with throttling of
iframes in general?

Yup, that's a blocking bug for OOPIF:

the subtree throttled bit needs to be replicated.

Rick Byers

unread,
Nov 9, 2016, 8:02:42 PM11/9/16
to Elliott Sprehn, Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
I guess it would be pretty hard to detect (for metrics purposes) when a site is relying on this right?

Seems like a reasonable rationalization and likely to be low risk.  I think we should give it a shot, but please ping this thread if any non-trivial breakage is discovered.

LGTM1

Philip Jägenstedt

unread,
Nov 10, 2016, 11:12:30 AM11/10/16
to Rick Byers, Elliott Sprehn, Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
LGTM2

Dimitri Glazkov

unread,
Nov 11, 2016, 2:45:45 PM11/11/16
to Philip Jägenstedt, Rick Byers, Elliott Sprehn, Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
LGTM3

Timothy Dresser

unread,
Nov 12, 2016, 1:13:24 PM11/12/16
to Dimitri Glazkov, Philip Jägenstedt, Rick Byers, Elliott Sprehn, Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
Sorry for the late response - should we be launching this via Finch? Finch would give us better insight into the exact performance implications of this change, as well as giving us opportunity to observe breakage in the wild before committing.

Rick Byers

unread,
Nov 12, 2016, 1:55:01 PM11/12/16
to Timothy Dresser, Dimitri Glazkov, Philip Jägenstedt, Elliott Sprehn, Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
It's a good question, sorry we didn't ask it sooner.

If this is being done because we think it'll substantially improve performance of existing sites, then I'd agree.  But it sounds like that's not Elliott's motivation here.

Instead we're already not rendering content during this period, so we're just trying to improve rationality (and perhaps code health?) by reflecting that in the rAF behavior.  If that's the case, and we don't have any reason to believe this is likely to have a substantial aggregate performance impact, then I'd say trying to measure the impact via UMA/Finch isn't worth the effort (and loss of predictability) in this case.

Elliott, what do you think?

Elliott Sprehn

unread,
Nov 14, 2016, 3:48:20 PM11/14/16
to Rick Byers, Timothy Dresser, Dimitri Glazkov, Philip Jägenstedt, Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
On Sat, Nov 12, 2016 at 10:54 AM, Rick Byers <rby...@chromium.org> wrote:
It's a good question, sorry we didn't ask it sooner.

If this is being done because we think it'll substantially improve performance of existing sites, then I'd agree.  But it sounds like that's not Elliott's motivation here.

Instead we're already not rendering content during this period, so we're just trying to improve rationality (and perhaps code health?) by reflecting that in the rAF behavior.  If that's the case, and we don't have any reason to believe this is likely to have a substantial aggregate performance impact, then I'd say trying to measure the impact via UMA/Finch isn't worth the effort (and loss of predictability) in this case.

Elliott, what do you think?

Yeah this isn't really about performance, it's about making the FOUC avoidance system actually make sense both internally and for web developers.

The design doc talks about the state of the world today and the plan that fixes it, this intent is one of steps (also described at the bottom of the doc):

Chris Harrelson

unread,
Nov 14, 2016, 3:51:17 PM11/14/16
to Elliott Sprehn, Rick Byers, Timothy Dresser, Dimitri Glazkov, Philip Jägenstedt, Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
LGTM4

--
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+unsubscribe@chromium.org.

Timothy Dresser

unread,
Nov 17, 2016, 2:58:19 PM11/17/16
to Chris Harrelson, Elliott Sprehn, Rick Byers, Dimitri Glazkov, Philip Jägenstedt, Rune Lillesveen, dch...@chromium.org, Sami Kyostila, blink-dev, Ojan Vafai
Launching without finch SGTM, thanks for the clarification Rick/Elliot.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Reply all
Reply to author
Forward
0 new messages