Pro 4.0.7: Lazy loading issues

[Misho]

Hi!

X and Pro never worked with SG optimizer Lazy Loading, but they did worked with the one from WP Rocket. Since the latest updates it stopped working. I understand that Pro is supposed to Lazy load images in builders now, so I have deactivated my Lazy loading.

The results are not good. Not a single image is lazy loaded and external solutions are not working anymore.

Here is an example of a image-heavy homepage that can exist only with lazy loading: https://www.mojemalozlato.com/. Right now it drops 4MB of assets right to the initial load, and I need to fix that asap, without the need to remove most of the images.

Please note that the issue is present even with all plugins disabled.

Thanks!

[christian]

Hey @Misho,

May we know the exact method you’re doing to determine if images are lazy-loaded because upon checking, some images in your site has the loaded="lazy" attribute and value.

Regarding what you said:

@Misho

I understand that Pro is supposed to Lazy load images in builders now

Are you referring to the built-in WordPress’ Lazy Loading because I don’t see a lazy loading feature in the builder yet but correct me if I’m wrong or have missed an update.

If you’re referring to the WP Lazy Loading, it works on the Image Element as well as the <img/> Background. It, unfortunately, doesn’t work on the Classic Image element and the Background Image type.

I’m also not sure how WP Rocket’s lazy loading works but I’ve personally tested ShortPixel and its lazy loading feature works on all images in the site except for the Background Image type.

Thanks.

[Misho]

Hi!

I use several methods to determine if images are lazy loaded:

1. GTM Waterfall > Filter for images. They are all loaded in the test, which means that they are not lazy loaded.
2. Pingdom > Same as GT Metrix. If images were lazy-loaded, waterfall would not show them.
3. Quickly pulling the scrollbar downwards on the page: images are already there. If lazy loaded, it would take them a fraction of second to appear
4. loading="lazy" was present on a single image on the entire page (the same one you have found), while there were 35 images inside <img> tags. Now I have reduced the number of images.

@christian

If you’re referring to the WP Lazy Loading, it works on the Image Element as well as the <img/> Background. It, unfortunately, doesn’t work on the Classic Image element and the Background Image type.

Yes. Now more images have the lazy attribute, but they are still not getting loaded. I have switched all Grid cells to have <img> tags instead of the background image. Grid cells do have loading="lazy", but if we inspect the first image below the CSS Grid, it doesn’t have loading="lazy", despite being exactly the same type of image as the one that is displayed above the CSS Grid.

@christian

I’m also not sure how WP Rocket’s lazy loading works but I’ve personally tested ShortPixel and its lazy loading feature works on all images in the site except for the Background Image type.

WP Rocket was able to lazy-load everything in Pro, including background images. Right now when enabled, it isn’t effective on this page.

Thanks!

[alexander]

Hi @Misho,

Thanks for bringing this up. I was able to find some inconsistencies with how lazy loading is detected. It was applying loading="lazy" only to images added via an attachment ID (i.e. images added since Pro 4). I’ve made some adjustments for the next point release. Let’s see if that alleviates some of the problems you’re seeing here (once we get the release out.

For context, this is the full extent of what we are doing to enable lazy loading:

if ( $enabled && function_exists('wp_lazy_loading_enabled') && wp_lazy_loading_enabled( 'img', 'cs_apply_image_atts' ) ) {
  $atts['loading'] = 'lazy';
}

We use wp_lazy_loading_enabled to ensure the site is running WordPress 5.5 and doesn’t have filters to disable native WordPress lazy loading. If it’s allowed, we output the attribute which tells modern browsers what to do. This is run on all V2 elements when the img tag is being generated. It doesn’t get run on text content.

Because we’re simply adding that attribute in certain cases, I’m not sure why all of a sudden we’d see incompatibilities with other lazy loading systems.

In correcting the anomalies mentioned above, I was able to find a way to retroactively add it to classic elements but I’m concerned its a bit late in the cycle to implement that. What we’re going to pursue as early as the next cycle is running all Pro output through the WordPress wp_filter_content_tags function which will ensure lazy loading of everything, even classic images and images found in text content. Regretfully it opens up some new challenges like potentially breaking retina image output. We’ll need some more dedicated time to unpack it, but it’s definitely a priority to bring consistency to how that works.