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

[Scott Little]

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

• A thread on WICG about lazy loading images

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]

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]

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]

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

• A thread on WICG about lazy loading images

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBp5rV_uNeekijVoSezJXc5nf4RKTmHk4ZMe6tvosy9amtQQQ%40mail.gmail.com.

[smaug]

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>

>
>
> 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

> <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>.

> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACBp5rV_uNeekijVoSezJXc5nf4RKTmHk4ZMe6tvosy9amtQQQ%40mail.gmail.com

> <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]

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.

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.

[zco...@gmail.com]

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.

https://github.com/whatwg/html/pull/3752#issuecomment-480782281

cheers,

[in...@wellness-heaven.de]

Interesting feature.

However, there seems to be an issue with loading of background images via css url().

Example: https://take.ms/lCF7C

https://www.wellness-heaven.de/wellnesshotel/schloss-elmau/testbericht-wellness/

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]

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.

Example: https://take.ms/fUtNJ

https://www.wellness-heaven.de/wellnesshotel/schwarz/

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]

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.

Example: https://take.ms/fUtNJ

https://www.wellness-heaven.de/wellnesshotel/schwarz/

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

Thanks, I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=950503 to fix it.

 

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]

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]

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]

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):

https://www.dropbox.com/s/eihuj8hhud9udgt/Screenshot%202019-04-08%2014.26.46.png?dl=0

2. The headers on network tab:

https://www.dropbox.com/s/zspv3dn8oloj8mc/Screenshot%202019-04-08%2014.28.34.png?dl=0

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

https://www.dropbox.com/s/9boo6vpmudty3v1/Screenshot%202019-04-08%2014.29.02.png?dl=0

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]

Problem solved, was an Cloudflare issue. 

Disabled the "Polish" Cloudflare feature: 

https://www.dropbox.com/s/zattsx9nat2u0qp/Screenshot%202019-04-08%2014.44.49.png?dl=0

Now the images is showing correct via lazyload.

[ja...@nodecraft.com]

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.

[robert.l...@gmail.com]

Feature-Policy can govern lazyload: https://github.com/w3c/webappsec-feature-policy/issues/193

[EhsanK]

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]

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

[Rick Byers]

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.

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.

[Jake Archibald]

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]

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]

The default is "auto", leaving the browser to choose between "lazy" or "eager" per image for whatever reason.

[Dominic Farolino]

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.

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.