1542784 - (lazyload) Support <img loading="lazy"> lazy-loading

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, enhancement)

Description

[jmcbray]

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.

Comment 1

[Steffen Weber]

Bug report for the old "lazyload" attribute: https://bugzilla.mozilla.org/show_bug.cgi?id=947427

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 3

[Joshua Lindquist]

WHATWG Pull Request for "loading" attribute: https://github.com/whatwg/html/pull/3752

Comment 4

[Firefox Bug Husbandry Bot]

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

Comment 5

[Firefox Bug Husbandry Bot]

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

Comment 6

[Karl Dubost💡 :karlcow]

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

Comment 7

[Wellington Torrejais da Silva]

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

Comment 8

[Sebastian Zartner [:sebo]]

(In reply to Wellington Torrejais da Silva from 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

Comment 9

[Jen Simmons [:jensimmons]]

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.

Comment 10

[Henri Sivonen (:hsivonen)]

(In reply to Jen Simmons [:jensimmons] from 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.)

Comment 11

[Anne (:annevk)]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[fatih.hayrioglu]

https://davidwalsh.name/loading-lazy

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Annotate bug number for tests affected by an open issue [1] for lazy-loading. r?emilio

[1] https://github.com/whatwg/html/issues/5236

Comment 16

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Add loading attribute to the HTML parser. r?hsivonen

Depends on D61433

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Stop speculative image load for lazy load images. r?hsivonen

Depends on D61434

Comment 18

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Make DOMIntersectionObserver::mCallback Variant. r?emilio!,bzbarsky!

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

Depends on D61435

Comment 19

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Use nsIRequest::LOAD_BACKGROUND for lazy-load image elements. r?hsivonen

Depends on D61436

Comment 20

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Implement lazy loading for images. r?emilio!,hsivonen!

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;

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

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

Comment 21

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Add tests for lazy-load images in cross origin iframes. r?emilio

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

Comment 22

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Add a wpt to make sure loading="lazy" is not honored in script disable iframe. r?emilio

Depends on D61439

Comment 23

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1542784 - Add a wpt when the deferred image element moves into script disabled document. r?emilio

Depends on D61440

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7c714a35e683
Annotate bug number for tests affected by an open issue [1] for lazy-loading. r=emilio
https://hg.mozilla.org/integration/autoland/rev/c6419c6e50be
Add loading attribute to the HTML parser. r=hsivonen
https://hg.mozilla.org/integration/autoland/rev/7def7a454580
Stop speculative image load for lazy load images. r=hsivonen
https://hg.mozilla.org/integration/autoland/rev/03c1c36d300c
Make DOMIntersectionObserver::mCallback Variant. r=emilio,bzbarsky
https://hg.mozilla.org/integration/autoland/rev/63cb9dca2a0d
Use nsIRequest::LOAD_BACKGROUND for lazy-load image elements. r=hsivonen
https://hg.mozilla.org/integration/autoland/rev/e27886fc6a2a
Implement lazy loading for images. r=emilio,hsivonen
https://hg.mozilla.org/integration/autoland/rev/738e2a3729cf
Add tests for lazy-load images in cross origin iframes. r=emilio
https://hg.mozilla.org/integration/autoland/rev/aaf6810da7b9
Add a wpt to make sure loading="lazy" is not honored in script disable iframe. r=emilio
https://hg.mozilla.org/integration/autoland/rev/f2f84d35d5cc
Add a wpt when the deferred image element moves into script disabled document. r=emilio

Comment 25

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/21768 for changes under testing/web-platform/tests

Comment 26

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.

Comment 27

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/7c714a35e683
https://hg.mozilla.org/mozilla-central/rev/c6419c6e50be
https://hg.mozilla.org/mozilla-central/rev/7def7a454580
https://hg.mozilla.org/mozilla-central/rev/03c1c36d300c
https://hg.mozilla.org/mozilla-central/rev/63cb9dca2a0d
https://hg.mozilla.org/mozilla-central/rev/e27886fc6a2a
https://hg.mozilla.org/mozilla-central/rev/738e2a3729cf
https://hg.mozilla.org/mozilla-central/rev/aaf6810da7b9
https://hg.mozilla.org/mozilla-central/rev/f2f84d35d5cc

Comment 28

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 29

[Henri Sivonen (:hsivonen)]

(In reply to Pulsebot from comment #24)

https://hg.mozilla.org/integration/autoland/rev/c6419c6e50be
Add loading attribute to the HTML parser. r=hsivonen

Landed in the htmlparser repo:
https://github.com/validator/htmlparser/commit/0ee4b8afe8c4866c32597d847838e20e87075ddb

Comment 30

[Eric Shepherd [:sheppy]]

Documentation updates:

• Added the loading attribute to the HTMLImageElement page
• Mention loading on Web performance resources
• Add info to Lazy loading
• Add Use lazy loading for images to "Tips for authoring fast-loading HTML pages]
• Updated Firefox 75 for developers
• Submitted BCD PR 5862

Comment 31

[michael]

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.

Comment 32

[Hiroyuki Ikezoe (:hiro)]

(In reply to michael from 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

Comment 33

[michael]

(In reply to Hiroyuki Ikezoe (:hiro) from 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?

Comment 34

[Hiroyuki Ikezoe (:hiro)]

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

Comment 35

[Sebastian Zartner [:sebo]]

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

Comment 36

[flightvision]

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

Comment 37

[flightvision]

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>

Comment 38

[Albert Scheiner [:alberts]]

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.

Comment 39

[flightvision]

(In reply to Albert Scheiner [:alberts] from 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.

Comment 40

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 42

[arthur]

While debugging I thought Lazy-loading was not working in Firefox.

It turns out that if you go to inspect element, in the network tab, scroll down to load all the page, scroll back up, keep the Disable Cache toggled on, and then refresh. All images will be requested eagerly. (at least all that were previously fetched)

If we keep working on the same page for hours and just refreshing to do tests, we might think it's not working.

To really be able to test if lazy loading is working and be able to evaluate our website performance, we have open a new tab, inspect element, network tab, and then navigate to the test page.

I'm not sure if this behavior was intended or not, but it seems like a bug.

A page were this can be tested: https://mathiasbynens.be/demo/img-loading-lazy

Comment 43

[Emilio Cobos Álvarez (:emilio)]

It is expected that cached images don't lazy load, see bug 1709577. It's per spec too.

Comment 44

[Emilio Cobos Álvarez (:emilio)]

Ctrl+F5 would be more effective than that to ensure the image lazy loads, and if that doesn't work we should fix it.