Lazy Loading: A Practical Guide That Won't Ruin Your Site's LCP

Your Above-the-Fold Image Is Blurry and LCP Has Passed 4 Seconds

You open the site, the top of the page is empty, then the header image slowly appears. In PageSpeed Insights, Lighthouse also says "Largest Contentful Paint" has exceeded the limit. You've found the culprit: an attribute called loading="lazy" that you happily added to all images a month ago. This is exactly where lazy loading turns from an optimization tool into an anti-pattern.

Let's settle this once and for all. Lazy loading means the browser won't download an element until the user gets close to it. The idea is sound: long, image-heavy pages without it transfer megabytes of useless data. But incorrect implementation destroys Google's primary user experience metric. This article isn't just about "how"; it's about "where" and "where not."

Where Lazy Loading Really Helps

Imagine you have a product page with 40 gallery images, or a blog with 15 photos in a long post. The user has to scroll to see the tenth image. If all images are downloaded from the start, bandwidth is wasted and full page load time increases. This is where lazy loading works wonders: the browser only fetches images near the viewport and holds off on the rest until needed.

See the practical result with a simple test. Consider a page with 20 images of 200 KB each. Without lazy loading, the browser downloads about 4 MB. With it, maybe only 2 MB until the moment of full scroll. That means better TTFB and perceived speed, and for mobile users with limited data, a real difference.

But that's only half the story. Proper lazy loading isn't limited to below-the-fold images. If you have a YouTube video iframe or a Google Map at the bottom of the page, apply the same logic. These are the heaviest elements on a page, and there's no reason to download them until the user reaches them.

How to Implement It Correctly

The simplest way is the native HTML attribute. One line of code, no libraries needed:

<img src="product-1.jpg" alt="Product number 1" loading="lazy" width="800" height="600">

Make sure you include width and height. Without these, the browser doesn't know the image's space, and the page jumps during scroll. This jump increases CLS (Cumulative Layout Shift) and ruins the second Core Web Vitals metric. If the image is responsive, use srcset with the same attribute:

<img src="small.jpg" srcset="small.jpg 400w, large.jpg 1200w" sizes="(max-width: 600px) 400px, 1200px" loading="lazy" width="1200" height="800" alt="Description">

For older browsers that don't support loading="lazy" (Safari before 15.4), use libraries like lazysizes. But first ask: does your audience actually use these browsers? Check your Google Analytics stats. If the share of old Safari is under 2%, don't add a library; a 30 KB script is itself part of the problem.

Where Lazy Loading Ruins LCP

LCP means the largest content element visible in the initial viewport. Usually, this is the header image, main slider, or a large heading. If you give this image loading="lazy", the browser delays its download. The result? The user sees an empty or half-empty page, and your LCP goes from 2.5 seconds to 4 or 5 seconds.

This is where people go wrong: many think "if I lazy-load all images, the site will be faster." The result shows in PageSpeed Insights: a red warning saying the LCP image was loaded with delay. This error is so common that Google has a dedicated audit for it: "Largest Contentful Paint image was lazily loaded."

The golden rule: any element visible within the first 1000 pixels of the page (or better, in the initial viewport) should never be lazy-loaded. This includes the logo, header image, and main slider. For these, use fetchpriority="high" to tell the browser this element is critical:

<img src="hero.jpg" alt="Main banner" fetchpriority="high" width="1920" height="1080">

Note that you shouldn't combine this attribute with lazy. The two contradict each other, and the browser may behave unpredictably. Use one or the other.

How to Tell Which Image Is the LCP

Don't forget Google's free tools. In Chrome DevTools, open the Performance tab, record once, and look at the Timings section. The LCP element is marked with a blue label. PageSpeed Insights also gives you a detailed report. If you don't want to dive into these details, I have a simple rule of thumb: any image visible without scrolling is LCP or close to it. So don't lazy-load it.

For a more precise technical check, you can use online DNS and HTTP header checking tools to ensure your server responds correctly. DNS delay or high TTFB will ruin LCP even with proper lazy loading. See these as separate issues: lazy loading only delays the browser's download, but if the server itself is slow, no client-side trick will help.

Don't Forget CSS Background Images

Another common scenario: background images defined with background-image in CSS. The native loading="lazy" attribute doesn't work on them. These images are outside HTML, and the browser treats them like a regular asset. The result? If you have a heavy background image at the top of the page, it gets downloaded without any control and ruins LCP.

What's the solution? You have two options. First, if the background image is purely decorative, replace it with a CSS gradient or a solid color. Second, if you really need it, use the content-visibility: auto technique:

.lazy-bg {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

This property tells the browser to delay rendering this section until it's in the viewport. But note: this is for rendering, not downloading. The browser may still download the image; it just delays the render. For true download control, you need to use Intersection Observer and conditionally add the class. This is more complex, but it's the only correct way for background images.

Lazy Loading and SEO: A Misunderstood Relationship

Google has stated that it understands lazy loading and indexes lazy-loaded content. Google's crawlers view the page with a larger viewport and examine lazy-loaded elements too. So don't worry that below-the-fold images will be excluded from indexing. But there's one condition: if you use JavaScript for lazy loading, make sure the content is accessible without JS. If an image only loads via JS and Googlebot can't execute the script, that image is lost for SEO.

Another important point: lazy loading is not a replacement for image compression. If you lazy-load a 5 MB image, you've only delayed its download; when the user reaches it, they'll still get that 5 MB. WebP or AVIF formats, compression with tools like Squoosh, and correct dimensions are always the first priority. Lazy loading is just the final layer of optimization, not the whole story.

If you want to combine an optimized image with lazy loading, get the order right: first compression, then correct dimensions, then lazy loading. Don't reverse this order. Many people think lazy loading means "I no longer need to optimize the image." That's a mistake, and the end user pays for it with slow scrolling and lag.

The Final Decision: When to Use Lazy Loading

A simple table for quick decision-making:

If your site is a short landing page with 3 images, lazy loading barely helps. The added complexity isn't worth it. This technique is designed for long pages with lots of content, not for everything. My choice? For every new project, I first compress images, set exact dimensions, and only then add lazy loading for below-the-fold elements. If the page is short, I don't add it at all.

One final note on tools: if you work with WordPress, plugins like Smush or ShortPixel automate this. But automated means imprecise. These plugins typically lazy-load all images, including the header image. After installation, be sure to check the homepage in PageSpeed Insights, and if you see the "lazily loaded LCP image" error, exclude the header image from the lazy list. This is exactly where automated tools can backfire on you.

If you're looking for a more comprehensive review of your site's speed status, ServerNet's SEO and webmaster tools can give you an overview of your site's technical condition. But remember: no tool replaces a proper understanding of browser behavior.

Frequently Asked Questions

Does lazy loading negatively affect SEO?

No, if implemented correctly. Google indexes lazy-loaded content and doesn't distinguish between a normal image and a lazy-loaded one. The problem only arises when content isn't accessible without JavaScript, or when you lazy-load the LCP image and slow down the site, which indirectly affects rankings.

How do I know lazy loading is working?

In Chrome DevTools, open the Network tab and refresh the page. Look at the request list; below-the-fold images shouldn't be downloaded initially. Now scroll and watch as each image's request is sent as you approach it. If all images are downloaded from the start, either you haven't set the attribute correctly or the browser doesn't support it.

Does lazy loading work for videos too?

Yes, you can use loading="lazy" on the <video> tag too, but browser support is more limited. A more reliable method for video is using the preload="none" attribute, which tells the browser not to download the video until playback starts. For YouTube iframes, loading="lazy" works well too.

What's the difference between lazy loading and preload?

These two are exact opposites. Lazy loading says "don't download until needed." Preload says "download now because it'll be needed soon." For the LCP image, use fetchpriority="high" or preload; for everything else, use lazy loading. Combining both on a single element makes browser behavior unpredictable.