Currently, all images inserted by users in the page content are loaded eagerly.
This means that images are creating network activities even when they are not within the visible viewport.
As a consequence, pages with a lot of text and images (e.g., https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor%20Integration/) are more network intensive than they could, as users usually only read a few sections they are interested in.
To address this issue, it is possible to add a loading='lazy' attributes on img elements.
When this attribute is defined, images are only loaded when they are close to be within the viewport, based on browser specific heuristics.
To give some rough estimates, I manually made images from the CKEditor Integration page linked above lazy, and measured the network activity of the page. It went from 20.12MB to 18.84MB.
Therefore, I think it would be beneficial to improve our html rendering to make img elements lazy by default.
Different options are possible:
make all images lazy, as it does not seem to have drawbacks according to the documentations.
define a threshold, e.g., only make the Nth image lazy (assuming the one before that are likely to be within viewport)
some other heuristic?
Before discussing implementation details, what do you think of the general idea?
Thanks
PS: other image specific attributes such as src-set are also interesting to lower the network use of images, I plan to propose them in separate discussions.
Thanks for looking into this. I haven’t tried the loading='lazy' so I’m wondering if it can create UI flickering issues in the absence of an explicit width / height on the image. I mean, without loading the image and without the image dimensions specified the browser can’t know how much space to reserve for the image. For instance, if the image is inside a table, after some text, not in the initial viewport, I assume the browser may have to update the columns widths after the image is displayed. If browsers manage to update the layout smoothly after the image is loaded then +1 to use loading='lazy' on my side.
I tried with a slow network (2g speed in Firefox debugger).
With this kind of network, image load is perceptible (image being displayed gradually top to bottom). It also becomes worse when scrolling quickly to the bottom of the page, as all the intermediate images starts being loaded concurrently.
But, in practice, XWiki is pretty broken in 2g because of requirejs timeout.
Though, I agree we need to think of ways to avoid this, but I don’t yet have an option in mind that would be adaptable to different screen size while being userfriendly.
I did some other tests on a more controlled environment (9 image2, one paragraph between each image). It goes from 15.87MB to 2.47MB (about six times less).
Currently, the only other metric that seems to improve it the Largest Contentful Paint (LCP) with goes from 1.6s to 1.3s. I’m not yet convinced this number is significant.