Defer cross-domain iframe loads until they are viewable

[KenjiBaheux]

Deferring the load of out-of-view iframes should improve the Loading user experience (more bandwidth & cpu for assets and tasks that are more essential than out-of-view iframes).

To make this intervention safer, it might make sense to restrict its scope to cross-domain iframes.

To strike the right balance between the needs of iframe owners and the user experience, it might be important to time the load on "about to be viewable" / "not viewable yet but idle time" signals rather than a strict "became viewable" signal.

[bsittler]

Some sites use off-screen IFRAMEs for cross-origin APIs using postMessage, for instance to facilitate OAuth 2 and other authorization checks and for CORS-like API calling with additional client-side features (caching, auth token injection, etc.) These "service" IFRAMEs are typically positioned absolutely at negative x and/or y coordinates. Is there any way to avoid breaking them?

[KenjiBaheux]

Thinking out loud:

1. iframes that are meant to always be offscreen vs.
2. iframes that are currently offscreen but could be reached out

We could ignore case 1 iframes?

[hillbrad]

Agreed with @bsittler

This would be horrible to apply to same-origin iframes, as they are used by many AJAX type frameworks to parallelize and do background loads of content. Much of Facebook works like this. (yes you could do this today with Workers, but this strategy is more broadly compatible and has worked much longer than Workers have been around)

For cross-origin cases, iframes and postMessage are the safest and best cross-origin communication mechanism we have. This would be really unfortunate for the platform. We want developers to do things like this instead of expensive HTTP round-trips using easily abused open redirectors. There a number of ways these iframes are deliberately hidden: display: none, 0x0 size, or positioned off-screen.

Could we have a "nice" attribute instead so that page authors could give explicit scheduling priorities to iframe loads?

[ojanvafai]

This is something we'll need to experiment with. It's not clear to me we'll every find something shippable here, but the problem is (maybe) big enough to warrant investigation. To start with, we're just measuring the number of cross-origin frames that are never visible. I think there's a few obvious things we'll need to exclude from that though: -Same-origin frames. Sync access to the parent page makes them more likely to be needed. -0x0 frames. Clearly the majority of these will be used for some sort of postMessage conversation. -Frames that are in user inaccessible regions of the page (i.e. above the top or to the left of the scrollable region of the root of the page). Clearly the majority of these will be used for some sort of postMessage conversation.

[Daniel15]

Is this a duplicate of #1?

[ojanvafai]

It's not a dupe. #1 still loads them, just at a lower priority. This proposal is oriented at both performance benefits and reduction in bytes downloaded, so doesn't load them at all if they're far from the viewport.

[johannhof]

(As noted in https://github.com/WICG/interventions/pull/72, we intend to archive this repository and are thus triaging and resolving all open issues)

This seems quite an ambitious effort considering the outlined use-cases that would be broken. There may be potential for browser experimentation, and, if it proves successful, the following standardization discussion could be had in a new issue on HTML.

There is also the (optional) loading attribute which helps sites opt-in to this behavior with less risk of breakage.