Intent to Experiment: LazyEmbeds

312 views
Skip to first unread message

Minoru Chikamune

unread,
Jun 23, 2022, 10:55:47 PMJun 23
to blink-dev

Contact emails

chik...@chromium.org, sisid...@chromium.org


Explainer


Specification: https://github.com/nyaxt/lazyembeds


Summary: LazyEmbeds aims to improve LCP and power consumption by delaying the iframe loads outside the viewport when all of the following conditions are met.


  • The loading=eager or loading=lazy are not specified in the iframe tag.

  • The iframe's src URL matches a pre-curated list of 3rd party embeds that have opted-in to the experiment.

  • The page is visible.

  • The iframe's src URL must be cross origin.


LazyEmbeds doesn't load the offscreen iframes until the viewport comes near the iframe. So the iframes that are eligible for LazyEmbeds might not be loaded at all. Site authors can specify loading=eager on frames to opt-out LazyEmbeds.


The current LazyEmbeds implementations target a 1% stable channel for data gathering purposes. We don't release these LazyEmbeds as-is.


Blink component: Blink>Loader


TAG review

None


TAG review status

Not applicable


Risks

Interoperability and Compatibility

The goal of the experiment is to test if the idea actually improves page load UX. Once that is proven, we would like to start pitching in the standardization forum on having the new behavior part of the spec.


We have a rough sketch of how it would look like in terms of specification changes at https://github.com/nyaxt/lazyembeds. LazyEmbeds applies a different loading schedule to offscreen cross-origin <iframe>s. Site authors who believe offscreen content is a critical part of the user-experience may find this breaks their expectations. To restore the previous behavior, authors can specify loading=eager on those frames.


Ergonomics

Websites don’t have to do anything.


Activation

LazyEmbeds works without any developer activation.


Security and privacy

LazyEmbeds doesn't have any security and privacy concerns.


Goals for experimentation

We would like to judge if this is a good idea or not before we would like to validate our hypothesis using the performance data (e.g. Core Web Vitals and battery power consumption) collected through the experiment before we proceed to the next steps (open-ended discussion with other vendors, involved 3rd-parties).


Experimental timeline

We’d like to start an experimental 1% rollout in M104.


Any risks when the experiment finishes?

No.


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

Yes.


Is this feature fully tested by web-platform-tests?

No, through the experiment phase, but if the idea proves to be useful through the experiment and makes it to the spec, we will add WPTs to cover them.


Tracking bug

https://crbug.com/1247131


Launch bug

https://crbug.com/1247130


Links to previous Intent discussions

N/A


Link to entry on the feature dashboard

Not yet.


Yoav Weiss

unread,
Jun 24, 2022, 3:39:07 AMJun 24
to Minoru Chikamune, blink-dev
On Fri, Jun 24, 2022 at 4:55 AM Minoru Chikamune <chik...@chromium.org> wrote:

Contact emails

chik...@chromium.org, sisid...@chromium.org


Explainer


Specification: https://github.com/nyaxt/lazyembeds


Summary: LazyEmbeds aims to improve LCP and power consumption by delaying the iframe loads outside the viewport when all of the following conditions are met.


  • The loading=eager or loading=lazy are not specified in the iframe tag.

  • The iframe's src URL matches a pre-curated list of 3rd party embeds that have opted-in to the experiment.


How have the 3P embeds opted-in to the experiment? Is this a closed partner list for the experiment phase?

Am I correct in thinking that 3P embeds that would like this behavior (in the long term) can already opt-in by modifying their snippets to include `loading=lazy`?
Or are there differences between this experiment and that approach, other than slow adoption by embedders?
 
  • The page is visible.

  • The iframe's src URL must be cross origin.


LazyEmbeds doesn't load the offscreen iframes until the viewport comes near the iframe. So the iframes that are eligible for LazyEmbeds might not be loaded at all. Site authors can specify loading=eager on frames to opt-out LazyEmbeds.


The current LazyEmbeds implementations target a 1% stable channel for data gathering purposes. We don't release these LazyEmbeds as-is.


Blink component: Blink>Loader


TAG review

None


TAG review status

Not applicable


Risks

Interoperability and Compatibility

The goal of the experiment is to test if the idea actually improves page load UX. Once that is proven, we would like to start pitching in the standardization forum on having the new behavior part of the spec.


We have a rough sketch of how it would look like in terms of specification changes at https://github.com/nyaxt/lazyembeds. LazyEmbeds applies a different loading schedule to offscreen cross-origin <iframe>s. Site authors who believe offscreen content is a critical part of the user-experience may find this breaks their expectations. To restore the previous behavior, authors can specify loading=eager on those frames.


Ergonomics

Websites don’t have to do anything.


Activation

LazyEmbeds works without any developer activation.


Security and privacy

LazyEmbeds doesn't have any security and privacy concerns.


Goals for experimentation

We would like to judge if this is a good idea or not before we would like to validate our hypothesis using the performance data (e.g. Core Web Vitals and battery power consumption) collected through the experiment before we proceed to the next steps (open-ended discussion with other vendors, involved 3rd-parties).


Experimental timeline

We’d like to start an experimental 1% rollout in M104.


What's the end milestone for this experiment?
 

Any risks when the experiment finishes?

No.


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

Yes.


Is this feature fully tested by web-platform-tests?

No, through the experiment phase, but if the idea proves to be useful through the experiment and makes it to the spec, we will add WPTs to cover them.


Tracking bug

https://crbug.com/1247131


Launch bug

https://crbug.com/1247130


Links to previous Intent discussions

N/A


Link to entry on the feature dashboard

Not yet.


--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEy%2BVD%2B4e%2BvU6aiP9bEmfWc0SD%2B7%2Be8ngNe_bn7vUGSWco4u0A%40mail.gmail.com.

Kenji Baheux

unread,
Jun 28, 2022, 3:26:37 AMJun 28
to Yoav Weiss, Minoru Chikamune, blink-dev
On Fri, Jun 24, 2022 at 4:39 PM Yoav Weiss <yoav...@chromium.org> wrote:


On Fri, Jun 24, 2022 at 4:55 AM Minoru Chikamune <chik...@chromium.org> wrote:

Contact emails

chik...@chromium.org, sisid...@chromium.org


Explainer


Specification: https://github.com/nyaxt/lazyembeds


Summary: LazyEmbeds aims to improve LCP and power consumption by delaying the iframe loads outside the viewport when all of the following conditions are met.


  • The loading=eager or loading=lazy are not specified in the iframe tag.

  • The iframe's src URL matches a pre-curated list of 3rd party embeds that have opted-in to the experiment.


How have the 3P embeds opted-in to the experiment? Is this a closed partner list for the experiment phase?

Sorry for the miscommunication.

There isn't an actual opt-in. For the purpose of establishing the potential benefits, the code is applying loading=lazy to a small list of popular embeds. We gave a heads-up to these embedders as a matter of courtesy, and to give folks the opportunity to push back or share concerns. So far, we haven't heard any major concerns.

We'll revisit this particular point and re-engage with owners of popular embeds after the experiment concludes, assuming that the impact is significant.

In addition, embed owners can opt-out from the experiment by setting loading=eager. That said, we would love to hear why folks feel compelled to opt-out, and adjust our approach as necessary.
 

Am I correct in thinking that 3P embeds that would like this behavior (in the long term) can already opt-in by modifying their snippets to include `loading=lazy`?

Yes, some embedders might be able to achieve the same behavior by setting loading=lazy.
One of the embedders we talked to has already made that change for their default snippet.

However, it might not be practical to do so for the embeds already integrated (hardcoded) by various websites.

 

Yoav Weiss

unread,
Jun 28, 2022, 3:33:21 AMJun 28
to Kenji Baheux, Minoru Chikamune, blink-dev
On Tue, Jun 28, 2022 at 9:26 AM Kenji Baheux <kenji...@chromium.org> wrote:


On Fri, Jun 24, 2022 at 4:39 PM Yoav Weiss <yoav...@chromium.org> wrote:


On Fri, Jun 24, 2022 at 4:55 AM Minoru Chikamune <chik...@chromium.org> wrote:

Contact emails

chik...@chromium.org, sisid...@chromium.org


Explainer


Specification: https://github.com/nyaxt/lazyembeds


Summary: LazyEmbeds aims to improve LCP and power consumption by delaying the iframe loads outside the viewport when all of the following conditions are met.


  • The loading=eager or loading=lazy are not specified in the iframe tag.

  • The iframe's src URL matches a pre-curated list of 3rd party embeds that have opted-in to the experiment.


How have the 3P embeds opted-in to the experiment? Is this a closed partner list for the experiment phase?

Sorry for the miscommunication.

There isn't an actual opt-in. For the purpose of establishing the potential benefits, the code is applying loading=lazy to a small list of popular embeds. We gave a heads-up to these embedders as a matter of courtesy, and to give folks the opportunity to push back or share concerns. So far, we haven't heard any major concerns.

We'll revisit this particular point and re-engage with owners of popular embeds after the experiment concludes, assuming that the impact is significant.

In addition, embed owners can opt-out from the experiment by setting loading=eager. That said, we would love to hear why folks feel compelled to opt-out, and adjust our approach as necessary.

Thanks for clarifying!
 
 

Am I correct in thinking that 3P embeds that would like this behavior (in the long term) can already opt-in by modifying their snippets to include `loading=lazy`?

Yes, some embedders might be able to achieve the same behavior by setting loading=lazy.
One of the embedders we talked to has already made that change for their default snippet.

However, it might not be practical to do so for the embeds already integrated (hardcoded) by various websites.

Yeah, large-scale deployment is hard..
Friendly ping on this question :)

Kenji Baheux

unread,
Jun 30, 2022, 2:15:41 AMJun 30
to Yoav Weiss, Minoru Chikamune, blink-dev
Just 1 milestone should be enough, assuming that everything goes according to plan.

Yoav Weiss

unread,
Jun 30, 2022, 5:33:12 AMJun 30
to Kenji Baheux, Minoru Chikamune, blink-dev
LGTM to experiment M104
Reply all
Reply to author
Forward
0 new messages