Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

['Joe Medley' via blink-dev]

Thanks!
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 1, 2022 at 10:06 PM Minoru Chikamune 
wrote:

> >> Where's the status entry for this?
> > I'll create a chrome status entry. Thank you for pointing this out.
>
> I've created a chrome status entry.
> https://chromestatus.com/guide/edit/5104987642789888
>
>
> On Tue, Aug 2, 2022 at 10:06 AM Minoru Chikamune 
> wrote:
>
>> > A change of schedule doesn't really qualify as an experiment extension.
>> My LGTM from the previous intent
>>  still
>> stands.
>>
>> Oh, I see.
>>
>> > Where's the status entry for this?
>>
>> I'll create a chrome status entry. Thank you for pointing this out.
>>
>>
>> On Tue, Aug 2, 2022 at 2:50 AM Joe Medley  wrote:
>>
>>> Where's the status entry for this?
>>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>> 816-678-7195 <(816)%20678-7195>
>>> *If an API's not documented it doesn't exist.*
>>>
>>>
>>> On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss 
>>> wrote:
>>>
 A change of schedule doesn't really qualify as an experiment extension.
 My LGTM from the previous intent
 
 still stands.

 On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune <
 chikam...@chromium.org> wrote:

> *Contact emails*
>
> chikam...@chromium.org, sisidov...@chromium.org
>
> Explainer:
>
>-
>
>https://github.com/nyaxt/lazyembeds
>
>
> Specification: https://github.com/nyaxt/lazyembeds
>
> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
> outside the viewport when all of the following conditions are met.
>
>
>-
>
>The loading=eager or loading=lazy attribute values are not
>specified in the iframe tag.
>
>
>-
>
>The iframe's src URL matches a pre-curated list of cross-origin
>embeds (for the sake of quick experimentation).
>
>
>-
>
>The page is visible.
>-
>
>The iframe's src URL must be cross origin.
>-
>
>The main frame is not loaded in the following ways. In the
>following operations, the user probably wants to avoid any breakage 
> caused
>by LazyEmbeds.
>-
>
>   The main frame is reloaded.
>   -
>
>   The main frame is a result after the user (re)submits a form.
>
>
> LazyEmbeds has a timeout mechanism that loads all the iframes that are
> eligible for LazyEmbeds after a few seconds have elapsed even when the
> viewport doesn't come near the iframe. This timeout mechanism is the main
> difference between  LazyEmbeds and .
>
> Site authors can specify loading=eager on frames to opt-out of
> LazyEmbeds.
>
> The current LazyEmbeds implementations target a 1% stable channel for
> data gathering purposes. We don't have any plan to release LazyEmbeds in
> its current form. This experiment is to help us assess the potential
> impact, in order to motivate a proper, launchable, design.
>
> Blink component: Blink>Loader
> 
>
> TAG review
>
> None
>
> TAG review status
>
> Not applicable
>
> RisksInteroperability 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
> 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) collected through the experiment before we proceed to the next
> steps (open-ended discussion with other vendors, involved 3rd-parties).
>
> Reason this experiment is being extended
>
> The previous timeline was to start an experi

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

[Minoru Chikamune]

>> Where's the status entry for this?
> I'll create a chrome status entry. Thank you for pointing this out.

I've created a chrome status entry.
https://chromestatus.com/guide/edit/5104987642789888


On Tue, Aug 2, 2022 at 10:06 AM Minoru Chikamune 
wrote:

> > A change of schedule doesn't really qualify as an experiment extension.
> My LGTM from the previous intent
>  still
> stands.
>
> Oh, I see.
>
> > Where's the status entry for this?
>
> I'll create a chrome status entry. Thank you for pointing this out.
>
>
> On Tue, Aug 2, 2022 at 2:50 AM Joe Medley  wrote:
>
>> Where's the status entry for this?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>  816-678-7195
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss  wrote:
>>
>>> A change of schedule doesn't really qualify as an experiment extension.
>>> My LGTM from the previous intent
>>> 
>>> still stands.
>>>
>>> On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
>>> wrote:
>>>
 *Contact emails*

 chikam...@chromium.org, sisidov...@chromium.org

 Explainer:

-

https://github.com/nyaxt/lazyembeds


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

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


-

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


-

The iframe's src URL matches a pre-curated list of cross-origin
embeds (for the sake of quick experimentation).


-

The page is visible.
-

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

The main frame is not loaded in the following ways. In the
following operations, the user probably wants to avoid any breakage 
 caused
by LazyEmbeds.
-

   The main frame is reloaded.
   -

   The main frame is a result after the user (re)submits a form.


 LazyEmbeds has a timeout mechanism that loads all the iframes that are
 eligible for LazyEmbeds after a few seconds have elapsed even when the
 viewport doesn't come near the iframe. This timeout mechanism is the main
 difference between  LazyEmbeds and .

 Site authors can specify loading=eager on frames to opt-out of
 LazyEmbeds.

 The current LazyEmbeds implementations target a 1% stable channel for
 data gathering purposes. We don't have any plan to release LazyEmbeds in
 its current form. This experiment is to help us assess the potential
 impact, in order to motivate a proper, launchable, design.

 Blink component: Blink>Loader
 

 TAG review

 None

 TAG review status

 Not applicable

 RisksInteroperability 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
 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) collected through the experiment before we proceed to the next
 steps (open-ended discussion with other vendors, involved 3rd-parties).

 Reason this experiment is being extended

 The previous timeline was to start an experimental 1% stable rollout
 in M104. But while running experiments in M104 beta, we have noticed
 several problems. So we would like to change the schedule. We want to
 restart the experiment in M105 beta and 1% stable rollout in M105.

 The following are the notable differences between M104 and M105.

-

The main frame is not loaded in the following ways. In the

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

[Minoru Chikamune]

> A change of schedule doesn't really qualify as an experiment extension.
My LGTM from the previous intent
 still
stands.

Oh, I see.

> Where's the status entry for this?

I'll create a chrome status entry. Thank you for pointing this out.


On Tue, Aug 2, 2022 at 2:50 AM Joe Medley  wrote:

> Where's the status entry for this?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss  wrote:
>
>> A change of schedule doesn't really qualify as an experiment extension.
>> My LGTM from the previous intent
>> 
>> still stands.
>>
>> On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
>> wrote:
>>
>>> *Contact emails*
>>>
>>> chikam...@chromium.org, sisidov...@chromium.org
>>>
>>> Explainer:
>>>
>>>-
>>>
>>>https://github.com/nyaxt/lazyembeds
>>>
>>>
>>> Specification: https://github.com/nyaxt/lazyembeds
>>>
>>> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
>>> outside the viewport when all of the following conditions are met.
>>>
>>>
>>>-
>>>
>>>The loading=eager or loading=lazy attribute values are not specified
>>>in the iframe tag.
>>>
>>>
>>>-
>>>
>>>The iframe's src URL matches a pre-curated list of cross-origin
>>>embeds (for the sake of quick experimentation).
>>>
>>>
>>>-
>>>
>>>The page is visible.
>>>-
>>>
>>>The iframe's src URL must be cross origin.
>>>-
>>>
>>>The main frame is not loaded in the following ways. In the following
>>>operations, the user probably wants to avoid any breakage caused by
>>>LazyEmbeds.
>>>-
>>>
>>>   The main frame is reloaded.
>>>   -
>>>
>>>   The main frame is a result after the user (re)submits a form.
>>>
>>>
>>> LazyEmbeds has a timeout mechanism that loads all the iframes that are
>>> eligible for LazyEmbeds after a few seconds have elapsed even when the
>>> viewport doesn't come near the iframe. This timeout mechanism is the main
>>> difference between  LazyEmbeds and .
>>>
>>> Site authors can specify loading=eager on frames to opt-out of
>>> LazyEmbeds.
>>>
>>> The current LazyEmbeds implementations target a 1% stable channel for
>>> data gathering purposes. We don't have any plan to release LazyEmbeds in
>>> its current form. This experiment is to help us assess the potential
>>> impact, in order to motivate a proper, launchable, design.
>>>
>>> Blink component: Blink>Loader
>>> 
>>>
>>> TAG review
>>>
>>> None
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> RisksInteroperability 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
>>> 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) collected through the experiment before we proceed to the next
>>> steps (open-ended discussion with other vendors, involved 3rd-parties).
>>>
>>> Reason this experiment is being extended
>>>
>>> The previous timeline was to start an experimental 1% stable rollout in
>>> M104. But while running experiments in M104 beta, we have noticed several
>>> problems. So we would like to change the schedule. We want to restart the
>>> experiment in M105 beta and 1% stable rollout in M105.
>>>
>>> The following are the notable differences between M104 and M105.
>>>
>>>-
>>>
>>>The main frame is not loaded in the following ways. In the following
>>>operations, the user probably wants to avoid any breakage caused by
>>>LazyEmbeds.
>>>-
>>>
>>>   The main frame is reloaded.
>>>   -
>>>
>>>   The main frame is a result after the user (re)submits a form.
>>>   -
>>>
>>>Added a timeout mechanism that loads all the iframes that are
>>>eligible for LazyEmbeds after a few seconds have elapsed even when the
>>>viewport 

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

['Joe Medley' via blink-dev]

Where's the status entry for this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss  wrote:

> A change of schedule doesn't really qualify as an experiment extension. My
> LGTM from the previous intent
> 
> still stands.
>
> On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
> wrote:
>
>> *Contact emails*
>>
>> chikam...@chromium.org, sisidov...@chromium.org
>>
>> Explainer:
>>
>>-
>>
>>https://github.com/nyaxt/lazyembeds
>>
>>
>> Specification: https://github.com/nyaxt/lazyembeds
>>
>> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
>> outside the viewport when all of the following conditions are met.
>>
>>
>>-
>>
>>The loading=eager or loading=lazy attribute values are not specified
>>in the iframe tag.
>>
>>
>>-
>>
>>The iframe's src URL matches a pre-curated list of cross-origin
>>embeds (for the sake of quick experimentation).
>>
>>
>>-
>>
>>The page is visible.
>>-
>>
>>The iframe's src URL must be cross origin.
>>-
>>
>>The main frame is not loaded in the following ways. In the following
>>operations, the user probably wants to avoid any breakage caused by
>>LazyEmbeds.
>>-
>>
>>   The main frame is reloaded.
>>   -
>>
>>   The main frame is a result after the user (re)submits a form.
>>
>>
>> LazyEmbeds has a timeout mechanism that loads all the iframes that are
>> eligible for LazyEmbeds after a few seconds have elapsed even when the
>> viewport doesn't come near the iframe. This timeout mechanism is the main
>> difference between  LazyEmbeds and .
>>
>> Site authors can specify loading=eager on frames to opt-out of LazyEmbeds.
>>
>> The current LazyEmbeds implementations target a 1% stable channel for
>> data gathering purposes. We don't have any plan to release LazyEmbeds in
>> its current form. This experiment is to help us assess the potential
>> impact, in order to motivate a proper, launchable, design.
>>
>> Blink component: Blink>Loader
>> 
>>
>> TAG review
>>
>> None
>>
>> TAG review status
>>
>> Not applicable
>>
>> RisksInteroperability 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 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) collected through the experiment before we proceed to the next
>> steps (open-ended discussion with other vendors, involved 3rd-parties).
>>
>> Reason this experiment is being extended
>>
>> The previous timeline was to start an experimental 1% stable rollout in
>> M104. But while running experiments in M104 beta, we have noticed several
>> problems. So we would like to change the schedule. We want to restart the
>> experiment in M105 beta and 1% stable rollout in M105.
>>
>> The following are the notable differences between M104 and M105.
>>
>>-
>>
>>The main frame is not loaded in the following ways. In the following
>>operations, the user probably wants to avoid any breakage caused by
>>LazyEmbeds.
>>-
>>
>>   The main frame is reloaded.
>>   -
>>
>>   The main frame is a result after the user (re)submits a form.
>>   -
>>
>>Added a timeout mechanism that loads all the iframes that are
>>eligible for LazyEmbeds after a few seconds have elapsed even when the
>>viewport doesn't come near the iframe. This timeout mechanism is intended
>>to minimize the risk of breakage caused by LazyEmbeds.
>>-
>>
>>Expanded the pre-curated list of cross-origin embeds.
>>
>>
>> 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
>> 

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

[Yoav Weiss]

A change of schedule doesn't really qualify as an experiment extension. My
LGTM from the previous intent
 still
stands.

On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
wrote:

> *Contact emails*
>
> chikam...@chromium.org, sisidov...@chromium.org
>
> Explainer:
>
>-
>
>https://github.com/nyaxt/lazyembeds
>
>
> Specification: https://github.com/nyaxt/lazyembeds
>
> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
> outside the viewport when all of the following conditions are met.
>
>
>-
>
>The loading=eager or loading=lazy attribute values are not specified
>in the iframe tag.
>
>
>-
>
>The iframe's src URL matches a pre-curated list of cross-origin embeds
>(for the sake of quick experimentation).
>
>
>-
>
>The page is visible.
>-
>
>The iframe's src URL must be cross origin.
>-
>
>The main frame is not loaded in the following ways. In the following
>operations, the user probably wants to avoid any breakage caused by
>LazyEmbeds.
>-
>
>   The main frame is reloaded.
>   -
>
>   The main frame is a result after the user (re)submits a form.
>
>
> LazyEmbeds has a timeout mechanism that loads all the iframes that are
> eligible for LazyEmbeds after a few seconds have elapsed even when the
> viewport doesn't come near the iframe. This timeout mechanism is the main
> difference between  LazyEmbeds and .
>
> Site authors can specify loading=eager on frames to opt-out of LazyEmbeds.
>
> The current LazyEmbeds implementations target a 1% stable channel for data
> gathering purposes. We don't have any plan to release LazyEmbeds in its
> current form. This experiment is to help us assess the potential impact, in
> order to motivate a proper, launchable, design.
>
> Blink component: Blink>Loader
> 
>
> TAG review
>
> None
>
> TAG review status
>
> Not applicable
>
> RisksInteroperability 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 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) collected through the experiment before we proceed to the next
> steps (open-ended discussion with other vendors, involved 3rd-parties).
>
> Reason this experiment is being extended
>
> The previous timeline was to start an experimental 1% stable rollout in
> M104. But while running experiments in M104 beta, we have noticed several
> problems. So we would like to change the schedule. We want to restart the
> experiment in M105 beta and 1% stable rollout in M105.
>
> The following are the notable differences between M104 and M105.
>
>-
>
>The main frame is not loaded in the following ways. In the following
>operations, the user probably wants to avoid any breakage caused by
>LazyEmbeds.
>-
>
>   The main frame is reloaded.
>   -
>
>   The main frame is a result after the user (re)submits a form.
>   -
>
>Added a timeout mechanism that loads all the iframes that are eligible
>for LazyEmbeds after a few seconds have elapsed even when the viewport
>doesn't come near the iframe. This timeout mechanism is intended to
>minimize the risk of breakage caused by LazyEmbeds.
>-
>
>Expanded the pre-curated list of cross-origin embeds.
>
>
> 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 das

[blink-dev] Intent to Extend Experiment: LazyEmbeds

[Minoru Chikamune]

*Contact emails*

chikam...@chromium.org, sisidov...@chromium.org

Explainer:

   -

   https://github.com/nyaxt/lazyembeds


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

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


   -

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


   -

   The iframe's src URL matches a pre-curated list of cross-origin embeds
   (for the sake of quick experimentation).


   -

   The page is visible.
   -

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

   The main frame is not loaded in the following ways. In the following
   operations, the user probably wants to avoid any breakage caused by
   LazyEmbeds.
   -

  The main frame is reloaded.
  -

  The main frame is a result after the user (re)submits a form.


LazyEmbeds has a timeout mechanism that loads all the iframes that are
eligible for LazyEmbeds after a few seconds have elapsed even when the
viewport doesn't come near the iframe. This timeout mechanism is the main
difference between  LazyEmbeds and .

Site authors can specify loading=eager on frames to opt-out of LazyEmbeds.

The current LazyEmbeds implementations target a 1% stable channel for data
gathering purposes. We don't have any plan to release LazyEmbeds in its
current form. This experiment is to help us assess the potential impact, in
order to motivate a proper, launchable, design.

Blink component: Blink>Loader


TAG review

None

TAG review status

Not applicable

RisksInteroperability 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 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) collected through the experiment before we proceed to the next
steps (open-ended discussion with other vendors, involved 3rd-parties).

Reason this experiment is being extended

The previous timeline was to start an experimental 1% stable rollout in
M104. But while running experiments in M104 beta, we have noticed several
problems. So we would like to change the schedule. We want to restart the
experiment in M105 beta and 1% stable rollout in M105.

The following are the notable differences between M104 and M105.

   -

   The main frame is not loaded in the following ways. In the following
   operations, the user probably wants to avoid any breakage caused by
   LazyEmbeds.
   -

  The main frame is reloaded.
  -

  The main frame is a result after the user (re)submits a form.
  -

   Added a timeout mechanism that loads all the iframes that are eligible
   for LazyEmbeds after a few seconds have elapsed even when the viewport
   doesn't come near the iframe. This timeout mechanism is intended to
   minimize the risk of breakage caused by LazyEmbeds.
   -

   Expanded the pre-curated list of cross-origin embeds.


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.

Links to previous Intent discussions

Intent to Experiment


-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev