View contents
Introduction
Lazy loading has a good reputation, and deservedly so: deferring images the user can't see yet saves bandwidth and speeds up initial page load. The trouble starts when that same technique is applied without discriminating, to the wrong image. Defer your LCP (Largest Contentful Paint) image and you aren't optimizing anything, you're delaying the first thing the user needs to see.
This article explains the why. What LCP actually measures, how deferral through loading="lazy" works, and why combining the two pushes your most visible metric in the opposite direction. It isn't a step-by-step tutorial: if you've already spotted the problem and want to fix it in your CMS or framework, the practical guide is linked below.
What LCP is and why it matters
Largest Contentful Paint (LCP) measures how long it takes for the largest content element in the initial viewport to become visible, usually an image or a block of text. Google uses it as one of the Core Web Vitals, the set of metrics that assess loading experience and feed into its ranking signals.
The thresholds Google defines:
- Good: ≤ 2.5 seconds
- Needs Improvement: 2.5 - 4.0 seconds
- Poor: > 4.0 seconds
On most pages the LCP element is a hero image, the featured product photo, or a large banner. In other words: almost always the image that gives the screen its meaning, the one the user is waiting for. That's why LCP works as a good proxy for perceived speed: it doesn't measure when everything finishes loading, but when the thing that matters shows up.
How browser lazy loading works
The loading="lazy" attribute tells the browser to postpone downloading an image until it's about to enter the viewport. It's a native mechanism, no extra JavaScript required: the browser watches the element's position and only fires the network request when the user scrolls near it.
<!-- Correct use: an image that lives below the fold -->
<img src="gallery-3.jpg" alt="Description" loading="lazy">
For a thumbnail at the foot of the page or the fourth image in a gallery, this is exactly what you want: don't spend network on something the user may never reach. Deferral is a prioritization tool, and like any prioritization, it only helps if it tells the urgent apart from what can wait.
The mechanism: why deferring the LCP delays the metric
Here is the heart of the problem. When you mark your LCP image with loading="lazy", you're asking the browser to treat as deferrable the very resource that defines your loading metric. The browser obeys, and that's what hurts.
Without deferral, the browser discovers the image while parsing the HTML and starts downloading it immediately, in parallel with the rest of the resources. With loading="lazy", the sequence changes:
- The browser parses the HTML and finds the hero image.
- It sees
loading="lazy"and decides not to request it yet. - It needs to compute layout to know whether the image falls inside the viewport.
- Only once it confirms the image is visible does it fire the download.
- The image arrives late, and LCP is recorded hundreds of milliseconds later than it should be.
The paradox is that the LCP image is already in the viewport from the very first moment. Deferral was designed for off-screen resources, but the browser can't assume an element is visible without first resolving layout. That intermediate work, waiting for layout instead of requesting the image the instant it's discovered, is the artificial delay. According to web.dev, applying lazy loading to the LCP element can add 500ms or more to the metric. It isn't that the browser is failing: it does exactly what you asked, defer. The mistake was asking it for the wrong image.
What breaks in Core Web Vitals and SEO
LCP doesn't live in isolation. It's one of the three Core Web Vitals, and Google folds it into its page experience signals. An LCP that crosses the 2.5-second threshold doesn't just feel slower to the user: it can move your Core Web Vitals assessment from passing to failing, with the effect that has on how competitive the page is in search results.
What makes this mistake so common is that it's usually invisible in the source. Nobody consciously writes loading="lazy" on their hero image; it arrives by default, through an optimization plugin, a CMS theme, or the standard behavior of a framework component. The intent was to speed the site up, and the result was to slow down the very metric search engines watch most.
The principle: selective lazy loading
The takeaway isn't to abandon lazy loading. It's to apply it with judgment. The rule fits in one line: if the user sees the image without scrolling on most devices, don't defer it.
Deferring (loading="lazy") makes sense for content the user hasn't seen yet:
- Images below the fold, further down the page
- Product photos past the first visible row of a grid
- Blog thumbnails, gallery items, footer images
- Content inside carousels, tabs, or hidden sections
Loading with priority (no deferral) belongs to the content the user sees right away:
- The hero image
- The first visible product photo
- Any above-the-fold image
- Your LCP element, whatever it is
Seen this way, lazy loading isn't a switch you flip for the whole site, but a per-image decision. The same technique that speeds up a twenty-photo gallery is the one that slows your hero down when you apply it without discriminating. The goal isn't to defer everything or nothing, but to reserve the network for what the user needs first.
How to fix it
The conceptual fix is direct: remove loading="lazy" from your LCP image and, if you want to go one step further, tell the browser to prioritize it with fetchpriority="high". But identifying exactly which element your LCP is, tracing where the attribute came from (a WordPress plugin, Shopify's auto-lazy, a JavaScript library, a framework's image component), and verifying the improvement is work with its own steps. All of that is covered in detail by How to detect and fix lazy loading on your LCP image, using DevTools, Lighthouse and PageSpeed Insights, with platform-specific fixes. This article stays with the why; the how lives there.
Related Articles
- How to detect and fix lazy loading on your LCP image - Step-by-step diagnosis and fixes across CMS and frameworks
- LCP Optimization Guide - Complete guide to improving Largest Contentful Paint
- Image Fetchpriority Explained - How to prioritize loading a critical image
- Image Preloading Explained - When to preload images
- Images SEO Hub - All image optimization guides
References
- web.dev - Largest Contentful Paint - Google's official LCP documentation
- web.dev - Browser-level lazy loading - When to use lazy loading
- Chrome Developers - Lighthouse LCP - Measuring LCP
- MDN - Lazy loading - Technical reference