Specify <iframe loading=lazy>

[zcorpan]

#3752 originally included the loading attribute for both img and iframe. This was shipped in Chrome. I think after Chromium's intent to ship (for both img and iframe) was approved, we narrowed the scope of the spec PR to only specify loading for img.

It appears there is interest from Gecko and WebKit for the iframe case as well, but it not being specified is a problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=1622090
https://bugs.webkit.org/show_bug.cgi?id=196698

I think now seems like a good time to specify <iframe loading=lazy>.

[domfarolino]

Thanks for filing this! I'm happy to take this. I think #5236 should probably a blocker for this, since it is mostly about creating some Intersection Observer infrastructure that we reuse for images and iframes (and other things) in a more reusable and interoperable way.

[addyosmani]

I think now seems like a good time to specify <iframe loading=lazy>.

Thanks, @zcorpan! It's time... :) From the Chrome side:

• We are excited & committed to contribute to spec-work for <iframe loading=lazy> (+1 to Lazy load intersection-checking should not be done in-parallel #5236 being a blocker we should resolve)
• We intend to move the current implementation for native iframe lazy-loading behind a flag until comfortable the spec is in a good place. Currently looking at doing this for Chrome 84/85.
• We strongly recommend developers avoid using <iframe loading=lazy> until this work is further along. Folks who have adopted native lazy-loading for iframes will soon find it a noop.

[domfarolino]

We intend to move the current implementation for native iframe lazy-loading behind a flag until comfortable the spec is in a good place. Currently looking at doing this for Chrome 84/85.

Thanks @addyosmani. Just to clarify, it seems that given our latest blink-dev update, we won't be moving our implementation of iframe lazy-loading behind a flag, while developers are still discouraged from using it until it is fully standardized.