To lazyload or not to lazyload above the fold images

Let's get straight to the point:

Above the fold images shouldn't be lazyloaded

Above the fold images shouldn't be lazyloaded. Crystal clear, right? But as there could be multiple images above the fold, you might wonder which exact images shouldn't be lazyloaded. This depends on the page type and template design.

Hero images

Hero images are often used on homepages or blog- and article pages. On a homepage, a template could consist of multiple images, especially within e-commerce websites. The largest image shouldn't be lazyloaded. Other images could be lazyload to prevent resource competition amongst above the fold images.

Product images

Chances are your product detail page is using an image slider. For example via libraries such as owl carousel, tinyslider, flickity or more platform specific: Fotorama (Magento 2).

This means there are multiple images above the fold. However, only one image is really visible at a time, if we ignore the image thumbnails. Within such page template setup, you should lazyload all slideshow images, except the first. Makes sense, as the first image should be displayed as soon as possible, without a delay. And preferably without competition.

Company logo

Some websites are using plugins to lazyload all images. And sometimes developers will just implement lazyloading to all images, even the logo, as they heard lazyloading images is the number one optimization that should be applied to all images.

However, from a commercial or just branding perspective, I wouldn't advice to lazyload the logo. Next to a product title or product image, the logo might be as important. For example when users like to shop at a specific brand, or when your company is well-known for its service, low prices or any other unique selling points.

So, don't lazyload your logo. And if you really think lazyloading your logo is worthwhile, chances are you've got bigger pagespeed fish to fry. In that case, do get in touch to find out.

Above the fold image lazyloading questions

But why should we stop lazyloading above the fold images, if browsers just introduced native lazyloading? A web.dev article is explaining this already. This article was the result of Wordpress plugins lazyloading all images, which actually proved to be an anti-pattern when doing so for above the fold or just LCP images.

This and other questions is what I sometimes run into when seeing discussions or starting lazyloading image discussions myself.

Native lazyloading of LCP images

I think with native lazy load you can safely do it for all images, including LCP. The browser will determine if the image needs to be lazy-loaded or not

An incorrect statement on LinkedIn

The above is something people might think: it is safe to lazyloading above the fold images, such as LCP images.

However, only the latter is correct: the browser will determine this, which will take time, resulting in potential noticeable delay (keep reading if you're interested in the nuance).

No harm in lazyloading for in-viewport images?

The following basically boils down to the same question, as we're basically always referring to in-viewport images when talking about above-the-fold images. The question below illustrates that the characteristics of how a browser works is important as well to know how your frontend code could be impacting performance and UX.

Is it correct that loading=lazy immediately loads that image if it's in the viewport?

Someone on LinkedIn wondering if browsers will do the heavy lifting

Does lazyloading even work above the fold?

Does lazyloading even work above the fold?

Another question on Linkedin

Enough with the examples of image lazyloading questions, as they're basically all illustrating the same: it's time to explain what's going on in browsers' minds.

Native browser lazyloading explained

Let's stick with "Does lazyloading even work above the fold?". Well yes, it actually works a bit too good. So, when you're applying the loading=lazy attribute to your above the fold hero-image, it will actually work and will delay the download of your image.

If you're really in search of improving your hero image LCP, see this image LCP hack. But if that doesn't fit your website design, then stop lazyloading the image.

Browser characteristics

You might know that the image will appear above the fold. Maybe because you're the designer, the developer or because you've visited the website before and now recognizing the template. But the browser doesn't know. And that's because the browser first has to do several tasks:

1. download the CSS (or fetch it from the browser cache);
2. construct the CSS Object Model and doing layout work;
3. to only then being able to determine the position within the page;
4. check your internet connection type to determine the distance-from-viewport thresholds;
5. and only then it will start to download your LCP image.

Native versus JavaScript lazyloading

Obviously, the steps above will be faster then when showing the LCP would depend on JS, as it would then rely on yet another resource. And JavaScript work is more CPU heavy, so experiences might result in a bigger UX gap.

Moreover, when using native lazyloading, browsers might start to fetch images right away when they're in browser cache already. As a result, you might not notice real differences yourselves in image loading experiences with and without lazyloading them.

But your real audience won't all be browsing under the same conditions, such as installed plugins, internet connectivity, device type (memory, battery level and potential CPU throttling, temperature, et cetera) and even the page type. The delay (and thus negative impact) will be bigger during unique pageviews,. Unfortunately something that your Core Web Vitals data alone won't tell you.

That's why using lazyloading for your above the fold images is considered an anti-pattern. Especially users in the long tail experiences might notice this by a lot, but you want them to convert as well! So, go check your templates and revert lazyloading of your above-the-fold images.