On Tue, Jun 28, 2022 at 9:26 AM Kenji Baheux <[email protected]> wrote:
> > > On Fri, Jun 24, 2022 at 4:39 PM Yoav Weiss <[email protected]> wrote: > >> >> >> On Fri, Jun 24, 2022 at 4:55 AM 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 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.. > > > >> 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 >>> <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 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? >> > Friendly ping on this question :) > >> >>> >>> 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. >>> >>> -- >>> 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%2BVD%2B4e%2BvU6aiP9bEmfWc0SD%2B7%2Be8ngNe_bn7vUGSWco4u0A%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEy%2BVD%2B4e%2BvU6aiP9bEmfWc0SD%2B7%2Be8ngNe_bn7vUGSWco4u0A%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/CAL5BFfWmqxn2miQ__F7Tpx5tkQJOQoOv4tuYvU4O2sY7dRma-w%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWmqxn2miQ__F7Tpx5tkQJOQoOv4tuYvU4O2sY7dRma-w%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/CAL5BFfWeAwWHNq%3DSPrhd01Q%2B29W865j-_a7Nb%3DZBc6U1KWr_0Q%40mail.gmail.com.
