> 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%2BVDJFkYfyUkipa57eg3XOogUtH%2B3e-rphPMNGT8yo1x3aOQ%40mail.gmail.com.
