Support <img loading="lazy"> lazy-loading
Categories
(Core :: DOM: Core & HTML, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox75 | --- | fixed |
People
(Reporter: jmcbray, Assigned: hiro)
References
(Depends on 2 open bugs, Blocks 3 open bugs)
Details
(Keywords: dev-doc-complete, Whiteboard: [webcompat][layout:backlog:2020q1], [wptsync upstream])
Attachments
(9 files)
Bug 1542784 - Annotate bug number for tests affected by an open issue [1] for lazy-loading. r?emilio
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
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.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Bug report for the old "lazyload" attribute: https://bugzilla.mozilla.org/show_bug.cgi?id=947427
Comment 2•6 years ago
|
||
There isn't yet a reasonable spec for lazyload, but it does feel like a good addition to the web platform.
Updated•6 years ago
|
Comment 3•6 years ago
|
||
WHATWG Pull Request for "loading" attribute: https://github.com/whatwg/html/pull/3752
Updated•6 years ago
|
Comment 4•6 years ago
|
||
Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.
Comment 5•6 years ago
|
||
See bug 1547409. Migrating whiteboard priority tags to program flags.
Updated•6 years ago
|
Comment 6•6 years ago
|
||
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•5 years ago
|
||
Not working: https://mathiasbynens.be/demo/img-loading-lazy
Comment 8•5 years ago
|
||
(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•5 years ago
•
|
||
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 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•5 years ago
|
||
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•5 years ago
|
||
This shouldn't be in "HTML: Parser" at all. A tiny fraction of the relevant work will happen there...
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 14•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 15•5 years ago
|
||
Assignee | ||
Comment 16•5 years ago
|
||
Depends on D61433
Assignee | ||
Comment 17•5 years ago
|
||
Depends on D61434
Assignee | ||
Comment 18•5 years ago
|
||
So that it can accept a callback function implemented in C++ for lazy-loading.
Depends on D61435
Assignee | ||
Comment 19•5 years ago
|
||
Depends on D61436
Assignee | ||
Comment 20•5 years ago
|
||
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;
- 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;
- 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
Assignee | ||
Comment 21•5 years ago
|
||
There are two variation of the tests.
- The image element gets visible by scrolling the iframe's scrollport.
- The image element gets visible by scrolling the parent scroll container of the iframe
Depends on D61438
Assignee | ||
Comment 22•5 years ago
|
||
Depends on D61439
Assignee | ||
Comment 23•5 years ago
|
||
Depends on D61440
Updated•5 years ago
|
Updated•5 years ago
|
Comment 24•5 years ago
|
||
Comment 27•5 years ago
|
||
bugherder |
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
(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•5 years ago
|
||
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•5 years ago
|
||
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.
Assignee | ||
Comment 32•5 years ago
|
||
(In reply to michael from comment #31)
When JavaScript is disabled (either by disabling it from the DevTools settings or by setting
javascript.enabled
tofalse
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•5 years ago
|
||
(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?
Assignee | ||
Comment 34•5 years ago
|
||
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•5 years ago
•
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
(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•4 years ago
|
||
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•3 years ago
|
||
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•3 years ago
|
||
It is expected that cached images don't lazy load, see bug 1709577. It's per spec too.
Comment 44•3 years ago
|
||
Ctrl+F5 would be more effective than that to ensure the image lazy loads, and if that doesn't work we should fix it.
Description
•