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.
