@Jdlrobson Can you flesh out the description with some of the technical implementation details? It's on @ovasileva's radar for the product side.

If you are on a slow connection, this is absolutely horrible UX, especially on desktop.

On mobile it makes sense:

• Mobile connections are often relatively fast, so there's less overall visible latency associated with each request
• Data caps are quite common for mobile connections, so you want to try to avoid downloading extra stuff to avoid using up people's data
• Screen size is small and people also tend to go to more things more quickly without necessarily scrolling down, so there's less point downloading everything anyway

For mobile, the data caps alone would be reason enough, but that just doesn't apply to most desktop use, nor are the usage patterns the same, either.

It's basically a trade-off in terms of experience: do you want to sit through a somewhat longer download process at the start, but then have everything right there, or do you want to have to wait constantly every time you scroll down? Given that the latter actually adds more overhead due to multiple individual requests, and also more opportunities for an individual request to fail (something that is particularly common on bad connections), and generally no way to re-try the failed request short of reloading the page, which then requires all the other requests to go again.

From a UX standpoint, I would strongly recommend against this.

In T148047#2732737, @Isarra wrote:

It's basically a trade-off in terms of experience: do you want to sit through a somewhat longer download process at the start, but then have everything right there, or do you want to have to wait constantly every time you scroll down?

Just to clarify, images are not render-blocking resources. The only render-blocking resource is the main stylesheet. Once that arrives, the browser will progressively render article content and images as they come in. On slow connections, the article will likely be readable in its entirely, while some of the images are still missing (white box reserved). This is browser default behaviour.

In addition, HTTP/2 request multiplexing also assigns a relatively lower priority to images in all major browsers. Which means images already get deprioritized, compared to article content and styles.

While there is a "longer download process at the start", this happens in the background while reading, not something users knowingly wait for.

This is to say that, bandwidth aside, this isn't even a trade-off. Without lazy-loading you already get the best of both. (Fast first render and shorter delays when reading later sections.)

With such reports on native image lazy loading: https://twitter.com/TheRealNooshu/status/1163827485076799489?s=20 and given how simple the implementation is (DOM element attributes), I think we should go ahead with native image lazy loading on desktop.

One thing we'll need to test is the browser's print feature (which we now promote prominently from the sidebar as well). In particular, to figure a way to force-load them (as mobile currently does), or to block on upstream browsers fixing this on their end if they haven't already.

We also need to warn developers and tech community to inform them that any code that uses the window "load" event, might stop working. As it might no longer wait for these images, and thus can no longer be used to know when it is safe to access dimension information (e.g. in mediaviewer, core gallery/slideshow, and gadgets).

Dimension information is exposed in attributes for thumbnails, for Media Viewer's sake. I don't think that Media Viewer relies on the load event to wait for anything, as users can click on thumbnails before the load event.

I'm surprised that printing is affected (verified on this demo: https://mathiasbynens.be/demo/img-loading-lazy), seems like a spec or implementation bug. Indeed, there is a Chrome bug for it: https://bugs.chromium.org/p/chromium/issues/detail?id=875403

As for workaround, there is an onbeforeprint event, but we would have to load the missing images as sync XHRs during that event, wouldn't we? Seems like this would cause a browser freeze.

The print feature in the sidebar seems to rely on a different version of the page, though (with different HTML), for which we could conceivably disable image lazy loading. The issue remains for users who invoke the browser's print feature directly themselves on an article.

@Gilles The printable=yes url linked in the sidebar for "Print this page" is a fallback for no-js and context/middle click only. By default, "Print this page" triggers the browser's own print feature for the current browser view.

At the time of T24256, we didn't find any use cases for the printable mode, so instead we promote the browser's own way of making a printable view - with the help of a few @media print style rules. I'm not sure why we kept the fallback, other than perhaps to reduce the amount of work done at once (so we could verify the hypothesis first), and perhaps for the convenience of IE6-8 users as these browsers don't support @media print and would not look as good in printed form without them.

See also:

• T24256: Change printable link to JavaScript `print()`
• T167237: Determine number of "Printable version" clicks per day
• T167956: Deprecate printable version mode

The fallback could be removed by making the link only visible for .client-js (without FOUC).

IMHO we should first investigate the problems with lazy image loading on mobile. In particular, I think essential images that are part of the main text flow of reading should be preloaded before they become visible. Often I try to read Wikipedia articles for instance in the subway, the text seems to be all right but without the essential images (like math formula) I can't make sense of the articles. I took the following screenshot today in the subway. It took almost a minute until the images did appear.

I'm surprised that printing is affected (verified on this demo: https://mathiasbynens.be/demo/img-loading-lazy), seems like a spec or implementation bug. Indeed, there is a Chrome bug for it: https://bugs.chromium.org/p/chromium/issues/detail?id=875403

As for workaround, there is an onbeforeprint event, but we would have to load the missing images as sync XHRs during that event, wouldn't we? Seems like this would cause a browser freeze.

Yeh that seems like an oversight to me. Looks like others have run into this too as I got some recent activity on an old bug for mobile's print problems - https://github.com/whatwg/html/issues/2532#issuecomment-524109565 - is this something we could flag in the w3c?

It's an HTML standard, so now handled by WHATWG, not the W3C. But I'm not sure that there's a proper standard proposal for the loading attribute yet anyway.

This is the actual HTML spec change proposal, I believe: https://github.com/whatwg/html/pull/3752

I think it would be really interesting to try this on one wiki for a short while and measure what kind of win it will make in number of bytes. If we can show the numbers, it would be easier to talk to Chrome to put prio on the solution for printing?

This is the plan for T230897

the upstream https://bugs.chromium.org/p/chromium/issues/detail?id=875403 bug has been fixed.

Using https://codepen.io/Krinkle/pen/GRBjXRG (via temporary debug URL, so no framing) checked the latest browsers.

In Chrome, the lazy images correctly don't load (using Devtools Network as validation), and when printing via menu or via JS button, it loads them, and the resulting preview includes the images on the last page indeed. Nice!

In Safari, it remains broken as per https://bugs.webkit.org/show_bug.cgi?id=224547.

We've been tracking this since last year at https://github.com/whatwg/html/issues/6581 in conversation also via our W3C WebPerf participation. We're now waiting for Apple or other WebKit contribitors to implement, and then for Apple to release it.

In T148047#8499754, @Krinkle wrote:

Using https://codepen.io/Krinkle/pen/GRBjXRG (via temporary debug URL, so no framing) checked the latest browsers.

In Chrome, the lazy images correctly don't load (using Devtools Network as validation), and when printing via menu or via JS button, it loads them, and the resulting preview includes the images on the last page indeed. Nice!

FYI: For documentation purposes this Chrome fix was done in jan 2022. https://bugs.chromium.org/p/chromium/issues/detail?id=875403

See also improvement done in February as part of T266155: Frequent "Error: 429, Too Many Requests" errors on pages with many (>50) thumbnails in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/883570

Today I noticed that we also have the images in [[Special:Log/upload]], which is apparently using yet another pager, which could use that same lazy load optimisation that I made for T266155

In T148047#9239019, @TheDJ wrote:

Today I noticed that we also have the images in [[Special:Log/upload]], which is apparently using yet another pager, which could use that same lazy load optimisation that I made for T266155

This is apparently a commons gadget, so no core functionality.
[edit]: This gadget was improved to set loading=lazy.