PagespeedInsights shows defer offscreen images even when image is lazy loaded?

Question

PageSpeedInsights shows defer offscreen images even when the image below is lazyloaded

<img data-src="https://www.healinghandsclinic.co.in/images/successfull-stories/australian-Patient.jpg" alt="" title="" class="img-responsive lazyloaded" src="https://www.healinghandsclinic.co.in/images/successfull-stories/australian-Patient.jpg">

Can someone please explain what the above code means especially this part:

 class="img-responsive lazyloaded"

How can I defer this image?

Defer this image

<img data-src="https://www.healinghandsclinic.co.in/images/successfull-stories/australian-Patient.jpg" alt="" title="" class="img-responsive lazyloaded" src="https://www.healinghandsclinic.co.in/images/successfull-stories/australian-Patient.jpg">

Answer 1

If this code snippet is directly coming from the server side rendered HTML, both the src attribute value as well as data-src attribute are the same.

This then means that the browser will start to fetch the src resource right away: https://www.healinghandsclinic.co.in/images/successfull-stories/australian-Patient.jpg

And if that image is not visible within the viewport (as used by Lighthouse), it will still end up competing for bandwidth with other (image & non-image) resources.

Hence PageSpeed Insights (PSI)/Lighthouse's recommendation to defer off-screen images.

However, given the CSS classes used on your image element (class="img-responsive lazyloaded"), it's likely that the code snippet you're sharing is actually the end result after some lazyloading JS library loaded the image.

The same theory as above still applies: the initial fallback image (which might just be a low-quality version of your image or a 1x1 placeholder) might have ended up being downloaded, and that was discovered by PSI.

Without additional info, it's hard to say which image was initially found by PSI.

Solution

Regardless of your scenario, there is a 2-step best practice & solution here:

• remove your JS lazyloading library;
• and then go with native lazyloading (which just means adding a loading="lazy" attribute to your <img>);
• it might be convenient to also change CSS bg images (if you have any) into <img> as that gives you more loading options/control

As using native lazyloading allows you to remove JavaScript, it will then improve your JS performance and TBT (lab data/Lighthouse metric) and INP (field data/part of Core Web Vitals) as well!

Resources

This is an old Google article that talks about JS libraries: https://web.dev/articles/lazy-loading-images

But with native lazyloading, we don't need JS anymore (a new Google article on this subject): https://web.dev/articles/browser-level-image-lazy-loading#why_browser-level_lazy_loading

Code example and support in all major browsers (for both <img> and <iframe>): https://www.linkedin.com/feed/update/urn:li:activity:7129755923555737601/ When/what to lazyload: https://www.erwinhofman.com/blog/to-lazyload-above-the-fold-images/