Intent to Ship: Lazily load below-the-fold images and iframes

13,583 views
Skip to first unread message

Scott Little

unread,
Apr 6, 2019, 12:40:14 AM4/6/19
to blink-dev, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda

Contact emails

scli...@chromium.org, be...@chromium.org, rajen...@chromium.org


Explainer

https://github.com/scott-little/lazyload

https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit


Spec

Spec change pull request: https://github.com/whatwg/html/pull/3752

Tag review: https://github.com/w3ctag/design-reviews/issues/361 (started recently, since we initially didn't think one was necessary, but better late than never).


Summary

Support deferring the load of below-the-fold images and iframes on the page until the user scrolls near them. This is to reduce data usage, memory usage, and speed up above-the-fold content. Web pages can use the "loading" attribute on <img> and <iframe> elements to control and interact with the default lazy loading behavior, with possible values "lazy", "eager", and "auto" (which is equivalent to leaving the "loading" attribute unset).


Deferred content will start loading in when the user scrolls the viewport within a particular distance of it. The load-in distance depends on factors like the speed of the network, tuned such that content is typically finished loading in by the time it becomes visible.


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/czmmZUd4Vww/1-H6j-zdAwAJ


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, all platforms will support lazily loading <img> and <iframe> elements with loading="lazy" set on them.


On Android Chrome with Data saver turned on, elements with loading="auto" or unset will also be lazily loaded if Chrome determines them to be good candidates for lazy loading (according to heuristics). Setting loading="eager" on the image or iframe element will still prevent it from being lazily loaded though.


Risks

Interoperability and Compatibility

Firefox: No public signals

Edge: No public signals

Safari: Some public support

  • A WebKit developer has mentioned that Apple is interested in this kind of feature and is a reviewer on the LazyLoad spec pull request.

Web developers: Positive signals

Elements deferred by LazyLoad will have their onload event delayed until they load in later on (e.g. after the user scrolls nearby), which could happen after the document's onload event fires.


Ads that count impressions when an ad is loaded instead of when the ad is seen by the user (i.e. becomes visible in the viewport) could see their impression counts change for ads are currently often loaded but not seen. Users will still see lazily loaded ads just as often as they would have otherwise though.


Other compatibility risks are listed in the design doc.


Ergonomics

Deferring images makes use of the image replacement feature in Blink in order to avoid reflows when images load in later.


Some browser features (e.g. Print, Save Page As) that expect all resources to be fully loaded will currently show any deferred images or frames as blank boxes if they haven't loaded in yet, but this is something that will be fixed after the initial shipping (e.g. by forcing all deferred content to load in immediately, and block the print/save operation on that). More details here.


Activation

Sites can use LazyLoad by setting the attribute loading="lazy" on images or iframes. Sites can also prevent image or iframe elements from being lazily loaded by setting loading="eager" on them. Sites can detect LazyLoad support in JavaScript by checking if the "loading" property is defined, in a similar way to how many other features can be detected, e.g.:


if ('loading' in HTMLImageElement.prototype) { … }


We're also exploring adding a Client Hint for LazyLoad support.


Debuggability

When images are being lazily loaded, a message is logged to the console. No other DevTools integration is currently planned.


Demo

At time of writing, LazyLoad can be experimented with by going to chrome://flags and turning on both "Enable lazy frame loading" and "Enable lazy image loading". This will turn on LazyLoad for images and iframes marked loading="lazy", plus those marked loading="auto" or without any "loading" attribute set that are well suited to being lazily loaded, similar to how the feature will behave for Android Chrome Data Saver users when launched.


Is this feature fully tested by web-platform-tests?

The tests are in progress right now, but it will be fully tested by web-platform-tests.


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=709494


Entry on the feature dashboard

https://www.chromestatus.com/features/5645767347798016


addyo...@gmail.com

unread,
Apr 7, 2019, 9:19:32 PM4/7/19
to blink-dev
Non-owner LGTM. Very very excited to see this work finally shipping! Scott, did we resolve if the implementation we're shipping..

(1) Has <picture> support wired up? We had discussed this with Yoav but unsure of current status.

(2) Whether developers are likely to see double fetch entries in the DevTools network panel? I recall we fetch the first 2KB of images on page load & the remaining bytes when they're about to see the image.

For (2) I guess we can also wait and see how the discussion in https://github.com/w3c/resource-timing/issues/205 evolves.

Kenji Baheux

unread,
Apr 7, 2019, 10:03:05 PM4/7/19
to addyo...@gmail.com, blink-dev
Non owner LGTM.

We all know that pages have slowly become quite heavy, almost as much bytes as the original DOOM game ;)

We also know that this approach is very effective in terms of improving the user experience, as seen via AMP articles.

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e70588ac-6395-42f2-94f0-40daafff8ec8%40chromium.org.

Yoav Weiss

unread,
Apr 8, 2019, 7:56:15 AM4/8/19
to Scott Little, blink-dev, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda
I share the general excitement, and think this feature is long overdue on the web. Thanks for working on this! :)

On Sat, Apr 6, 2019 at 12:40 AM Scott Little <scli...@chromium.org> wrote:

Contact emails

scli...@chromium.org, be...@chromium.org, rajen...@chromium.org


Explainer

https://github.com/scott-little/lazyload

https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit


Spec

Spec change pull request: https://github.com/whatwg/html/pull/3752

Tag review: https://github.com/w3ctag/design-reviews/issues/361 (started recently, since we initially didn't think one was necessary, but better late than never).


Summary

Support deferring the load of below-the-fold images and iframes on the page until the user scrolls near them. This is to reduce data usage, memory usage, and speed up above-the-fold content. Web pages can use the "loading" attribute on <img> and <iframe> elements to control and interact with the default lazy loading behavior, with possible values "lazy", "eager", and "auto" (which is equivalent to leaving the "loading" attribute unset).


Deferred content will start loading in when the user scrolls the viewport within a particular distance of it. The load-in distance depends on factors like the speed of the network, tuned such that content is typically finished loading in by the time it becomes visible.


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/czmmZUd4Vww/1-H6j-zdAwAJ


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes, all platforms will support lazily loading <img> and <iframe> elements with loading="lazy" set on them.


On Android Chrome with Data saver turned on, elements with loading="auto" or unset will also be lazily loaded if Chrome determines them to be good candidates for lazy loading (according to heuristics). Setting loading="eager" on the image or iframe element will still prevent it from being lazily loaded though.


Risks

Interoperability and Compatibility

Firefox: No public signals


Have we tried to reach out to them?
 

Edge: No public signals

Safari: Some public support

  • A WebKit developer has mentioned that Apple is interested in this kind of feature and is a reviewer on the LazyLoad spec pull request.

Web developers: Positive signals

Elements deferred by LazyLoad will have their onload event delayed until they load in later on (e.g. after the user scrolls nearby), which could happen after the document's onload event fires.


This is the most concerning part, IMO.
Have you tried to quantify how often that happens and what are the implications? Did you run Finch trials with the feature? If so, have you seen any change in metrics that indicate that users may be seeing broken pages? (e.g. page reloads)
 

Ads that count impressions when an ad is loaded instead of when the ad is seen by the user (i.e. becomes visible in the viewport) could see their impression counts change for ads are currently often loaded but not seen. Users will still see lazily loaded ads just as often as they would have otherwise though.


Seems to me that ads that count impressions that way are getting heavily skewed data, and this change will bring them closer to "real" impressions.
 

Other compatibility risks are listed in the design doc.


Ergonomics

Deferring images makes use of the image replacement feature in Blink in order to avoid reflows when images load in later.


Some browser features (e.g. Print, Save Page As) that expect all resources to be fully loaded will currently show any deferred images or frames as blank boxes if they haven't loaded in yet, but this is something that will be fixed after the initial shipping (e.g. by forcing all deferred content to load in immediately, and block the print/save operation on that). More details here.


What would be the experience if someone were to print a page or save it in the mean time?
 

Activation

Sites can use LazyLoad by setting the attribute loading="lazy" on images or iframes. Sites can also prevent image or iframe elements from being lazily loaded by setting loading="eager" on them. Sites can detect LazyLoad support in JavaScript by checking if the "loading" property is defined, in a similar way to how many other features can be detected, e.g.:


if ('loading' in HTMLImageElement.prototype) { … }



Have you considered a full page opt-{in,out}? I'm curious if this is something developers would be interested in.
Also, as far as developer advice goes, what should it be? Should developers building new sites today try to mark their in-viewport images (for some definition of in-viewport) as "eager" and the rest as "lazy"? Will we try to do that automatically for them in the future as part of "auto"?

It would also be good to think about the migration path from JS based lazy loading to native one. Addy's approach ("cross browser" section) seems reasonable, as long as it's applied only to out-of-viewport images. 

 

We're also exploring adding a Client Hint for LazyLoad support.


I'll answer there, but I'm not 100% sure this fits the CH model. An extension to the Accept header may be more appropriate.
 

Debuggability

When images are being lazily loaded, a message is logged to the console. No other DevTools integration is currently planned.


Demo

At time of writing, LazyLoad can be experimented with by going to chrome://flags and turning on both "Enable lazy frame loading" and "Enable lazy image loading". This will turn on LazyLoad for images and iframes marked loading="lazy", plus those marked loading="auto" or without any "loading" attribute set that are well suited to being lazily loaded, similar to how the feature will behave for Android Chrome Data Saver users when launched.


Is this feature fully tested by web-platform-tests?

The tests are in progress right now, but it will be fully tested by web-platform-tests.


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=709494


Entry on the feature dashboard

https://www.chromestatus.com/features/5645767347798016


--
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 blink-dev+...@chromium.org.

smaug

unread,
Apr 8, 2019, 9:54:41 AM4/8/19
to Yoav Weiss, Scott Little, blink-dev, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda
On 4/8/19 2:55 PM, Yoav Weiss wrote:
> I share the general excitement, and think this feature is long overdue on the web. Thanks for working on this! :)
>
> On Sat, Apr 6, 2019 at 12:40 AM Scott Little <scli...@chromium.org <mailto:scli...@chromium.org>> wrote:
>
> Contact emails
>
> scli...@chromium.org <mailto:scli...@chromium.org>, be...@chromium.org <mailto:be...@chromium.org>, rajen...@chromium.org
> <mailto:rajen...@chromium.org>
> Tag review: https://github.com/w3ctag/design-reviews/issues/361(started recently, since we initially didn't think one was necessary, but better
> late than never).
>
>
> Summary
>
> Support deferring the load of below-the-fold images and iframes on the page until the user scrolls near them. This is to reduce data usage, memory
> usage, and speed up above-the-fold content. Web pages can use the "loading" attribute
> <https://github.com/scott-little/lazyload#ways-the-loading-attribute-can-be-used>on <img> and <iframe> elements to control and interact with the
> default lazy loading behavior, with possible values "lazy", "eager", and "auto" (which is equivalent to leaving the "loading" attribute unset).
>
>
> Deferred content will start loading in when the user scrolls the viewport within a particular distance of it. The load-in distance
> <https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit#heading=h.vac2t7cv55yr>depends on factors like the speed of
> the network, tuned such that content is typically finished loading in by the time it becomes visible.
>
>
> Link to “Intent to Implement” blink-dev discussion
>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/czmmZUd4Vww/1-H6j-zdAwAJ
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>
> Yes, all platforms will support lazily loading <img> and <iframe> elements with loading="lazy" set on them.
>
>
> On Android Chrome with Data saver turned on, elements with loading="auto" or unset will also be lazily loaded if Chrome determines them to be good
> candidates for lazy loading (according to heuristics
> <https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit#heading=h.zhgziaxqd8jf>).

Sounds like a very good way to break pages semi-accidentally. How can one know what the heuristics are if they aren't spec'ed.

How does this all affect to top level page's load event firing?
If user scrolls down during page load and more lazyloaded resources are loaded, do those loads block page's load event to fire?


-Olli



> Setting loading="eager" on the
> image or iframe element will still prevent it from being lazily loaded though.
>
>
> Risks
>
> Interoperability and Compatibility
>
> Firefox: No public signals
>
>
> Have we tried to reach out to them?
>
> Edge: No public signals
>
> Safari: Some public support
>
> *
>
> A WebKit developer has mentioned <https://github.com/whatwg/html/issues/2806#issuecomment-378831265>that Apple is interested in this kind of
> feature and is a reviewer on the LazyLoad spec pull request <https://github.com/whatwg/html/pull/3752>.
>
> Web developers: Positive signals
>
> *
>
> A thread on WICG <https://discourse.wicg.io/t/a-standard-way-to-lazy-load-images/1153>about lazy loading images
>
> Elements deferred by LazyLoad will have their onload event delayed <https://github.com/scott-little/lazyload#onload-events>until they load in
> later on (e.g. after the user scrolls nearby), which could happen after the document's onload event fires.
>
>
> This is the most concerning part, IMO.
> Have you tried to quantify how often that happens and what are the implications? Did you run Finch trials with the feature? If so, have you seen any
> change in metrics that indicate that users may be seeing broken pages? (e.g. page reloads)
>
>
> Ads that count impressions when an ad is loaded instead of when the ad is seen by the user (i.e. becomes visible in the viewport) could see their
> impression counts change for ads are currently often loaded but not seen. Users will still see lazily loaded ads just as often as they would have
> otherwise though.
>
>
> Seems to me that ads that count impressions that way are getting heavily skewed data, and this change will bring them closer to "real" impressions.
>
>
> Other compatibility risks are listed in the design doc
> <https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit#heading=h.ux7482iom65p>.
>
>
> Ergonomics
>
> Deferring images makes use of the image replacement feature
> <https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit#>in Blink in order to avoid reflows when images load in later.
>
>
> Some browser features (e.g. Print, Save Page As) that expect all resources to be fully loaded will currently show any deferred images or frames as
> blank boxes if they haven't loaded in yet, but this is something that will be fixed after the initial shipping (e.g. by forcing all deferred
> content to load in immediately, and block the print/save operation on that). More details here
> <https://docs.google.com/document/d/1e8ZbVyUwgIkQMvJma3kKUDg8UUkLRRdANStqKuOIvHg/edit?pli=1#heading=h.6ucgagtq62wh>.
>
>
> What would be the experience if someone were to print a page or save it in the mean time?
>
>
> Activation
>
> Sites can use LazyLoad by setting the attribute loading="lazy" on images or iframes. Sites can also prevent image or iframe elements from being
> lazily loaded by setting loading="eager" on them. Sites can detect LazyLoad support in JavaScript by checking if the "loading" property is
> defined, in a similar way <https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection>to how many
> other features can be detected, e.g.:
>
>
> if ('loading' in HTMLImageElement.prototype) { … }
>
>
>
> Have you considered a full page opt-{in,out}? I'm curious if this is something developers would be interested in.
> Also, as far as developer advice goes, what should it be? Should developers building new sites today try to mark their in-viewport images (for some
> definition of in-viewport) as "eager" and the rest as "lazy"? Will we try to do that automatically for them in the future as part of "auto"?
>
> It would also be good to think about the migration path from JS based lazy loading to native one. Addy's approach
> <https://addyosmani.com/blog/lazy-loading/> ("cross browser" section) seems reasonable, as long as it's applied only to out-of-viewport images.
>
> We're also exploring <https://bugs.chromium.org/p/chromium/issues/detail?id=949365>adding a Client Hint for LazyLoad support.
>
>
> I'll answer there, but I'm not 100% sure this fits the CH model. An extension to the Accept header may be more appropriate.
>
>
> Debuggability
>
> When images are being lazily loaded, a message is logged to the console. No other DevTools integration is currently planned.
>
>
> Demo
>
> At time of writing, LazyLoad can be experimented with by going to chrome://flags and turning on both "Enable lazy frame loading" and "Enable lazy
> image loading". This will turn on LazyLoad for images and iframes marked loading="lazy", plus those marked loading="auto" or without any "loading"
> attribute set that are well suited to being lazily loaded, similar to how the feature will behave for Android Chrome Data Saver users when launched.
>
>
> Is this feature fully tested by web-platform-tests?
>
> The tests are in progress <https://chromium-review.googlesource.com/c/chromium/src/+/1417117>right now, but it will be fully tested by
> web-platform-tests.
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=709494
>
>
> Entry on the feature dashboard
>
> https://www.chromestatus.com/features/5645767347798016
>
>
> --
> 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 blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBp5rV_uNeekijVoSezJXc5nf4RKTmHk4ZMe6tvosy9amtQQQ%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 blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgZqu%3DgVEpoeddu4J7GQfjNwOfqU3T%2BkQOAOhN693j53A%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgZqu%3DgVEpoeddu4J7GQfjNwOfqU3T%2BkQOAOhN693j53A%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Scott Little

unread,
Apr 8, 2019, 10:28:05 AM4/8/19
to addyo...@gmail.com, blink-dev
On Sun, Apr 7, 2019 at 9:19 PM <addyo...@gmail.com> wrote:
Non-owner LGTM. Very very excited to see this work finally shipping! Scott, did we resolve if the implementation we're shipping..

(1) Has <picture> support wired up? We had discussed this with Yoav but unsure of current status.

<picture> element support is on its way, the plan is to ship with it. The idea there is that specifying the "loading" attribute on the <img> element that's inside the <picture> element will apply to the whole <picture>, see the spec for more details.
 

(2) Whether developers are likely to see double fetch entries in the DevTools network panel? I recall we fetch the first 2KB of images on page load & the remaining bytes when they're about to see the image.

Yeah, both the range request and the later full fetch will currently appear in the DevTools network panel as separate requests.
 

For (2) I guess we can also wait and see how the discussion in https://github.com/w3c/resource-timing/issues/205 evolves. 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

zco...@gmail.com

unread,
Apr 8, 2019, 10:55:56 AM4/8/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
I am excited about this feature, and I'm happy that it's moving forward!

However, it's unclear to me whether the spec PR is ready to be merged as per WHATWG working mode. I think it would be good to make this clearer before owners approve shipping.

in...@wellness-heaven.de

unread,
Apr 8, 2019, 10:55:56 AM4/8/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
Interesting feature.
However, there seems to be an issue with loading of background images via css url().



Page navigation is broken since css background images are not loaded, see https://take.ms/ZO5tr

Is there any way to set the loading attribute to "eager" for css background images?

Thanks, Tassilo

tass...@googlemail.com

unread,
Apr 8, 2019, 10:55:56 AM4/8/19
to blink-dev, scli...@chromium.org, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
I have just tested this new lazy load experimental feature in Chrome (73.0.3683.103).

I found an issue with the loading of css background images.



The lazy loading breaks the page navigation / dropdown menu, as certain background images are suppressed: https://take.ms/GQzX4

Is there a way to pass the loading attribute "eager" also to css background images?


Am Montag, 8. April 2019 13:56:15 UTC+2 schrieb Yoav Weiss:
I share the general excitement, and think this feature is long overdue on the web. Thanks for working on this! :)

On Sat, Apr 6, 2019 at 12:40 AM Scott Little <scli...@chromium.org> wrote:

Contact emails



To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Scott Little

unread,
Apr 8, 2019, 10:57:42 AM4/8/19
to tass...@googlemail.com, blink-dev, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda
On Mon, Apr 8, 2019 at 9:11 AM <tass...@googlemail.com> wrote:
I have just tested this new lazy load experimental feature in Chrome (73.0.3683.103).

I found an issue with the loading of css background images.



The lazy loading breaks the page navigation / dropdown menu, as certain background images are suppressed: https://take.ms/GQzX4

 

Is there a way to pass the loading attribute "eager" also to css background images?

Not right now, although note that any lazy loading of CSS background images will only be done for Android Chrome users with Data Saver turned on, since there's also not any way of setting loading="lazy" on CSS background images either right now. The idea is that there's not many ways for CSS background images to interact with other parts of the page, so there's not really much that can go wrong with lazily loading CSS background images besides display bugs like this one that will be fixed.

jj

unread,
Apr 8, 2019, 11:14:04 AM4/8/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org

Support deferring the load of below-the-fold images and iframes on the page until the user scrolls near them. This is to reduce data usage, memory usage, and speed up above-the-fold content. Web pages can use the "loading" attribute on <img> and <iframe> elements to control and interact with the default lazy loading behavior, with possible values "lazy", "eager", and "auto" (which is equivalent to leaving the "loading" attribute unset)



 Shouldn't we have  a simple way to set loading=lazy|eager  for the whole document, something like
<body loading=lazy> ?

Writing the above, it comes in mind: Why is this not done with CSS?

That said, in my little world was more need for deferring background-image loading while most images/iframes are sinificant (or tiny enough not to care about).


heckt...@gmail.com

unread,
Apr 8, 2019, 1:36:41 PM4/8/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
Is there any way to tell an image to load with low priority?  (similar to lazysizes lazy preload)

example: https://realtruck.com/ - The menu images under the Category Menu.

We don't want them eager, but we wouldn't want them 'lazy' per say either since our goal is to never have a user see an image loading.

ad...@futtura.net

unread,
Apr 8, 2019, 1:36:41 PM4/8/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
Testing the  loading="lazy"  attribute here, some images have broken, see screenshots.

1. When page loaded, and scrolled down, the image is broken (mainly part in blank):

2. The headers on network tab:

3. But if we copy the image URL, and open outside (new tab, for example), it open perfectly:


Specs:
OS: macOS Mojave
Browser: Chrome Version 73.0.3683.103 (Official Build) (64-bit)
Enabled flags: Enable lazy image loading + Enable lazy frame loading

ad...@futtura.net

unread,
Apr 9, 2019, 10:39:16 AM4/9/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, ad...@futtura.net
Problem solved, was an Cloudflare issue. 

Disabled the "Polish" Cloudflare feature: 


Now the images is showing correct via lazyload.

ja...@nodecraft.com

unread,
Apr 9, 2019, 7:42:24 PM4/9/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
This may be related to the existing bug at https://bugs.chromium.org/p/chromium/issues/detail?id=950503 but we're seeing some background-images in CSS not load correctly, specifically those as specified in a `:before` pseudo element.

The 3 blank boxes at https://nodecraft.com/about should show images, and do when lazy loading is disabled.
with-lazy-loading.png
without-lazy-loading.png

robert.l...@gmail.com

unread,
Apr 11, 2019, 10:27:15 PM4/11/19
to blink-dev

EhsanK

unread,
Apr 16, 2019, 2:27:53 PM4/16/19
to blink-dev
Just a quick note that the feature policy dealing with loading attribute is 'loading-frame-default-eager' (link to PR) which is briefly explained in this document as well. 

andr...@gmail.com

unread,
Apr 17, 2019, 12:22:22 PM4/17/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
There is nothing like that in the spec currently but it's worth asking over on the issue as it may then be included.

Rick Byers

unread,
Apr 23, 2019, 5:31:38 PM4/23/19
to andr...@gmail.com, blink-dev, Ben Greenstein, rajen...@chromium.org, nanc...@chromium.org, Ojan Vafai, Addy Osmani, ekar...@chromium.org, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
It sounds to me like there are some bugs that need to be fixed before this can ship, but we don't need to block LGTMs on those as long as we agree which bugs are definitely ship-blockers.

From a blink launch perspective it looks to me like the thing we're waiting for is web-platform-tests, right? Of course if we get any suggestions in the TAG review we should respond and consider changes (before or after shipping), but we can't block shipping on waiting for feedback. It looks like a number of improvements have been made to the spec such that Maciej (WebKit) now seems supportive of the design, so that's hugely positive.

Rick


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Jake Archibald

unread,
Apr 25, 2019, 4:16:53 AM4/25/19
to blink-dev, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
I don't think we should ship until the spec PR is merged, especially as the details are still pretty hand-wavey and there are a few unaddressed issues.

const img = new Image();
img.src = url;
img.onload = () => {
  // ready!
};

Developers have relied on the above for image preloading, but the proposed spec changes means the above may never load.

const img = new Image();
img.src = url;
await img.decode();
// ready!

The above is a more modern way to achieve a similar thing. This time it includes an explicit instruction to decode the image. However, as spec'd, the above may never resolve.

We could branch behaviour on whether the image is connected to a document, but that may still break some cases:

const div = document.createElement('div');
div.style.display = 'none';
document.body.append(div);

const img = new Image();
img.src = url;
div.append(img);

img.onload = () => {
  div.style.display = 'block';
};

I don't know how popular this is in the wild.

The spec doesn't perform any queuing of the 'prefetch' for layout vs the full fetch, so it's possible for the latter to land after the former, which could have weird results.

It doesn't seem clear how these images should react to changes of src. As in, when does their layout change to match the new dimensions? Do we still do the 'prefetch' in this case?

Daniel Bratell

unread,
Apr 25, 2019, 10:54:24 AM4/25/19
to blink-dev, Jake Archibald, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
If I understood correctly, lazy-load would be opt-in normally, but maybe opt-out on some platforms/in some environments? The opt-out part does indeed seem very risky. The opt-in part less so.

/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e356d343-8d56-4b2b-a83f-045dced55598%40chromium.org.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Jake Archibald

unread,
Apr 25, 2019, 11:21:43 AM4/25/19
to Daniel Bratell, blink-dev, andr...@gmail.com, Ben Greenstein, Raj T, nanc...@chromium.org, Ojan Vafai, ad...@chromium.org, ekar...@chromium.org, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
The default is "auto", leaving the browser to choose between "lazy" or "eager" per image for whatever reason.

Dominic Farolino

unread,
Apr 29, 2019, 11:13:19 PM4/29/19
to blink-dev, bra...@opera.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
Non-owner LGTM; I'm excited about this feature, and also share Simon's (zcorpan@'s) sentiment. Please let me know if I can help move the spec along in any way.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Daniel Bratell

unread,
Apr 30, 2019, 10:02:06 AM4/30/19
to blink-dev, Dominic Farolino, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
When you and other say that you are excited about the feature, does that include the "auto" part where browsers may or may not load images? I think that is the part of the feature that is not straight forward.

Or is the excitement limited to the addition of a loading=lazy attribute on image tags?

/Daniel

brendan....@gmail.com

unread,
May 5, 2019, 6:03:09 PM5/5/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
With the "enable lazy images" flag enabled, I spotted some bugs with SVG files referenced as background images in an external CSS file.

While scrolling some of these CSS-referenced SVGs load in, which was not expected because it's unrelated to the HTML attribute.

Roughly half the SVGs never render at all, which is really unexpected and bad because they are UI icons, and the site can look broken/confusing without visual indicators.

Dr. Tassilo Keilmann

unread,
May 6, 2019, 1:59:54 AM5/6/19
to brendan....@gmail.com, blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
With the "enable lazy images" flag enabled, I spotted some bugs with SVG files referenced as background images in an external CSS file.

Background images of other types (jpeg, png ...) have this issue as well.

_____________________________________________________



    Dr. Tassilo Keilmann, CEO
    Wellness Heaven® Hotel Guide

    www.wellness-heaven.de
    keil...@wellness-heaven.de

    Klosterweg 41
    82335 Berg am Starnberger See

    fon +49 (0) 8151 99 841 77
    fax +49 (0) 89 416 166 199

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/jxiJvQc-gVg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1086cd65-675f-4b5c-af60-90f6b3e08126%40chromium.org.

Dominic Farolino

unread,
May 7, 2019, 11:07:41 PM5/7/19
to blink-dev, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
(Responding to Bratell):

The excitement is about both. I think loading=lazy is great for reasons in this thread, but I like the idea of the browser being able to lazily load by default when it sees fit. As-is, the "auto" default in it's current state may need some clearing up as Jake demonstrated, but I'm supportive of the overall motivation.

Another concern of mine is that if Chrome/others ship lazy loading below-the-fold content by default, this may greatly reduce the need for devs to explicitly write `loading=lazy`, but I realize the attribute is a good way to start with an opt-in model. I just wonder if eventually we'll end up with this "extra" attribute developers won't really be motivated to use because by omitting it entirely, they get the same effect.

Ehsan Karamad

unread,
May 8, 2019, 11:01:57 AM5/8/19
to Dominic Farolino, blink-dev, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
Another concern of mine is that if Chrome/others ship lazy loading below-the-fold content by default, this may greatly reduce the need for devs to explicitly write `loading=lazy`, but I realize the attribute is a good way to start with an opt-in model. I just wonder if eventually we'll end up with this "extra" attribute developers won't really be motivated to use because by omitting it entirely, they get the same effect.
I'd assume the behavior of auto should lean towards eager loading by default; and that is why we are also shipping policies such as loading-frame-default-eager that can be disabled using the response headers to shift the default behavior of loading (when unset or set to auto) towards almost always lazyloading. There is still the non-determinism of sorts here as well but ideally the cases where unset images and frames load eagerly is small. Technically with the policy he browser has a strong signal that it should do its best at loading lazily. To remove the uncertainty in loading behavior, the loading attribute could be used explicitly.

oj...@google.com

unread,
May 16, 2019, 3:27:14 PM5/16/19
to blink-dev, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:

1. Improved web platform tests coverage
2. Rounding out the spec concerns.

Scott, I think both of these are on your radar, but Yoav has details if they're not.

We also discussed how the auto heuristic doesn't have compat/interop concerns as it's based off a user opt-in (data saver). If we get to the point of changing the default behavior web-wide in a future iteration, we'd probably need to block on having the feature policy to have a page level opt-out in addition to the attribute level one.

marco.s...@gmail.com

unread,
May 17, 2019, 11:57:50 AM5/17/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
There is something strage.
I enabled lazyload in chrome://flags e restarted chrome. 

- Windows 7
- Chrome Versione 74.0.3729.157 (Build ufficiale) (a 64 bit)

The javascript check, suggested by Addy Osmani in his post:

if ('loading' in HTMLImageElement.prototype) {
.....
}

returns false as if Chrome is not supporting lazyload.
While using Canary 

- Window 7
- Chrome Versione 76.0.3797.0 (Build ufficiale) canary (a 64 bit)

with flags setted the test returns true.

Moreover if I use Canary with lazyload enabled using tag picture:

<picture>
<img loading="lazy" src="/img/img_tappo.png" data-src="https://wips.plug.it/cips/sport.virgilio.it/cms/2019/05/dybala_1132585.jpg?w=507&a=r" class="lazy" alt="Juventus-Atalanta, probabili formazioni" >
<noscript><img loading="lazy" src="https://wips.plug.it/cips/sport.virgilio.it/cms/2019/05/dybala_1132585.jpg?w=507&a=r" alt="Juventus-Atalanta, probabili formazioni" /></noscript>
</picture>

looking at Network panel in devtools it seems that Chrome is downlading all images of the pages and then no lazyload.
I'm using Addy Osmani's javscript (a bit changed):

<script type="text/javascript">
function _initLazySize() {
/* ---- i: LAZYSIZES CONFIG ---- */
window.lazySizesConfig = window.lazySizesConfig || {};
// use .lazy instead of .lazyload
window.lazySizesConfig.lazyClass = 'lazy';
//page is optimized for fast onload event
//lazySizesConfig.loadMode = 1;
if ('loading' in HTMLImageElement.prototype) {
      const images = document.querySelectorAll("img.lazy");
      images.forEach(img => {
          img.src = img.dataset.src;
      });
  } else {
      // Dynamically import the LazySizes library
    var se = document.createElement("script");
    se.onload=function(){lazySizes.init();};
    se.async = true;
    se.src = "/js/lazysizes.min.js";
    document.body.appendChild(se); 
}
}

if (document.readyState === "loading") {
document.addEventListener("DOMContentLoaded", _initLazySize);
} else { 
_initLazySize();
}
</script>

Dominic Farolino

unread,
May 18, 2019, 12:36:52 AM5/18/19
to blink-dev, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
I'll be working with Ben and Scott on some of the remaining specification work.


On Thursday, May 16, 2019 at 3:27:14 PM UTC-4, Ojan Vafai wrote:
API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:

1. Improved web platform tests coverage
 Last I spoke to Scott, some of the implementation was being worked on which will lead to simplifying some of the tests currently proposed at https://chromium-review.googlesource.com/c/chromium/src/+/1417117, so I suspect that will be underway soon.

2. Rounding out the spec concerns.
I think one of the remaining concerns here at least from Jake (maybe others), was what exactly what the "auto" mode means for image elements created from script (often with the intention to "preload" an image before DOM insertion). I spoke with Ben, Scott, and they made me aware that all images that are not created by the HTML Parser (i.e., by script or other means, should they exist) are never LazyLoaded unless the `loading` attribute is explicitly set to `lazy`. We can express this in the spec a couple of ways. One is making the Image() constructor automatically set an image's LazyLoad attribute to the "Eager" state. This leaves some open-endedness for images created with document.createElement('img'), but there are ways we can handle that too in spec-land.

Jake: Would that help some concerns you have with the current state of the spec?

Yoav Weiss

unread,
May 18, 2019, 3:57:15 AM5/18/19
to Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
On Sat, May 18, 2019 at 6:36 AM Dominic Farolino <domfa...@gmail.com> wrote:
I'll be working with Ben and Scott on some of the remaining specification work.

That's great to hear! Thank you!! :)
 

On Thursday, May 16, 2019 at 3:27:14 PM UTC-4, Ojan Vafai wrote:
API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:

1. Improved web platform tests coverage
 Last I spoke to Scott, some of the implementation was being worked on which will lead to simplifying some of the tests currently proposed at https://chromium-review.googlesource.com/c/chromium/src/+/1417117, so I suspect that will be underway soon.

Looking forward to it!
 

2. Rounding out the spec concerns.
I think one of the remaining concerns here at least from Jake (maybe others), was what exactly what the "auto" mode means for image elements created from script (often with the intention to "preload" an image before DOM insertion). I spoke with Ben, Scott, and they made me aware that all images that are not created by the HTML Parser (i.e., by script or other means, should they exist) are never LazyLoaded unless the `loading` attribute is explicitly set to `lazy`. We can express this in the spec a couple of ways. One is making the Image() constructor automatically set an image's LazyLoad attribute to the "Eager" state. This leaves some open-endedness for images created with document.createElement('img'), but there are ways we can handle that too in spec-land.

If we're going that route, maybe we can also be explicit about image which have onload/onerror events attached to them, and make sure they are eagerly loaded as well in auto mode?
I think that would help alleviate many of the compatibility concerns. (although the page's onload event can still rely on the image data being there in some weird ways)
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25bcef1c-09eb-4f9d-8118-898d0ea1b179%40chromium.org.

Ashley Gullen

unread,
May 18, 2019, 1:35:39 PM5/18/19
to Scott Little, blink-dev, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda
One potential compatibility issue I haven't seen raised is how the partial requests for image metadata might interact with Service Worker caching.

If a page has a lot of off-screen images with loading="lazy", it appears Chrome still issues requests to fetch the first ~2kb of data, to get the metadata so images have the right size for layout. The server responds with a 206 Partial Content accordingly. Then when the user scrolls the image in to view it does a full request and the server responds with 200 OK.

What if the page has a Service Worker with lazy-caching? For example suppose that the Service Worker will add the first response to a request to the cache, and respond cache-first in future. It would seem this will cache the first 206 Partial Content response, and then in future always serve that response from the cache, meaning the image never loads.

I haven't tested this yet, but would that be expected to happen? It's not a backwards compatibility issue since you still have to opt-in to loading="lazy", but it might be an unexpected gotcha when enabling it. It can also be worked around by making sure the Service Worker doesn't add partial responses to the cache, but this requires changing the SW.


--
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 blink-dev+...@chromium.org.

matthew...@gmail.com

unread,
May 24, 2019, 12:14:20 PM5/24/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
Enabling this in Google Flags broke some background SVGs for me. (I'm on macOS Mojave)

block.rxc...@gmail.com

unread,
May 27, 2019, 2:15:52 AM5/27/19
to blink-dev, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org
Hi

I tried Lazyloading image via Chrome 75 Canary.
I wrote about current behaviour in my blog, but it's in Japanese,
so I wanna share my feedback.


1. Range + Full request
every request for image sends Range Request and Full request.
so If all images are in above the fold, 1st range request is waste.
if image are in above the fold accidentally, its better to avoid range request.


2. Lazy for small img
range request grab first 2.0KB for image header data.
and full request come after for content.
but if image size is lower than 2.0KB (like samll icon)
second full request could reusable when its fresh.
but current implementation, seems sends full request for Above the fold small image
and reuse cache for below the fold.

same things for large image (> 2.0KB), second request
could get from offset 2.0KB and merge into single response.
using conditional GET via If-Range.
that will reduce transport size. 2.0KB is not small.


3. Above the Fold
current above the fold decision is too large/wide.
I added loading=lazy to image in my blog, 
but almost all images are loaded immediately (range + full)
even if it's not in above the fold.
so it's only increase wasted RTT.

browser has correct viewport data, so it seems better to reduce
above the fold decision like 1.5vh or so.


4. 2.0KB Request

2.0KB is not small, I wanna reduce them.
my understand is that, this range request is for retrieve `<img>` size for avoid layout junk,
so, if `<img>` has correct width/height or intrinsicsize + style
Range request could avoidable and reduces extra RTT.


5. HEAD request

in http, retrieve content meta information (which Range request does) is done via HEAD method.
so if HEAD request for image has image data, it's reasonable to send HEAD request smaller than 2.0KB range GET
but there are no backward compatibility, so it's turn to use feature policy.

how about do it like HTTP header and Head method
(image-size-info feature policy, and Image-Size header, client send HEAD for that)

```
GET /index.html HTTP/1.1
```

```
HTTP/1.1 200 OK
Feature-Policy; image-size-info; loading-image-default-lazy

<img loading=lazy src=icon.jpeg>
```

```
HEAD icon.jpeg HTTP/1.1
```

```
HTTP/1.1 200 OK
Image-Size: 200x300
```

this enables content author to opt-in lazyload only by adding header
not fixing HTML content.



thanks

Jxck


2019年4月6日土曜日 13時40分14秒 UTC+9 Scott Little:

Dominic Farolino

unread,
Jun 11, 2019, 8:31:03 PM6/11/19
to blink-dev, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com


On Saturday, May 18, 2019 at 4:57:15 PM UTC+9, Yoav Weiss wrote:


On Sat, May 18, 2019 at 6:36 AM Dominic Farolino <domfa...@gmail.com> wrote:
I'll be working with Ben and Scott on some of the remaining specification work.

That's great to hear! Thank you!! :)
 

On Thursday, May 16, 2019 at 3:27:14 PM UTC-4, Ojan Vafai wrote:
API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:

1. Improved web platform tests coverage
 Last I spoke to Scott, some of the implementation was being worked on which will lead to simplifying some of the tests currently proposed at https://chromium-review.googlesource.com/c/chromium/src/+/1417117, so I suspect that will be underway soon.

Looking forward to it!
 

2. Rounding out the spec concerns.
I think one of the remaining concerns here at least from Jake (maybe others), was what exactly what the "auto" mode means for image elements created from script (often with the intention to "preload" an image before DOM insertion). I spoke with Ben, Scott, and they made me aware that all images that are not created by the HTML Parser (i.e., by script or other means, should they exist) are never LazyLoaded unless the `loading` attribute is explicitly set to `lazy`. We can express this in the spec a couple of ways. One is making the Image() constructor automatically set an image's LazyLoad attribute to the "Eager" state. This leaves some open-endedness for images created with document.createElement('img'), but there are ways we can handle that too in spec-land.

If we're going that route, maybe we can also be explicit about image which have onload/onerror events attached to them, and make sure they are eagerly loaded as well in auto mode?
I think that would help alleviate many of the compatibility concerns. (although the page's onload event can still rely on the image data being there in some weird ways)

Hmm, could you outline the compat concerns you have in mind that this would mitigate, that would not be addressed by "ensuring images/iframes created by script are always eagerly-loaded)? I feel like if a user has added onload/onerror events to an image far below-the-fold, we'd be penalizing them by making the image non-lazy-loadable, where it may be reasonable for a developer to want onload/onerror events on images that may not load for a while, but I may be missing something?
 

Yoav Weiss

unread,
Jun 20, 2019, 3:03:06 PM6/20/19
to Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
On Wed, Jun 12, 2019 at 2:31 AM Dominic Farolino <domfa...@gmail.com> wrote:


On Saturday, May 18, 2019 at 4:57:15 PM UTC+9, Yoav Weiss wrote:


On Sat, May 18, 2019 at 6:36 AM Dominic Farolino <domfa...@gmail.com> wrote:
I'll be working with Ben and Scott on some of the remaining specification work.

That's great to hear! Thank you!! :)
 

On Thursday, May 16, 2019 at 3:27:14 PM UTC-4, Ojan Vafai wrote:
API owners discussed this today. We're close to being able to LGTM, but there seems to be a couple remaining issues:

1. Improved web platform tests coverage
 Last I spoke to Scott, some of the implementation was being worked on which will lead to simplifying some of the tests currently proposed at https://chromium-review.googlesource.com/c/chromium/src/+/1417117, so I suspect that will be underway soon.

Looking forward to it!
 

2. Rounding out the spec concerns.
I think one of the remaining concerns here at least from Jake (maybe others), was what exactly what the "auto" mode means for image elements created from script (often with the intention to "preload" an image before DOM insertion). I spoke with Ben, Scott, and they made me aware that all images that are not created by the HTML Parser (i.e., by script or other means, should they exist) are never LazyLoaded unless the `loading` attribute is explicitly set to `lazy`. We can express this in the spec a couple of ways. One is making the Image() constructor automatically set an image's LazyLoad attribute to the "Eager" state. This leaves some open-endedness for images created with document.createElement('img'), but there are ways we can handle that too in spec-land.

If we're going that route, maybe we can also be explicit about image which have onload/onerror events attached to them, and make sure they are eagerly loaded as well in auto mode?
I think that would help alleviate many of the compatibility concerns. (although the page's onload event can still rely on the image data being there in some weird ways)

Hmm, could you outline the compat concerns you have in mind that this would mitigate, that would not be addressed by "ensuring images/iframes created by script are always eagerly-loaded)? I feel like if a user has added onload/onerror events to an image far below-the-fold, we'd be penalizing them by making the image non-lazy-loadable, where it may be reasonable for a developer to want onload/onerror events on images that may not load for a while, but I may be missing something?

I suspect that at least some site may rely on their image's onload/onerror events to always fire, even if those images are static.
I don't expect a ton of sites to have those events in markup, but we could look at HA to see if that would likely have a significant impact or not.
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ab1ac2-2682-4039-9c25-16239afe8c0e%40chromium.org.

Dominic Farolino

unread,
Jul 16, 2019, 3:19:31 AM7/16/19
to blink-dev, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
Just an update for this thread. We were able to review + land the WPTs, and the spec is in near-good shape. The biggest hang-up on the spec right now is how exactly deferred iframes should be treated. The current PR defers the entirety of iframe loading until they are in the viewport etc. This means once the UA decides to load the iframe, the frame's URL is parsed relative to the most up-to-date value of the outer document's URL.

Anne, currently reviewing the PR, believes this may be problematic. He suggests that immediately when the <iframe> is parsed, the navigation steps run, relative to the outer document's base URL at that time. The navigation steps would be responsible for waiting until the viewport condition is met, to continue. This way, changes to the document's base URL before the <iframe> enters the viewport would have no effect on the <iframe>'s final URL, since it was computed eagerly. The two ways of going about this are pretty different. If there are any opinions on which may be best, I'm happy to hear them.

Yoav Weiss

unread,
Jul 16, 2019, 4:42:06 AM7/16/19
to Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
Thanks for the update!

On Tue, Jul 16, 2019 at 9:19 AM Dominic Farolino <domfa...@gmail.com> wrote:
Just an update for this thread. We were able to review + land the WPTs, and the spec is in near-good shape. The biggest hang-up on the spec right now is how exactly deferred iframes should be treated. The current PR defers the entirety of iframe loading until they are in the viewport etc. This means once the UA decides to load the iframe, the frame's URL is parsed relative to the most up-to-date value of the outer document's URL.

Anne, currently reviewing the PR, believes this may be problematic. 
He suggests that immediately when the <iframe> is parsed, the navigation steps run, relative to the outer document's base URL at that time. The navigation steps would be responsible for waiting until the viewport condition is met, to continue. This way, changes to the document's base URL before the <iframe> enters the viewport would have no effect on the <iframe>'s final URL, since it was computed eagerly. The two ways of going about this are pretty different. If there are any opinions on which may be best, I'm happy to hear them.

Seems like the concern is that decisions like the base URL may be racy in the current model, depending on *when* the user scrolled down. Is that exclusive to iframes? (e.g. seems like the base URL should also be relevant for images with relative URLs)
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05b6e854-2873-4e26-b89b-9fa167d17f3f%40chromium.org.

Dominic Farolino

unread,
Jul 16, 2019, 4:53:26 AM7/16/19
to blink-dev, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com


On Tuesday, July 16, 2019 at 5:42:06 PM UTC+9, Yoav Weiss wrote:
Thanks for the update!

On Tue, Jul 16, 2019 at 9:19 AM Dominic Farolino <domfa...@gmail.com> wrote:
Just an update for this thread. We were able to review + land the WPTs, and the spec is in near-good shape. The biggest hang-up on the spec right now is how exactly deferred iframes should be treated. The current PR defers the entirety of iframe loading until they are in the viewport etc. This means once the UA decides to load the iframe, the frame's URL is parsed relative to the most up-to-date value of the outer document's URL.

Anne, currently reviewing the PR, believes this may be problematic. 
He suggests that immediately when the <iframe> is parsed, the navigation steps run, relative to the outer document's base URL at that time. The navigation steps would be responsible for waiting until the viewport condition is met, to continue. This way, changes to the document's base URL before the <iframe> enters the viewport would have no effect on the <iframe>'s final URL, since it was computed eagerly. The two ways of going about this are pretty different. If there are any opinions on which may be best, I'm happy to hear them.

Seems like the concern is that decisions like the base URL may be racy in the current model, depending on *when* the user scrolled down. Is that exclusive to iframes? (e.g. seems like the base URL should also be relevant for images with relative URLs)

Right, I should have indicated that this is not exclusive to a) iframes, b) base URL. The same goes for images (where URL-parsing-time is particularly important for things like blob URLs), as well as attributes like `referrerPolicy`, `crossOrigin` in either element case. Basically the biggest undecided bit is "which version of all of this stuff is the source of truth?":
  1. Either the version at eventual-load-time, or...
  2. The version at parse-time, used today etc.
It looks like the best way to land the spec will be to honor (2) above. From my understanding (talking to Tarun & Raj) this may introduce complex implementation changes, so I want to be sure that this is a reasonable way forward.

It should be noted that we're still waiting for Apple's opinion on these undecided parts as well, which we have not received yet.
 

Dominic Farolino

unread,
Jul 25, 2019, 9:01:55 AM7/25/19
to blink-dev, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
Update for the API owners (and everyone):

After syncing up with Tarun, Raj, and Ben (implementers behind the feature in Chromium), it appears that the latest spec review by Anne (Mozilla) positions the spec to much more-closely align with Chrome’s implementation regarding the previous points (attribute parse-time, URL parse-time, etc). Furthermore, me and Tarun have been working with Raj to land some critical WPTs testing this behavior.

The biggest risk from here on is the fact that the spec could change in some unexpected ways after other vendors, like Apple, are able to take a closer look. Me and Yoav believe this risk is small, as the spec is not anticipated to deviate much from its current review path, which as I mentioned, matches Chrome’s behavior quite well. It is likely that any changes that would need to be made to Chrome’s implementation after the initial launch are minor, and would not break developer expectations.

Given the progress on the latest spec discussions, and the minor risk, shipping the feature seems relatively safe.

Rick Byers

unread,
Jul 25, 2019, 11:14:31 AM7/25/19
to Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, rajen...@chromium.org, nanc...@chromium.org, Ojan Vafai, Addy Osmani, ekar...@chromium.org, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
This is looking like it's about ready to ship an initial version to me. I see there's still some debate around some precise semantics / timing, and we can expect some of those details may change as part of finalizing the spec PR and tag review. But, for an opt-in feature, those all seem like changes that will be easy to make post-ship.

A few things I see that still probably block shipping:
  • Confirm all the WPTs are passing. From the WPT dashboard, it looks like the feature isn't yet enabled by --enable-experimental-web-platform-features? If so, that's a shame (great way to get additional testing and test results that are widely visible)
  • Confirm all open bugs are not ship blockers (i.e. can be safely addressed post-ship). I reviewed the ones marked Pri-1 and commented on them (it seems like maybe at least this one should) 
  • Ping the tag review indicating we now believe the design is solid and are planning on shipping an initial version (but we are, of course, still open to changes in the details).

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/54dc2866-0bf2-41a7-9eb6-0eb87b33f6fc%40chromium.org.

Ashley Gullen

unread,
Jul 25, 2019, 11:27:43 AM7/25/19
to Rick Byers, Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
Last I checked, the presence of any Service Worker disabled lazy-loading (falling back to eagerly loading everything). This seems like a pretty big limitation - for example anything that qualifies as a PWA must have a Service Worker, and therefore cannot use this feature. Is that fixed?

Dominic Farolino

unread,
Jul 26, 2019, 2:54:52 AM7/26/19
to blink-dev, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com


On Friday, July 26, 2019 at 12:14:31 AM UTC+9, Rick Byers wrote:
This is looking like it's about ready to ship an initial version to me. I see there's still some debate around some precise semantics / timing, and we can expect some of those details may change as part of finalizing the spec PR and tag review. But, for an opt-in feature, those all seem like changes that will be easy to make post-ship.

A few things I see that still probably block shipping:
  • Confirm all the WPTs are passing. From the WPT dashboard, it looks like the feature isn't yet enabled by --enable-experimental-web-platform-features? If so, that's a shame (great way to get additional testing and test results that are widely visible)
Me and Raj have confirmed that current tests are passing with Chrome's current implementation. Talking with Raj and digging around a bit myself, it seems the --enable-experimental-web-platform-features flag enables the `loading` attribute, but not the lazyloading behavior actually required for the tests for some reason, which is why the WPT dashboard looks funny. That is the behavior that will be enabled when this feature ships, so everything is OK. Raj is fixing this inconsistency now, though it will matter much less once this ships. Totally agree though, having it all controlled by the experimental flag is a great way to further-publicize test results/impl status.
  • Confirm all open bugs are not ship blockers (i.e. can be safely addressed post-ship). I reviewed the ones marked Pri-1 and commented on them (it seems like maybe at least this one should)
Thanks for checking them out. It looks like the only P1 left is https://crbug.com/984983, for tracking remaining WPTs. These WPTs are being added in https://crrev.com/c/1719445, which I've just reviewed. I suspect it will land soon. Our impl is not perfect regarding those tests, and fixing that is tracked by a P2 issue that we'll take care of after initial shipment. 
  • Ping the tag review indicating we now believe the design is solid and are planning on shipping an initial version (but we are, of course, still open to changes in the details).
Done.

Rick Byers

unread,
Jul 26, 2019, 12:47:43 PM7/26/19
to Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, rajen...@chromium.org, nanc...@chromium.org, Ojan Vafai, Addy Osmani, ekar...@chromium.org, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
Thanks.

LGTM1 to ship once the remaining WPTs land.

Obviously there's still likely to be some tweaks to the precise semantics and spec text, but the API shape is very simple and seems likely to be stable now. Being an opt-in feature, I feel confident that we will not have problems continuing to improve the precise semantics and spec text post-ship. But if any potentially high-risk breaking change is taken to the design before the feature hits stable, then we should reconsider.

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6cc89816-a791-4e66-b0c1-de788082ec93%40chromium.org.

Yoav Weiss

unread,
Jul 26, 2019, 2:12:20 PM7/26/19
to Rick Byers, Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
LGTM2 under similar conditions.
Since this is also controlled by a server-side flag, please make sure that the tests pass on the version this is intended to ship in before shipping.

I'm super excited to see this feature ship, as this is something developers have been asking for since ~forever.
Thanks to the team for pushing through the process and huge thanks to Dominic for stepping up to bring the PR to a stable state and shepherd the WPTs!! 



smaug

unread,
Jul 26, 2019, 2:29:15 PM7/26/19
to Rick Byers, Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, rajen...@chromium.org, nanc...@chromium.org, Ojan Vafai, Addy Osmani, ekar...@chromium.org, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
On 7/26/19 7:47 PM, Rick Byers wrote:
> Thanks.
>
> LGTM1 to ship once the remaining WPTs land.
>
> Obviously there's still likely to be some tweaks to the precise semantics and spec text, but the API shape is very simple and seems likely to be
> stable now. Being an opt-in feature,

It is not an opt-in feature, at least not per the latest PR.
So shipping the feature is rather risky. It could let browsers to handle page loads in various different ways, depending on the heuristics they want
to do with 'auto': "Indicates a preference for the user agent to determine the fetching strategy (the default)."


-Olli


I feel confident that we will not have problems continuing to improve the precise semantics and spec text
> post-ship. But if any potentially high-risk breaking change is taken to the design before the feature hits stable, then we should reconsider.
>
> Rick
>
> On Thu, Jul 25, 2019 at 11:54 PM Dominic Farolino <domfa...@gmail.com <mailto:domfa...@gmail.com>> wrote:
>
>
>
> On Friday, July 26, 2019 at 12:14:31 AM UTC+9, Rick Byers wrote:
>
> This is looking like it's about ready to ship an initial version to me. I see there's still some debate around some precise semantics /
> timing, and we can expect some of those details may change as part of finalizing the spec PR and tag review. But, for an opt-in feature, those
> all seem like changes that will be easy to make post-ship.
>
> A few things I see that still probably block shipping:
>
> * Confirm all the WPTs are passing. From the WPT dashboard <https://wpt.fyi/results/loading/lazyload?label=master&label=experimental>, it
> looks like the feature isn't yet enabled by --enable-experimental-web-platform-features? If so, that's a shame (great way to get
> additional testing and test results that are widely visible)
>
> Me and Raj have confirmed that current tests are passing with Chrome's current implementation. Talking with Raj and digging around a bit myself,
> it seems the --enable-experimental-web-platform-features flag enables the `loading` attribute, but not the lazyloading behavior actually required
> for the tests for some reason, which is why the WPT dashboard looks funny. That is the behavior that will be enabled when this feature ships, so
> everything is OK. Raj is fixing this inconsistency now, though it will matter much less once this ships. Totally agree though, having it all
> controlled by the experimental flag is a great way to further-publicize test results/impl status.
>
> * Confirm all open bugs <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ELoader%3ELazyLoad&can=2> are not ship
> blockers (i.e. can be safely addressed post-ship). I reviewed the ones marked Pri-1 and commented on them (it seems like maybe at least
> this one <https://bugs.chromium.org/p/chromium/issues/detail?id=973124> should)
>
> Thanks for checking them out. It looks like the only P1 left is https://crbug.com/984983, for tracking remaining WPTs. These WPTs are being added
> in https://crrev.com/c/1719445, which I've just reviewed. I suspect it will land soon. Our impl is not perfect regarding those tests, and fixing
> that is tracked by a P2 issue that we'll take care of after initial shipment.
>
> * Ping the tag review
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F361&sa=D&sntz=1&usg=AFQjCNGwijEfiUfuhKnPrGMIwy4jnbcgfg> indicating
> we now believe the design is solid and are planning on shipping an initial version (but we are, of course, still open to changes in the
> details).
>
> Done.
>
>
> On Thu, Jul 25, 2019 at 6:02 AM Dominic Farolino <domfa...@gmail.com> wrote:
>
> *Update for the API owners* (and everyone):
>
> After syncing up with Tarun, Raj, and Ben (implementers behind the feature in Chromium), it appears that the latest spec review by Anne
> (Mozilla) positions the spec to much more-closely align with Chrome’s implementation regarding the previous points (attribute parse-time,
> URL parse-time, etc). Furthermore, me and Tarun have been working with Raj to land some critical WPTs testing this behavior.
>
> The biggest risk from here on is the fact that the spec could change in some unexpected ways after other vendors, like Apple, are able to
> take a closer look. Me and Yoav believe this risk is small, as the spec is not anticipated to deviate much from its current review path,
> which as I mentioned, matches Chrome’s behavior quite well. It is likely that any changes that would need to be made to Chrome’s
> implementation after the initial launch are minor, and would not break developer expectations.
>
> Given the progress on the latest spec discussions, and the minor risk, shipping the feature seems relatively safe.
>
> On Tuesday, July 16, 2019 at 5:53:26 PM UTC+9, Dominic Farolino wrote:
>
>
>
> On Tuesday, July 16, 2019 at 5:42:06 PM UTC+9, Yoav Weiss wrote:
>
> Thanks for the update!
>
> On Tue, Jul 16, 2019 at 9:19 AM Dominic Farolino <domfa...@gmail.com> wrote:
>
> Just an update for this thread. We were able to review + land the WPTs, and the spec is in near-good shape. The biggest
> hang-up on the spec right now is how exactly deferred iframes should be treated. The current PR defers the entirety of iframe
> loading until they are in the viewport etc. This means once the UA decides to load the iframe, the frame's URL is parsed
> relative to the most up-to-date value of the outer document's URL.
>
> Anne, currently reviewing the PR, believes this may be problematic.
>
> He suggests that immediately when the <iframe> is parsed, the navigation steps run, relative to the outer document's base URL
> /at that time/. The navigation steps would be responsible for waiting until the viewport condition is met, to continue. This
> way, changes to the document's base URL before the <iframe> enters the viewport would have no effect on the <iframe>'s final
> URL, since it was computed eagerly. The two ways of going about this are pretty different. If there are any opinions on which
> may be best, I'm happy to hear them.
>
>
> Seems like the concern is that decisions like the base URL may be racy in the current model, depending on *when* the user scrolled
> down. Is that exclusive to iframes? (e.g. seems like the base URL should also be relevant for images with relative URLs)
>
>
> Right, I should have indicated that this is not exclusive to a) iframes, b) base URL. The same goes for images (where URL-parsing-time
> is particularly important for things like blob URLs), as well as attributes like `referrerPolicy`, `crossOrigin` in either element
> case. Basically the biggest undecided bit is "which version of all of this stuff is the source of truth?":
>
> 1. Either the version at eventual-load-time, or...
> 2. The version at parse-time, used today etc.
> I'd assume the behavior of /auto/ should lean towards eager loading by default; and that is why we are
> also shipping policies such as /loading-frame-default-eager/ that can be disabled using the response
> headers to shift the default behavior of loading (when unset or set to auto) towards almost always
> lazyloading. There is still the /non-determinism/ of sorts here as well but ideally the cases where
> unset images and frames load eagerly is small. Technically with the policy he browser has a strong
> signal that it should do its best at loading lazily. To remove the uncertainty in loading behavior,
> the loading attribute could be used explicitly.
>
> *From: *Dominic Farolino <domfa...@gmail.com>
> *Date: *Tue, May 7, 2019 at 11:07 PM
> *To: *blink-dev
> *Cc: * <domfa...@gmail.com>, <andr...@gmail.com>, <be...@chromium.org>, <rajen...@chromium.org>,
> spec <https://github.com/whatwg/html/pull/3752> such that Maciej (WebKit)
> now seems supportive of the design, so that's hugely positive.
>
> Rick
>
>
> On Wed, Apr 17, 2019 at 12:22 PM <andr...@gmail.com> wrote:
>
> There is nothing like that in the spec currently but it's worth asking
> over on the issue as it may then be included.
>
> https://github.com/whatwg/html/pull/3752
>
> On Monday, 8 April 2019 18:36:41 UTC+1, heckt...@gmail.com wrote:
>
> Is there any way to tell an image to load with low priority?
> (similar to lazysizes lazy preload)
>
> example: https://realtruck.com/ - The menu images under the
> Category Menu.
>
> We don't want them eager, but we wouldn't want them 'lazy' per say
> either since our goal is to never have a user see an image loading.
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12fa06d1-9e20-4e3f-9be9-3b4d9971bda0%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12fa06d1-9e20-4e3f-9be9-3b4d9971bda0%40chromium.org?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 blin...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e356d343-8d56-4b2b-a83f-045dced55598%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e356d343-8d56-4b2b-a83f-045dced55598%40chromium.org?utm_medium=email&utm_source=footer>.
>
>
>
>
> --
> /* Opera Software, Linköping, Sweden: CET (UTC+1) */
>
>
>
>
> --
> /* Opera Software, Linköping, Sweden: CET (UTC+1) */
>
> --
> 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 blin...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25bcef1c-09eb-4f9d-8118-898d0ea1b179%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25bcef1c-09eb-4f9d-8118-898d0ea1b179%40chromium.org?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 blin...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ab1ac2-2682-4039-9c25-16239afe8c0e%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3ab1ac2-2682-4039-9c25-16239afe8c0e%40chromium.org?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 blin...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05b6e854-2873-4e26-b89b-9fa167d17f3f%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05b6e854-2873-4e26-b89b-9fa167d17f3f%40chromium.org?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 blin...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/54dc2866-0bf2-41a7-9eb6-0eb87b33f6fc%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/54dc2866-0bf2-41a7-9eb6-0eb87b33f6fc%40chromium.org?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 blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6cc89816-a791-4e66-b0c1-de788082ec93%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6cc89816-a791-4e66-b0c1-de788082ec93%40chromium.org?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 blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9p93W-p_YiQJZF_4w7jV7uRcp2L_ZBNB4LtMWbBvGgRA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9p93W-p_YiQJZF_4w7jV7uRcp2L_ZBNB4LtMWbBvGgRA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

Yoav Weiss

unread,
Jul 26, 2019, 3:13:51 PM7/26/19
to smaug, Rick Byers, Dominic Farolino, blink-dev, andr...@gmail.com, Ben Greenstein, Raj T, Nancy Gao, Ojan Vafai, Addy Osmani, Ehsan Karamad, Kenji Baheux, Kinuko Yasuda, heckt...@gmail.com
On Fri, Jul 26, 2019 at 2:29 PM smaug <sm...@welho.com> wrote:
On 7/26/19 7:47 PM, Rick Byers wrote:
> Thanks.
>
> LGTM1 to ship once the remaining WPTs land.
>
> Obviously there's still likely to be some tweaks to the precise semantics and spec text, but the API shape is very simple and seems likely to be
> stable now. Being an opt-in feature,

It is not an opt-in feature, at least not per the latest PR.
So shipping the feature is rather risky. It could let browsers to handle page loads in various different ways, depending on the heuristics they want
to do with 'auto': "Indicates a preference for the user agent to determine the fetching strategy (the default)."


-Olli


AFAIU the current implementation does not change the default behavior in the "auto" case. The only case where behavior will change is when developers will explicitly add a "loading=lazy" attribute to their markup.
I agree that the spec language currently permits e.g. a browser to avoid loading images by default outside of the initial viewport. That is indeed riskier, and were we considering shipping that, it would indeed require more data regarding the potential compat impact.

brendan....@gmail.com

unread,
Jul 26, 2019, 5:26:49 PM7/26/19
to blink-dev, sm...@welho.com, rby...@chromium.org, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
The bug with CSS-defined background images is still present, and for me that should be a blocker.

If I enable the feature in Chrome flags, and visit a page the uses <img loading="lazy"> somewhere — that causes the browser to never load some images defined via CSS. This is important because those icons may be necessary to understand the UI.

You can test on this URL:

Problem areas (screenshots attached):
  • Missing search button icon
  • Missing prev/next buttons for the "trending" carousel
When I tested this feature a few months ago it caused several but not all of the social icons to load/not (which are below the fold). I'm not sure how the browser decides this now, because some of these icons failing to load are not below the fold on load.

Regardless, the feature does not request those images (when defined via CSS) as the browser scrolls them into view, so that is a blocking bug to me. We'll definitely get complaints that sites are not working.

Thanks,
Brendan
Screen Shot 2019-07-26 at 2.24.25 PM.png

Yoav Weiss

unread,
Jul 26, 2019, 5:47:34 PM7/26/19
to brendan....@gmail.com, blink-dev, smaug, rby...@chromium.org, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
That indeed sounds like a blocking issue. Have you filed an issue at crbug.com?

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fafc269d-cb20-436a-9523-0afc3542cf50%40chromium.org.

Raj T

unread,
Jul 26, 2019, 5:57:02 PM7/26/19
to blink-dev, brendan....@gmail.com, sm...@welho.com, rby...@chromium.org, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
Hi Brendan,

We fixed this related issue in M76.
I don't see the issue (visiting the URL you gave) with M76 beta (with Lazyload enabled in chrome://flags).
Could you double check too.

Thanks
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

brendan....@gmail.com

unread,
Jul 26, 2019, 6:35:55 PM7/26/19
to blink-dev, brendan....@gmail.com, sm...@welho.com, rby...@chromium.org, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
@ Yoav — I didn't file a new bug because the same context was reported: https://bugs.chromium.org/p/chromium/issues/detail?id=950503

Can't find my original comments now, but I added notes on my case here or there previously.

@ Raj — Just checked in Canary 77 (with Enabled and Enabled when safe in Chrome Flags) and all CSS background images are retrieved on load.

Note: I couldn't get any lazy loading to occur on scroll (everything loaded on load), but maybe my whole page is under the threshold for that to occur now.

But considering the bug was merged, I trust it's all good now. Seems to be, thanks!

Raj T

unread,
Jul 26, 2019, 9:14:56 PM7/26/19
to blink-dev, brendan....@gmail.com, sm...@welho.com, rby...@chromium.org, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
Thanks Brendan for double checking.

Alex Russell

unread,
Aug 1, 2019, 3:12:13 PM8/1/19
to blink-dev, brendan....@gmail.com, sm...@welho.com, rby...@chromium.org, domfa...@gmail.com, andr...@gmail.com, be...@chromium.org, rajen...@chromium.org, nanc...@chromium.org, oj...@chromium.org, ad...@chromium.org, ekar...@chromium.org, kenji...@chromium.org, kin...@chromium.org, heckt...@gmail.com
With the clarification in today's OWNERS meeting that we only intend to ship the opt-in variant with this intent, LGTM3.
Reply all
Reply to author
Forward
0 new messages