Interpreting Results After Implementing Lazy Loading


Whenever we implement lazy loading for a client it’s a hit. The data we garner, however, is subjective so I’d like to get the other half of reality, so to speak.

The thing is this: whenever we implement lazy loading, it kills the site’s speed index; and, in online tools (such as WPT) merely pushes the load of the images down the waterfall thereby extending the reported load time beyond (significantly beyond) what it was prior to implementation. Needless to say, some clients get really stuck on what these tools report even though they, themselves, are thrilled with the “real world” results.

Anyway, I’m having a hard time getting a bead on how to best interpret these results and am wondering if WPT is even set-up to be able to account for lazy loading(?).


Thanks so much,

Lazy loading should have the opposite impact on speed index which only looks at the rendering of the above-the-fold part of the page (and it’s the best metric for showing the benefits of lazy loading).

Depending on how you are implementing the lazy loading it can have a lot of different impacts.

If you load the images as they scroll into view it can be pretty jarring and there’s a chance that the user will see blank space while scrolling (and on mobile it may be even worse if it has to wake up the radio).

If you load the images off of a timer then it may start loading them before the above-the-fold images load.

If you load them based on the load event firing for the above-the-fold images it’s possible that the images will still push out onload.

Generally my favorite way to do it is to fire a setImmediate/0ms timeout in the onload handler for the page and load the lazy load images after the page content has finished. The onload metrics will be a good representation of the user experience and the fully loaded time will let you know when the lazy-load images have finished.

Thanks again, Patrick.

What we nearly always do (because it’s generally the easiest and quickest thing to do) is load the images as they scroll into view on desktops, and disable lazy loading altogether for tablets and mobiles.

In the above-linked test results, that’s what we’re doing. What I don’t quite get is why/how those images (the images loaded after DOM content is loaded are the lazy loaded images) are being loaded at all if the test is accurately simulating a human user. In short: why aren’t these HTTP requests eliminated as opposed to being pushed out/down as indicated in the above tests?

Never mind. In the instance I posted there was a conflict with the lazy loading technique used and visibility classes. Which I’m gonna go out on a limb and say also explains the other instances in which I’ve seen similar results.