>> 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 <[email protected]> wrote: > > A change of schedule doesn't really qualify as an experiment extension. > My LGTM from the previous intent > <https://groups.google.com/a/chromium.org/g/blink-dev/c/PhLkO3KITyw> 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 <[email protected]> wrote: > >> Where's the status entry for this? >> Joe Medley | Technical Writer, Chrome DevRel | [email protected] | >> 816-678-7195 >> *If an API's not documented it doesn't exist.* >> >> >> On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss <[email protected]> wrote: >> >>> A change of schedule doesn't really qualify as an experiment extension. >>> My LGTM from the previous intent >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/PhLkO3KITyw> >>> still stands. >>> >>> On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune <[email protected]> >>> wrote: >>> >>>> *Contact emails* >>>> >>>> [email protected], [email protected] >>>> >>>> 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 <iframe loading=lazy>. >>>> >>>> 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 >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader> >>>> >>>> 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 >>>> <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) 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 >>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> 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 <https://www.chromestatus.com/> >>>> >>>> Not yet. >>>> >>>> Links to previous Intent discussions >>>> >>>> Intent to Experiment >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/PhLkO3KITyw/m/dMl_Nf5aAgAJ> >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEy%2BVDL14VfnmGO2Nv_MmpAY064CiP7jAGhJxnCs6ERVbH%3DhSA%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEy%2BVDL14VfnmGO2Nv_MmpAY064CiP7jAGhJxnCs6ERVbH%3DhSA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUUptp5ReE3f%2BEW2Ky4uGdcn%3DH5y6r1R38y4JEjcsaAPw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUUptp5ReE3f%2BEW2Ky4uGdcn%3DH5y6r1R38y4JEjcsaAPw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEy%2BVDLtdwbOO_FoXupMV9en7R-27bjteb386UC8NGHcQbkFpQ%40mail.gmail.com.
