Iframe lazy loading

[Yoav Weiss]

Hey folks,

Following a Twitter thread, which was a latent reaction to Simon Pieters' tweet from a month ago, I looked into iframe lazy-loading and the claims that it's not specified.

It seems like the lazy-loading PR was modified at some point *after the feature shipped* to only cover image lazy loading.

Right now, there's a web.dev article saying that developers shouldn't be using the feature. 

IMO, we need to decide - if we indeed don't want developers to use the feature, we need to remove it. 

Otherwise, we can work to remove that warning from the article and indicate that while the feature is not currently specified (due to changes post-shipping) we trust that it will be soon, and that its behavior changes won't require web developer facing changes. (assuming this is indeed the case - Dom/Kinuko - can you confirm?)

I'm currently leaning towards the latter.

Thoughts?

Yoav

[Dominic Farolino]

Thanks Yoav for sending this! I'm more than happy to spec <iframe loading=lazy> if we can make it a priority!

Yeah, while there are still bugs in the current implementation, web developers shouldn't have to react in any way when we incrementally fix them.

[Chris Harrelson]

On Wed, Apr 29, 2020 at 6:48 AM 'Dominic Farolino' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Thanks Yoav for sending this! I'm more than happy to spec <iframe loading=lazy> if we can make it a priority!

Do you have a defined list of open problems to be solved for specifying iframe lazy-loading? How "simple" are they to spec? 

 

On Wed, Apr 29, 2020 at 12:28 AM Yoav Weiss <yoav...@google.com> wrote:

Hey folks,

Following a Twitter thread, which was a latent reaction to Simon Pieters' tweet from a month ago, I looked into iframe lazy-loading and the claims that it's not specified.

It seems like the lazy-loading PR was modified at some point *after the feature shipped* to only cover image lazy loading.

Right now, there's a web.dev article saying that developers shouldn't be using the feature. 

IMO, we need to decide - if we indeed don't want developers to use the feature, we need to remove it. 

Otherwise, we can work to remove that warning from the article and indicate that while the feature is not currently specified (due to changes post-shipping) we trust that it will be soon, and that its behavior changes won't require web developer facing changes. (assuming this is indeed the case - Dom/Kinuko - can you

Yeah, while there are still bugs in the current implementation, web developers shouldn't have to react in any way when we incrementally fix them.

How big are these bugs? Could you give a few examples?

 

confirm?)

I'm currently leaning towards the latter.

Thoughts?

Yoav

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CACa0%2BXtjjLQrPdm80SL7rHgYnSDkujMrbBCvhcVpseA%2BWkKgBw%40mail.gmail.com.

[Dominic Farolino]

On Wed, Apr 29, 2020 at 9:27 AM Chris Harrelson <chri...@chromium.org> wrote:

On Wed, Apr 29, 2020 at 6:48 AM 'Dominic Farolino' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Thanks Yoav for sending this! I'm more than happy to spec <iframe loading=lazy> if we can make it a priority!

Do you have a defined list of open problems to be solved for specifying iframe lazy-loading? How "simple" are they to spec? 

No, though it will be interacting with the navigation algorithm. I don't anticipate it being easy. It's also possible that https://github.com/whatwg/html/issues/5236 will be a blocker, which may end up being a little tedious (I'm very keen on doing it though).

 

On Wed, Apr 29, 2020 at 12:28 AM Yoav Weiss <yoav...@google.com> wrote:

Hey folks,

Following a Twitter thread, which was a latent reaction to Simon Pieters' tweet from a month ago, I looked into iframe lazy-loading and the claims that it's not specified.

It seems like the lazy-loading PR was modified at some point *after the feature shipped* to only cover image lazy loading.

Right now, there's a web.dev article saying that developers shouldn't be using the feature. 

IMO, we need to decide - if we indeed don't want developers to use the feature, we need to remove it. 

Otherwise, we can work to remove that warning from the article and indicate that while the feature is not currently specified (due to changes post-shipping) we trust that it will be soon, and that its behavior changes won't require web developer facing changes. (assuming this is indeed the case - Dom/Kinuko - can you

Yeah, while there are still bugs in the current implementation, web developers shouldn't have to react in any way when we incrementally fix them.

How big are these bugs? Could you give a few examples?

• https://bugs.chromium.org/p/chromium/issues/detail?id=992526
• I've fixed the <img loading=lazy> portion of this, but still would like to to do the <iframe> portion
• https://bugs.chromium.org/p/chromium/issues/detail?id=993273
  
• Also another bug that I have yet to file, about letting <iframe>s be lazy loaded more than once. It's sister bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1072018

[Rick Byers]

Thanks for bringing this up Yoav. Now that this has been shipped in chromium for awhile, what do we know about adoption and/or perf impact of iframe lazy loading? My recollection from the initial experiments (auto-opt-in) were that it was a big deal for loading performance. If that's still the case then I'd definitely agree investing in the spec is high value. Do we know if any other implementation has shown any interest in implementing the iframe piece?

[Dominic Farolino]

Adoption of iframe lazy loading seems to be at least 0.1% of pages in HTTP Archive, which is pretty significant IIUC [tweet]. I am not sure about the performance impact (Ben Greenstein's team would know more about that), but I'm pretty sure it is significant.

I believe Apple and Mozilla have both shown interest in <iframe loading=lazy>, especially since they've both implemented <img loading=lazy>. I don't have any sources in front of me unfortunately, but hopefully that provides some perspective.

[Dominic Farolino]

+Addy Osmani who started another similar thread about this as well.

Also, just FYI there seems to be several things along the lines of https://webplatform.news/issues/2020-04-27, which I think just generally doesn't look great for Chromium.

[Kinuko Yasuda]

I saw the twitter thread too.  We keep hearing that it's super popular & adoption is high, so investing in this would make sense (and that's on our Q2 OKR too up to some extent).

Regarding performance as far as I know it has about 10+% data savings combined with images (from automatic one) which is huge, speed-wise it looks somewhat neutral.  +Ben Greenstein 

[Addy Osmani]

> Now that this has been shipped in chromium for awhile, what do we know about adoption and/or perf impact of iframe lazy loading? My recollection from the initial experiments (auto-opt-in) were that it was a big deal for loading performance. If that's still the case then I'd definitely agree investing in the spec is high value. Do we know if any other implementation has shown any interest in implementing the iframe piece?

Fwiw, a number of large partners (e.g Facebook for their Like button) have expressed interest in using <iframe loading=lazy>. I've been attempting to get YouTube to consider adding the attribute to their iframes given it brings in ~600-700KB of script anytime the player is used. I think lazy-loading embed frames could have a significant impact for some of the more popular portable content sites.

Stepping back, the proposal I suggested in the other thread (I've tagged Rick and Chris H on) is that we:

1. Find an owner for the iframe lazy-loading spec work - seems between Dom, Simon and others this is OK

2. Good faith - make a public commitment to doing the spec work and admit we should have circled back here 

3. Move iframe lazy-loading behind a flag and only turn it on for Lite Mode - waiting for further input here. Should be a no-op for that 0.1% (for now)

4. Find an owner for the iframe lazy-loading implem work once 1. lands - I believe Ben's team can help update the implem (in case 1 involves change)

5. Publish guidance finally on iframe lazy-loading being OK to use for real this time and make a moment from it.

[Simon Pieters]

Hi all,

I'm happy to help moving this forward in the smoothest way possible. I think the ideal would be to get this specified as soon as possible, iron out any bugs, and get the feature prioritized in Gecko or WebKit. 

Here is Mozilla's bug about implementing lazy-loaded iframes: https://bugzilla.mozilla.org/show_bug.cgi?id=1622090

WebKit's bug for both img and iframe: https://bugs.webkit.org/show_bug.cgi?id=196698

A bug in Chromium's implementation I noticed, but didn't see reported, is that the .loading attribute can return "auto". Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1076651

cheers,

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAAKPnK8wOi6WVt72qcJWy5%2B22qOmTRgEHC3UW5%2BH%2B%2BK1EoEd6A%40mail.gmail.com.

--

Simon Pieters

https://bocoup.com/

[Simon Pieters]

I also reported a spec issue to add this feature: https://github.com/whatwg/html/issues/5496

cheers,

[Ben Greenstein]

On Wed, Apr 29, 2020 at 4:23 PM Kinuko Yasuda <kin...@google.com> wrote:

I saw the twitter thread too.  We keep hearing that it's super popular & adoption is high, so investing in this would make sense (and that's on our Q2 OKR too up to some extent).

Regarding performance as far as I know it has about 10+% data savings combined with images (from automatic one) which is huge, speed-wise it looks somewhat neutral.  +Ben Greenstein 

Median user data savings is ~8.5% now and we'll be rolling out new parameters to bring that to 10%. Speed is indeed neutral. 

[fal...@chromium.org]

2020年4月30日木曜日 9時27分24秒 UTC+9 Ben Greenstein:

On Wed, Apr 29, 2020 at 4:23 PM Kinuko Yasuda <kin...@google.com> wrote:

I saw the twitter thread too.  We keep hearing that it's super popular & adoption is high, so investing in this would make sense (and that's on our Q2 OKR too up to some extent).

Regarding performance as far as I know it has about 10+% data savings combined with images (from automatic one) which is huge, speed-wise it looks somewhat neutral.  +Ben Greenstein 

Median user data savings is ~8.5% now and we'll be rolling out new parameters to bring that to 10%. Speed is indeed neutral. 

I'm having trouble reconciling the "speed neutral" result with the web.dev article that says it improves page load time.

Are developers using <iframe loading=lazy> expecting a page load performance improvement that we no longer expect? One explanation I can imagine is that the "speed neutral" result comes from aggregated data including automatic LazyLoad, while explicitly using <iframe loading=lazy> can still be expected to improve FCP/LCP on that particular site?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

[Ben Greenstein]

On Thu, Apr 30, 2020 at 9:38 PM <fal...@chromium.org> wrote:

2020年4月30日木曜日 9時27分24秒 UTC+9 Ben Greenstein:

On Wed, Apr 29, 2020 at 4:23 PM Kinuko Yasuda <kin...@google.com> wrote:

I saw the twitter thread too.  We keep hearing that it's super popular & adoption is high, so investing in this would make sense (and that's on our Q2 OKR too up to some extent).

Regarding performance as far as I know it has about 10+% data savings combined with images (from automatic one) which is huge, speed-wise it looks somewhat neutral.  +Ben Greenstein 

Median user data savings is ~8.5% now and we'll be rolling out new parameters to bring that to 10%. Speed is indeed neutral. 

I'm having trouble reconciling the "speed neutral" result with the web.dev article that says it improves page load time.

+Scott Little can provide more detail, but at launch of automatic lazyload for Lite mode users, there was a 1-2% improvement in FCP, but I believe LCP was neutral.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

[Chris Harrelson]

FYI: https://groups.google.com/a/chromium.org/g/blink-dev/c/bKn2DLuRdeU

TL;DR API owners do not think you have to unlaunch the feature, but we do need to specify the behavior.

[Alex Russell]

FYI:

https://groups.google.com/a/chromium.org/g/blink-dev/c/bKn2DLuRdeU

On Fri, May 1, 2020 at 1:47 PM Ben Greenstein <be...@google.com> wrote:

[Ben Greenstein]

Thanks Alex for clarifying the owners' position (and Chris for the pointer). Dom, let's discuss specifying the behavior.