I am looking at disadvantages of lazy-loading images, and I must be hyper-thorough because we are considering implementing loading="lazy" on many/most images in the site. The reason for that is that I believe I have a strategy that should work.
We are using the browser-native loading="lazy" attribute, since we dropped support for IE recently. Wow, I know.
We are setting all images above the fold to eager, and all images below to lazy, across the entire site.
Then we are listening for the page load event and running a script that converts every image with loading="lazy" to loading="eager" (or auto). So images below the fold will get loaded too, probably in most cases by the time the user scrolls (at least using modern internet connection speeds). The page load event fires after all eager-loaded images have completed, but may/should fire before lazy-loaded images have started, so that is our opportunity to trigger loading below the fold.
One known disadvantage is that lazy-loaded images can cause a layout shift as the user scrolls, since the browser doesn't know the dimensions until the image starts loading. Another disadvantage is that users may be annoyed by images that are not loaded by the time they scroll to the image. This solution addresses both of those problems by converting remaining lazy-loading images to eager as soon as the prioritized images are loaded, to reduce the chance of the user encountering these issues.
There is also the possibility that there may be specific cases where pieces of JavaScript are waiting for an image to load in order to do something with it, and that can sometimes block rendering. Let's treat that as a side issue. I think it's unlikely we'll encounter that in this site, and we'll fix it where it occurs.
A side note, I have also devised a script that observes elements being populated or manipulated on the DOM by external scripts, and converts any newly-added img elements to loading="lazy" (if it occurs before page load), so I am able to guarantee lazy loading on all img elements on the page, and it DOES yield Lighthouse load performance gains of several points.
I am so far not finding many serious and/or likely problems from lazy-loading every or most images on a page, given that it is handled with the strategies that I have devised.
My question is what am I missing. Could this strategy have gaps?
What other considerations do I need to think about? Because I don't want my decisions to cause problems on the site I am working on.
What you may not know if you've never used browser-native lazy loading is that it does not necessarily improve initial load size/time on shorter pages, because it still initiates loading anything closer to the viewport than 3000 pixels, even before the window load event fires. This is what is considered too eager.
Info about this issue: https://calendar.perfplanet.com/2019/native-image-lazy-loading-in-chrome-is-way-too-eager
That can make it useless against Google's Lighthouse performance metrics for shorter pages.
So we are implementing the old-fashioned non-native lazy loading where we have complete control via JavaScript. Our images are served like:
<img data-src="some-image.src" />
<noscript>
<img src="some-image.src" />
</noscript>
...And using JavaScript strategy similar to what was described in the original question here, in addition to the common technique for swapping Image.dataset.src into the Image.src property, or we many use lazySizes.
But I don't get a few things about the functionality of browser-native lazy loading. Particularly, why the browser wouldn't prioritize lazy images above the fold over lazy images below the fold, and not load any lazy image below the fold or fire the load event until everything is loaded above the fold.
And I don't get why lazy loading can't be set with CSS. It would be great if we could apply the loading attribute to sections of a page by CSS selectors alone. Instead we're forced to handle it either with JavaScript or on the server. With CSS it would be as simple as loading: lazy;.
I'm going to look into if these ideas are proposed anywhere. I may also post the code we use in the end.