LGTM to experiment M104 On Thu, Jun 30, 2022 at 8:15 AM Kenji Baheux <[email protected]> wrote:
> Just 1 milestone should be enough, assuming that everything goes according > to plan. > > On Tue, Jun 28, 2022 at 4:33 PM Yoav Weiss <[email protected]> wrote: > >> >> >> 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/CAL5BFfVroP7dkTmhg8aR1eV3Ov%2B9Yj7Akbs%2BRSnHQeAZ_gOe-w%40mail.gmail.com.
