No, and treating it as a blanket rule actively works against Largest Contentful Paint in the common case where the LCP element is an image. Lazy-loading is a net positive specifically for below-the-fold and off-screen images, because it defers requests the browser would otherwise make immediately, freeing bandwidth and main-thread priority for what the user actually sees first. Applying loading="lazy" to an above-the-fold image, and especially to whichever image is the page’s LCP candidate, delays the browser’s discovery and fetch of that exact resource, which directly and predictably worsens LCP. Google’s own documentation warns against this specific mistake by name; it is not a matter of interpretation.
Mechanism: why “lazy” helps below the fold and hurts above it
Native lazy loading (loading="lazy") works by telling the browser to defer fetching an image’s resource until it’s近 (near) the viewport, based on the browser’s own distance-from-viewport thresholds, rather than fetching it immediately when the HTML parser encounters the <img> tag. For images genuinely off-screen at load time, this is exactly the intended and beneficial behavior: the browser doesn’t waste bandwidth, connection slots, or decode/render work on content the user hasn’t scrolled to yet, and may never scroll to at all. This directly helps overall page weight, reduces contention on the network for critical above-the-fold resources, and can indirectly help metrics like Total Blocking Time by reducing simultaneous decode work.
The problem is what happens when that same attribute is applied to an image inside the initial viewport, particularly if that image is the one the browser’s LCP algorithm will select as the page’s largest contentful element. The LCP metric, as defined by Chrome’s Web Vitals team, is the render time of the largest image or text block visible within the viewport at any point during the page’s load. When the browser encounters an above-the-fold <img loading="lazy">, it does not treat it specially just because it happens to be immediately visible; the browser’s lazy-loading heuristic still defers the fetch, typically until layout has been calculated and the browser confirms the image is (or is about to be) within its loading threshold. This adds a sequencing delay before the request even starts, on top of the normal fetch and decode time, directly pushing back the render timestamp that LCP measures. web.dev’s own lazy-loading guidance states plainly that you should not lazy-load images near the top of the page, and specifically calls out the anti-pattern of lazy-loading what will become the LCP element, since doing so removes the ability of the browser’s preload scanner to discover and prioritize that resource early, which is precisely the mechanism modern LCP optimization guidance relies on (for example, using fetchpriority="high" on the LCP image, which is functionally the opposite instruction to lazy-loading it).
Why this misconception persists
The confusion comes from a reasonable-sounding but incorrect generalization: “lazy loading defers work, deferred work is asynchronous and non-blocking, non-blocking is good for performance, therefore more lazy loading is better.” This reasoning holds for resources genuinely not needed immediately, but Core Web Vitals, and LCP specifically, measure how fast the most important visible content appears, not how little total work the browser does. Deferring the fetch of the very resource the metric is timing is the one case where the general “defer non-critical work” heuristic inverts and becomes actively harmful, because the resource in question isn’t non-critical, it’s the single most load-bearing resource on the page for that metric.
Some CMS platforms and page builders made this worse by defaulting to lazy-loading every image on a template, including hero images and header banners, without excluding the first visible image or the LCP candidate. This is a known pattern Google has called out generally in Core Web Vitals guidance around common LCP regressions: blanket, unconditional lazy-loading defaults applied by themes or plugins without any above-the-fold exception.
Practical implication: what to actually do
The correct policy is conditional, not universal: lazy-load images that are reliably below the fold or off-screen at initial load, and explicitly exclude images that are above the fold, especially whichever one is likely to be the LCP element (commonly a hero image, a large product photo, or a featured image in a card layout at the top of a template). For the LCP candidate specifically, best practice per Google’s LCP documentation goes beyond just omitting loading="lazy"; it recommends actively prioritizing that resource, for example via fetchpriority="high" on the <img> tag and ensuring it isn’t hidden behind a lazy-loaded background-image in CSS (background images referenced via CSS are not covered by the HTML lazy-loading attribute at all and follow a separate loading path, which is a related but distinct pitfall).
Because “above the fold” isn’t a single fixed pixel boundary across devices, viewports, and templates, the safest implementation is usually to lazy-load everything by default at the template or CMS level but with an explicit override or exception for the first N images in a given template context (commonly just the first one or two), combined with periodically checking actual LCP element identification in PageSpeed Insights or DevTools’ Performance panel to confirm which image Chrome is selecting as LCP on real pages, since template assumptions about “the hero image is always the LCP element” can be wrong on pages where a different large image or text block ends up larger.
The one-sentence version for a checklist: lazy-load below the fold, never lazy-load the LCP candidate, and verify which element actually is the LCP candidate rather than assuming based on template design, because the entire Core Web Vitals benefit of lazy-loading depends on correctly scoping it to genuinely deferred content, not applying it uniformly.
