User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Chrome is adding support for lazy loading images and iframes, as specified here: https://github.com/scott-little/lazyload/.

Actual results:

Firefox does not support this syntax, and I could not find an existing bug requesting it.

Expected results:

Firefox should also implement this. Currently, lazy-loading images not only requires using JavaScript, it also requires writing your HTML in such a way that your images will not be loaded at all with JavaScript disabled. Putting image lazy-loading in the browser's handling of the <img> tag makes it possible to provide this in a more robust way, lower down the web stack - you can confidently use the <img loading="lazy"> syntax and know that the fallback to eager loading will work in all browsers.

There isn't yet a reasonable spec for lazyload, but it does feel like a good addition to the web platform.

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

See bug 1547409. Migrating whiteboard priority tags to program flags.

Starting with Chrome 76, you'll be able to use the new loading attribute to lazy-load resources without the need to write custom lazy-loading code or use a separate JavaScript library. — https://web.dev/native-lazy-loading

(In reply to Wellington Torrejais da Silva from lazy-loading" target="_blank">comment #7)

Not working: https://mathiasbynens.be/demo/img-loading-lazy

It's not working, because this feature isn't implemented yet. It's not even standardized yet. See the issue Joshua linked to. But I'm guess once the discussion there has settled and the feature is in the specification, Mozilla will prioritize this.

Sebastian

If the spec for this is well thought-through, complete and has gone through the proper process.... then we should do this ASAP. It gives Authors simple tools for greatly improving the performance of their sites, and will result in Firefox being faster.

I'm also getting many, many requests for this feature — and questions about when we are shipping it. Authors are eager for it.

(In reply to Jen Simmons [:jensimmons] from lazy-loading" target="_blank">comment #9)

If the spec for this is well thought-through, complete and has gone through the proper process....

I haven't reviewed this on that level.

then we should do this ASAP. It gives Authors simple tools for greatly improving the performance of their sites, and will result in Firefox being faster.

I'm also getting many, many requests for this feature — and questions about when we are shipping it. Authors are eager for it.

So for the HTML: Parser component, this request is just turning off prefetching for <img> if there's an attribute loading whose value is lazy, right? Or is there more for the HTML parser to do? (And then the rest of the feature goes under Layout.)

FWIW, the HTML PR isn't in a good shape (yet) and I'm also not sure there's adequate test coverage. See https://github.com/mozilla/standards-positions/issues/151 for Mozilla's overall position.

This shouldn't be in "HTML: Parser" at all. A tiny fraction of the relevant work will happen there...

So that it can accept a callback function implemented in C++ for lazy-loading.

Depends on D61435

Note that there are 3 web platform tests which still fail with this
implementation.

/loading/lazyload/original-base-url-applied-tentative.html
/loading/lazyload/original-crossorigin-applied-tentative.sub.html
/loading/lazyload/original-referrer-policy-applied-tentative.sub.html

These tests are supposed to expect that changing base url doesn't affect
lazy-load images once after its target url was resolved. That's true as per the
spec.

As per "updating-the-image-data" [1] in the spec, the step for resolving URL is
done in the step 11;

1. Parse selected source, relative to the element's node document, and let
   urlString be the resulting URL string. If that is not successful,

Then in the step 22;

1. If the will lazy load image steps given the img return true, then run
   these steps:

So after the step 11, the resolved URL will never be changed even if it's for
lazy-load images. Wheares our current image load implementation is not
compliant with this spec. Once after we implement spec compliant in bug
1076583, these tests should pass as it is.

Depends on D61437

There are two variation of the tests.

1. The image element gets visible by scrolling the iframe's scrollport.
2. The image element gets visible by scrolling the parent scroll container of the iframe

Depends on D61438

When JavaScript is disabled (either by disabling it from the DevTools settings or by setting javascript.enabled to false in about:config), lazy-loading does not work, and all the images of the page are immediately loaded.

Is this behaviour intended? I didn’t find anything related to this scenario in the WHATWG spec.

As an author, I’ve been surprised by this. Seeing no relationship between the unavailability of JavaScript and the loading of HTML images by the browser, I would expect loading="lazy" to be honoured regardless of the ability to run JavaScript in the page, so that users could still benefit from the performance improvements coming from the attribute.

(In reply to michael from lazy-loading" target="_blank">comment #31)

When JavaScript is disabled (either by disabling it from the DevTools settings or by setting javascript.enabled to false in about:config), lazy-loading does not work, and all the images of the page are immediately loaded.

Is this behaviour intended? I didn’t find anything related to this scenario in the WHATWG spec.

Yes, that's intentional. https://whatpr.org/html/3752/images.html#updating-the-image-data

(In reply to Hiroyuki Ikezoe (:hiro) from lazy-loading" target="_blank">comment #32)

Yes, that's intentional. https://whatpr.org/html/3752/images.html#updating-the-image-data

Oh, so this is an anti-tracking measure. This makes sense. Thank you!

Do you think this reliance on JavaScript availability is worth being mentioned in the docs on MDN?

Indeed, it would be nice to have a note about the script case in the doc. :sheppy, would you mind adding a note there?

I have added the note. Thank you for providing that info!

Personally, while it makes sense to disable it to prevent tracking, I think this feature deserved a separate option to control it and not be bound to whether scripting is enabled, but that's an issue for the specification. For what it's worth, I've created one at https://github.com/whatwg/html/issues/5495 asking about that.

Sebastian

When reloading a page while the scroll position is already below an image with loading="lazy", the image is not loaded in FF 83.0.

To reproduce:

• Visit a page with an <img loading="lazy"> image
• Scroll down so that the image is not in the viewport
• Reload (F5)
• Scroll up to the image

=> the image is not loaded

I need to correct myself.
It seems to affect only <picture><img loading="lazy"></picture> since this example works fine: https://lazy-loading.firebaseapp.com/lazy_loading_native.html

<picture>
  <source media="(min-width: 40em)" srcset="big.jpg 1x, big-hd.jpg 2x">
  <source srcset="small.jpg 1x, small-hd.jpg 2x">
  <img src="fallback.jpg" loading="lazy">
</picture>

When reloading a page while the scroll position is already below an image with loading="lazy", the image is not loaded

Why would you expect and image that is outside the viewport of the first render, be it below or above?

It seems to affect only <picture><img loading="lazy"></picture> since this example works fine: https://lazy-loading.firebaseapp.com/lazy_loading_native.html

If I scroll to the bottom, reload and very quickly scroll up, I can see the pictures loading lazily, I guess it is just much faster then on the first load as some might be cached!? A hard refresh, which clears the images from the cache also resets my scroll position.

(In reply to Albert Scheiner [:alberts] from lazy-loading" target="_blank">comment #38)

Why would you expect and image that is outside the viewport of the first render, be it below or above?

It is outside (above) the viewport when loading the page, but then scrolling to show the image does trigger loading it.

If I scroll to the bottom, reload and very quickly scroll up, I can see the pictures loading lazily, I guess it is just much faster then on the first load as some might be cached!? A hard refresh, which clears the images from the cache also resets my scroll position.

This is an example where it is working as intended for me. It just uses <img loading="lazy">. Even using the dev tools (-> network) to disable the cache yields correct results for me.

On a test page with <picture><img loading="lazy"></picture> it is not working in the mentioned condition.

Here is an example in the wild where it is not working for even with enabled cache: https://www.schempp-hirth.com/en/sailplanes.

Please file a new bug about that, feel free to CC me on it. But that page is a bit weird because it requires you to open stuff using JS, so when you refresh the page contents are not the same.