How Incorrect Lazy Loading Hurts LCP

Lazy loading is designed to save bandwidth and reduce initial network contention by deferring the download of offscreen assets until a user scrolls near them. However, a common performance anti-pattern occurs when incorrect lazy loading hurts Largest Contentful Paint (LCP) by delaying images that appear inside the initial visible viewport. When hero banners, featured article headers, or primary product photos are configured to load lazily, the browser postpones fetching the largest visual element on the screen, directly increasing LCP times.

The core implementation rule is straightforward: images visible above the fold should be loaded eagerly, while lazy loading should be reserved strictly for below-the-fold resources. Because the primary viewport image is frequently the LCP candidate, it needs to be discovered by the browser's preload scanner as early as possible in the page load lifecycle rather than waiting for layout calculations or JavaScript execution to confirm its visibility.

In practice, this misconfiguration rarely happens because a developer intentionally delays a hero image. Instead, it usually stems from global CMS settings, performance plugins, or frontend component libraries that apply loading="lazy" or JavaScript-based lazy loading attributes to every image template by default. Resolving the issue requires identifying which images sit within the initial viewport across target devices and explicitly excluding them from automated lazy-loading rules so the browser can fetch and render them immediately.

Why lazy loading initial viewport images degrades largest contentful paint

To understand how lazy loading degrades Largest Contentful Paint (LCP), it is helpful to decompose LCP into its four technical sub-parts: Time to First Byte (TTFB), resource load delay, resource load duration, and element render delay. Resource load delay measures the time between the initial HTML response arriving (TTFB) and the browser actually starting to fetch the LCP image. Element render delay measures the time between the image finishing its download and the browser painting it onto the screen. Lazy loading an initial viewport image directly inflates resource load delay, and depending on the implementation method, can also increase element render delay.

The preload scanner and the critical rendering path

During a standard page load, the browser parses the HTML document to construct the Document Object Model (DOM). Whenever the main HTML parser encounters synchronous scripts or stylesheets, it may pause DOM construction to fetch and execute those resources. To prevent network idle time during these pauses, modern browsers run a secondary, lightweight parser called the preload scanner.

The preload scanner looks ahead through the raw HTML markup specifically to discover external resources-such as standard <img> tags containing src or srcset attributes-and queues their network requests immediately. When an above-the-fold image is configured normally, the preload scanner discovers the image URL within milliseconds of receiving the first chunk of HTML, keeping resource load delay to a minimum. Applying lazy loading disrupts this early discovery mechanism through one of two distinct failure modes.

Native lazy loading vs. JavaScript lazy loading

The severity of the performance penalty depends on whether the site relies on native browser lazy loading or a third-party JavaScript library.

1. Native lazy loading (loading="lazy")

When an <img> element includes the native loading="lazy" attribute, the image URL remains visible in the HTML markup, but the browser intentionally holds back the network request. Because the browser does not know where the image sits on the page until styles are applied, it must first download CSS, construct the CSS Object Model (CSSOM), combine it with the DOM to build the render tree, and calculate layout geometry.

Only after layout completes can the browser evaluate whether the image intersects the visible viewport (or falls within the browser's internal scroll-distance threshold). Waiting for CSS parsing and layout calculations before initiating the fetch adds measurable resource load delay compared to an eager request initiated by the preload scanner. Furthermore, even when the request begins, the browser may initially assign it a lower network priority than an eagerly loaded viewport image.

2. JavaScript-Based lazy loading (data-src and intersection observer)

JavaScript-driven lazy loading-whether built with custom Intersection Observer logic or libraries such as lazysizes -creates a larger bottleneck. These implementations strip the image URL from the standard src and srcset attributes and store them in non-standard data attributes like data-src or data-srcset .

Because the preload scanner only reads standard HTML resource attributes, it is completely blind to URLs inside data-src . As a result, the image request is blocked by a multi-step dependency chain:

1. The browser must download, parse, and execute the lazy-loading JavaScript bundle.
2. The browser must complete layout so the Intersection Observer API (or scroll listener) can detect that the placeholder element is inside the viewport.
3. The script must mutate the DOM by copying the value from data-src into the standard src attribute.

This sequence severely inflates resource load delay, especially on pages with heavy script contention on the main thread. Additionally, because the image swap depends on JavaScript execution and subsequent style recalculations, main-thread blocking can also delay the paint cycle after the file downloads, increasing element render delay.

Related Anti-Patterns: LQIP and CSS background images

Two adjacent rendering patterns cause similar delays for the LCP element even when the term "lazy loading" is not explicitly used in the markup:

• Low-Quality Image Placeholders (LQIP): Many frameworks and plugins load a tiny, blurred inline data URI or a heavily compressed placeholder in the initial src attribute, then use JavaScript to swap in the full-resolution image after load. According to the Largest Contentful Paint specification, browsers may ignore very low-entropy images or overwrite the initial candidate entry once a higher-resolution image paints over the same screen area. Consequently, the final LCP timestamp is recorded when the high-resolution image finishes rendering, meaning the LQIP swap directly increases both resource load delay and element render delay.
• CSS Background Images: Placing the primary hero visual inside a CSS background-image: url(...) property mimics the timing penalty of native lazy loading. Because the preload scanner does not parse external stylesheets to determine which CSS rules match the DOM, the browser will not fetch a CSS background image until it has downloaded the CSS file, built the render tree, and confirmed that the styled element is visible.

How to identify lazily loaded Above-the-Fold images

Detecting whether an initial viewport image is delayed requires checking both the HTML delivered by the server and the timing of network requests in the browser. A complete diagnostic workflow combines automated lab audits, manual DOM inspection, and network waterfall analysis to confirm which element is the Largest Contentful Paint candidate and why its discovery is delayed.

Automated lab auditing in lighthouse and PageSpeed insights

Lighthouse and PageSpeed Insights provide the fastest initial check for lazy-loaded LCP candidates. When running a performance audit, inspect two specific diagnostics in the report:

• Largest Contentful Paint element: This diagnostic identifies the exact DOM node recorded as the LCP candidate during the test run, allowing verification of whether the primary above-the-fold image is the element governing the LCP timestamp.
• Largest Contentful Paint image was lazily loaded: Lighthouse triggers this specific audit when it detects that the LCP image uses native lazy loading or is deferred by scripts. Passing this audit in Lighthouse does not always guarantee the image loaded early; custom JavaScript lazy-loading libraries that swap attributes after initial layout can sometimes evade simple attribute checks while still delaying the network fetch.

Because the element occupying the largest viewport area often differs between screen sizes, run lab audits across both mobile and desktop configurations. An image that sits below the fold on a narrow mobile viewport may sit squarely above the fold on a widescreen desktop layout.

Manual DOM and source inspection in chrome DevTools

Inspecting the page markup in Chrome DevTools reveals whether lazy-loading attributes are present on images visible in the initial viewport before scrolling. When verifying markup, distinguish between the live DOM in the Elements panel and the raw HTML response in the View Page Source tab.

Look for the following indicators on <img> and <picture> elements located above the fold:

• Native lazy loading attributes: Check whether the <img> tag contains loading="lazy" .
• Non-standard data attributes: Look for attributes such as data-src , data-srcset , data-sizes , or data-lazy-src . In the live Elements panel, a JavaScript library may have already mutated these into standard src and srcset attributes by the time DevTools is opened. Checking the raw server response (via View Page Source or the Response sub-tab of the main document request in the Network panel) confirms whether the initial HTML hid the image URL from the preload scanner.
• Lazy-loading CSS classes and placeholder sources: Look for classes such as lazyload , lazyloaded , or lazy alongside a missing src attribute, an empty src="" , or a src containing a base64-encoded data:image/svg+xml or data:image/gif placeholder.

Network waterfall analysis in chrome DevTools and WebPageTest

A network waterfall chart in the Chrome DevTools Network panel or WebPageTest provides definitive evidence of when the browser discovers and requests the above-the-fold image relative to the initial HTML document.

To capture an accurate trace in Chrome DevTools without scrolling interference, keep the viewport at the very top of the page, open the Network panel, enable the Disable cache checkbox, and reload the page. In the resulting request list, check the Priority and Initiator columns alongside the waterfall timeline for the hero image:

In WebPageTest, the waterfall chart visually marks key rendering milestones as vertical lines. If the request bar for the primary above-the-fold image begins to the right of the First Contentful Paint (FCP) vertical line-or starts immediately after a JavaScript execution block-the browser was unable to discover the image via the preload scanner. That horizontal gap between the end of the main HTML document download and the start of the image request represents the exact resource load delay caused by lazy loading or late discovery.

Configuring HTML attributes for Above-the-Fold images

Resolving lazy-loading delays on initial viewport images requires updating the raw HTML markup served in the initial document response so the browser's preload scanner can discover and prioritize the resource immediately. A complete implementation involves three attribute adjustments on the target image element.

1. Remove native lazy loading or set eager loading explicitly

Eager loading is the default behavior for standard HTML <img> elements. When an image tag does not contain a loading attribute, the browser automatically treats it as eager and queues the fetch as soon as the preload scanner encounters the tag.

In static templates or custom builds where markup is controlled directly, remove the loading="lazy" attribute entirely. In environments where a content management system, theme filter, or server-side middleware automatically injects loading="lazy" into any image tag missing a loading attribute, explicitly declare loading="eager" . Setting the attribute explicitly often acts as a signal to template parsers that the loading behavior has already been defined, preventing automated scripts from overwriting it.

2. Replace Non-Standard data attributes with standard image attributes

If a JavaScript lazy-loading library is managing the image, removing loading="lazy" alone will not expose the image URL to the preload scanner. The image path must be moved out of custom data attributes and back into standard HTML attributes:

• Move the primary image URL from data-src to src .
• Move responsive image candidate strings from data-srcset to srcset .
• Move layout sizing definitions from data-sizes to sizes .
• Remove the JavaScript initialization class (such as lazyload or lazy ) and any inline placeholder URI (such as a 1x1 transparent GIF or Base64 string) previously occupying the src attribute.

3. Add high fetch priority to the primary LCP image

Even when an image is discovered early by the preload scanner, browsers often assign images an initial network priority of Low or Medium while the document parser evaluates blocking stylesheets and scripts. Only after the layout phase confirms the image is inside the visible viewport does the browser elevate its priority to High.

Adding fetchpriority="high" to the Largest Contentful Paint (LCP) image bypasses this waiting period. It instructs supporting browsers to assign a High network priority to the image download immediately upon discovery during initial HTML parsing, allowing the image request to compete alongside critical resources.

Standard and responsive markup examples

For a standard responsive <img> element serving as the primary hero or featured image, the properly configured markup uses standard source attributes, explicit dimensions, and high fetch priority:

<img
  src="/images/hero-product-800.jpg"
  srcset="/images/hero-product-400.jpg 400w,
          /images/hero-product-800.jpg 800w,
          /images/hero-product-1200.jpg 1200w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="Primary product showcase"
>

When using a <picture> element for art direction or next-generation format delivery (such as AVIF and WebP), each <source> element must use the standard srcset attribute rather than data-srcset . However, attributes that control fetching and layout-including fetchpriority="high" , loading="eager" (if needed), width , and height -must be placed on the inner fallback <img> tag, not on the outer <picture> wrapper or the <source> tags:

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-400.avif 400w, /images/hero-800.avif 800w, /images/hero-1200.avif 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
  >
  <source
    type="image/webp"
    srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
  >
  <img
    src="/images/hero-800.jpg"
    width="1200"
    height="675"
    fetchpriority="high"
    alt="Primary product showcase"
  >
</picture>

In the HTML specification, the <picture> element is purely a structural wrapper that provides alternative sources to the contained <img> element. Because the <img> element is what actually requests and renders the selected resource, applying fetchpriority or dimension attributes to <picture> has no effect.

Implementation guardrails: Layout shifts and resource contention

When stripping out lazy-loading markup or refactoring image templates, maintain two technical safeguards to avoid introducing secondary performance regressions:

• Retain explicit dimensions to prevent Cumulative Layout Shift (CLS): Always keep explicit width and height attributes on the <img> element (or define an explicit CSS aspect-ratio ). Some JavaScript lazy loaders rely on wrapper divs with padding-bottom hacks to reserve space before the image loads; if those wrappers are removed during cleanup without restoring native width and height attributes, the browser cannot calculate the image's aspect ratio prior to download, causing the page layout to shift when the image renders.
• Apply fetchpriority="high" selectively: While every image visible in the initial viewport should load eagerly (without loading="lazy" ), fetchpriority="high" should be restricted to the single largest above-the-fold image-the actual LCP candidate. Applying high fetch priority to multiple viewport images (such as a site logo, navigation icons, and a full row of product thumbnails) creates bandwidth contention, diluting priority signals and slowing down the download of the primary LCP asset.

Platform and CMS configuration: WordPress, optimization plugins, and next.js

In many production environments, developers do not write raw HTML image tags by hand. Instead, content management systems, performance plugins, and frontend frameworks generate image markup dynamically-often applying lazy loading globally by default. Preventing above-the-fold lazy loading in these stacks requires configuring framework props, CMS filters, or plugin exclusion rules rather than editing static HTML.

WordPress core

Since WordPress 5.5, core automatically appends loading="lazy" to images generated through standard WordPress APIs. Recognizing the LCP impact of this default behavior, subsequent releases refined the logic: WordPress 5.9 introduced a mechanism to omit loading="lazy" from the very first content image or featured image on a page, and WordPress 6.3 expanded this heuristic to automatically add fetchpriority="high" to the image WordPress estimates is most likely to be the LCP element.

However, WordPress core tracks image order using an internal counter during template rendering. This automatic detection frequently fails in two common theme scenarios:

• The theme renders smaller images (such as a site logo, author avatar, or category icon) via standard attachment functions before rendering the main hero banner, consuming the initial exclusion threshold on a non-LCP asset.
• The hero image is built using a custom page builder block or theme function that bypasses standard loop context, causing WordPress to treat it as a secondary image and apply loading="lazy" .

When a theme template outputs an above-the-fold image directly via wp_get_attachment_image() or the_post_thumbnail() , developers can pass the desired attributes directly in the function arguments to override core heuristics:

echo wp_get_attachment_image( $attachment_id, 'full', false, array(
    'loading'       => false,
    'fetchpriority' => 'high',
) );

Setting 'loading' => false instructs WordPress to omit the loading attribute altogether, restoring default eager behavior.

If the image is rendered inside a third-party block, widget, or parent theme template that cannot be edited directly, use the wp_get_attachment_image_attributes filter in functions.php or a custom plugin to strip loading="lazy" and assign high priority to a specific CSS class or attachment ID:

add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment, $size ) {
    if ( isset( $attr['class'] ) && strpos( $attr['class'], 'hero-banner-img' ) !== false ) {
        unset( $attr['loading'] );
        $attr['fetchpriority'] = 'high';
    }
    return $attr;
}, 10, 3 );

WordPress optimization plugins

Performance and caching plugins-including WP Rocket, Perfmatters, Autoptimize, and FlyingPress-frequently override WordPress core image handling with their own native or JavaScript-based lazy-loading parsers. Even if WordPress core omits loading="lazy" from a hero image, an active optimization plugin may parse the final HTML buffer and rewrite the tag to use data-src or re-inject loading="lazy" .

Most WordPress optimization plugins provide two functional patterns to exclude critical viewport images:

• Threshold-based exclusions (Exclude first N images): Plugins commonly offer a numeric setting that skips lazy loading for the first N images found in the HTML document order. While simple to configure globally, this approach is fragile if headers or mega-menus contain multiple icon or thumbnail <img> tags before the hero image. If a navigation menu contains six small icons and the hero banner is the seventh image in DOM order, setting the threshold to 2 will leave the hero image lazily loaded, whereas setting it to 7 will eagerly load six unnecessary menu images.
• Attribute, class, or filename exclusions: A more reliable method is targeting the specific LCP element using exclusion strings. Most optimization plugins allow administrators to define a list of excluded CSS classes, image filenames, or parent container selectors. In addition, many lazy-loading scripts automatically ignore images that carry specific exclusion classes or attributes-such as skip-lazy , no-lazy , or data-skip-lazy -directly in the markup.

When both WordPress core and an optimization plugin are active, disable lazy loading in one system so two separate parsers do not compete over the same DOM elements, and verify the final rendered HTML in an incognito browser session to confirm the plugin's output buffer has respected the exclusion rule.

Next.js image component

In Next.js applications using the built-in next/image component ( <Image /> ), lazy loading is enabled by default. Any image rendered without explicit configuration receives loading="lazy" automatically.

To configure an above-the-fold LCP image in Next.js, add the documented priority boolean prop to the component:

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/images/hero-product.jpg"
      alt="Primary product showcase"
      width={1200}
      height={630}
      priority
    />
  );
}

When priority (or priority={true} ) is set on next/image , Next.js disables lazy loading, omits loading="lazy" , applies fetchpriority="high" , and generates preload metadata for the responsive image source set so the browser initiates the fetch early in the page lifecycle.

For secondary images visible in the initial viewport that should load eagerly without competing for high fetch priority (such as a brand logo in the header), avoid using priority . Instead, pass loading="eager" directly to the <Image /> component. Note that in Next.js, passing both priority and loading="lazy" simultaneously is invalid configuration and will trigger a build or runtime warning, as the two instructions conflict.

Handling responsive viewports, dynamic templates, and crawling considerations

Static single-image templates rarely represent the full complexity of production websites. Responsive layouts, interactive components, and search engine rendering pipelines introduce specific edge cases when configuring image loading behavior.

Responsive viewport differences

An image that appears above the fold on a desktop monitor may be pushed below the fold on a mobile screen, such as when a two-column hero layout stacks vertically on narrow viewports. Conversely, a compact mobile header may expose a featured image in the initial viewport that sits lower on a desktop layout with a large navigation bar or promotional banner.

Because the HTML loading attribute cannot be toggled via CSS media queries, a single <img> element shares the same loading instruction across all screen sizes. To handle this trade-off:

• Base the loading and fetchpriority attributes on the primary device distribution for that specific template. If mobile traffic accounts for the majority of page views and the image is offscreen on mobile, keeping loading="lazy" avoids consuming mobile bandwidth for an unseen resource, even if desktop users experience a slight delay. If the image is the LCP element on both viewports or desktop traffic predominates, load it eagerly.
• Avoid rendering two separate <img> tags (one for desktop, one for mobile) toggled with CSS display: none . Browsers often fetch images inside hidden containers before layout styles are evaluated, causing unnecessary network requests.
• When a page serves distinct art-directed hero assets for mobile and desktop, use a single <picture> element with media attributes on the child <source> tags and eager loading on the inner <img> element.

If you also use <link rel="preload"> tags in the document <head> to initiate early fetches for responsive hero images, include matching media attributes on the preload links so the browser only preloads the asset matching the active viewport:

<link rel="preload" as="image" href="/images/hero-mobile.webp" media="(max-width: 767px)" fetchpriority="high">
<link rel="preload" as="image" href="/images/hero-desktop.webp" media="(min-width: 768px)" fetchpriority="high">

Without the media constraint on the preload link, the browser downloads the preloaded image regardless of screen size, downloading both files on one device and competing for bandwidth during the initial page load.

Dynamic templates and image carousels

Hero carousels, product galleries, and dynamic sliders located in the initial viewport often contain three to ten high-resolution images inside the same DOM container. Treating all slides identically creates one of two failure modes: lazy loading every slide delays the LCP candidate, while eagerly loading every slide triggers simultaneous downloads of offscreen images that compete for network bandwidth with the primary visible image.

Configure dynamic template loops using index-based conditional logic so the first slide is treated differently from subsequent slides:

• Slide index 0 (initial visible slide): Render with standard src and srcset attributes, omit loading="lazy" (or set loading="eager" ), and apply fetchpriority="high" if the slide is the primary LCP candidate.
• Slide index 1 and higher (initially hidden slides): Apply loading="lazy" and omit fetchpriority="high" .

<!-- Slide 1: Visible in initial viewport -->
<div>
  <img src="/images/slide-1.jpg" alt="Summer collection" width="1200" height="600" fetchpriority="high">
</div>

<!-- Slide 2: Offscreen or hidden until interaction/rotation -->
<div>
  <img src="/images/slide-2.jpg" alt="Autumn collection" width="1200" height="600" loading="lazy">
</div>

Note that if a carousel positions subsequent slides horizontally using CSS overflow or transforms within or immediately adjacent to the initial viewport, the browser's native lazy-loading distance threshold may still trigger an early fetch for the second slide. However, restricting fetchpriority="high" strictly to the first slide ensures the browser prioritizes the visible LCP asset over adjacent slides.

Search engine crawling and indexing considerations

Replacing JavaScript-based lazy loading with standard HTML markup also removes a common indexing failure mode for images. Modern search engine crawlers, including Googlebot, support native loading="lazy" on standard <img> elements because the image URL is present directly in the standard src or srcset attribute in the initial HTML response.

In contrast, JavaScript-dependent lazy loading that stores image URLs in non-standard attributes-such as data-src , data-lazy-src , or data-srcset -without a valid src attribute hides the image URL from the initial HTML parser. Because crawlers generally do not resize viewports or simulate user scroll events during page rendering, intersection-based scripts that wait for an active scroll event to swap data-src into src may never execute during crawling. Furthermore, if JavaScript rendering is deferred, blocked by robots.txt , or encounters execution errors, Googlebot cannot extract the image URL, which can prevent the image from being discovered and indexed in Google Images.

When migrating above-the-fold or below-the-fold images away from JavaScript lazy-loading libraries to standard HTML attributes, verify how Googlebot processes the updated markup using the URL Inspection Tool in Google Search Console:

1. Inspect the updated page URL and run a live test.
2. Open the tested page view and inspect the rendered HTML.
3. Search for the target <img> or <picture> elements and confirm that resolved image URLs populate the standard src or srcset attributes rather than remaining inside data-* attributes or placeholder 1x1 data URIs.

Validating the fix in lab and field data

Confirming that an above-the-fold image is no longer delayed by lazy loading requires testing across two distinct phases: immediate verification in synthetic lab environments and longitudinal monitoring in real-user field data.

Stage 1: Immediate lab verification

Synthetic testing tools evaluate page changes immediately upon deployment. Before running lab tests, purge server, plugin, and CDN caches so the testing browser receives the updated HTML markup rather than a cached response still containing lazy-loading attributes.

Use Chrome DevTools, Lighthouse, or WebPageTest to verify three specific behavioral shifts in how the browser handles the Largest Contentful Paint (LCP) image:

• Early discovery by the preload scanner: In the Network waterfall (in Chrome DevTools or WebPageTest), confirm that the image request is initiated shortly after the main HTML document arrives, in parallel with early CSS and JavaScript files, rather than waiting until external scripts are downloaded and executed.
• High network priority: Enable the Priority column in the Chrome DevTools Network panel. Verify that the primary viewport image is queued at High priority. If fetchpriority="high" was applied to the element, the request should start at High priority immediately rather than starting at Low or Medium and upgrading only after layout calculation.
• Reduced resource load delay: Run a Lighthouse audit or record a trace in the Chrome DevTools Performance panel and inspect the LCP sub-parts. Removing lazy loading specifically targets resource load delay -the time elapsed between Time to First Byte (TTFB) and the moment the browser begins downloading the LCP image. In a properly configured template, resource load delay should be minimal, and the Lighthouse diagnostic audit flagging a lazily loaded LCP image should pass.

Stage 2: Real-World validation in field data

While lab tests confirm that the browser parses and requests the image earlier under controlled conditions, field data verifies how the change affects actual users across diverse devices, viewport sizes, and network connections.

Field validation relies on two primary data sources:

• Real User Monitoring (RUM): If the site collects telemetry using the standard PerformanceObserver API (or the web-vitals JavaScript library), inspect LCP distributions and LCP sub-part timings segmented by release version or deployment date. RUM data provides near-real-time feedback, allowing engineers to verify reductions in resource load delay within hours or days of deployment.
• Chrome User Experience Report (CrUX): Public field data surfaced in PageSpeed Insights ("Discover what your real users are experiencing") and the Core Web Vitals report in Google Search Console is powered by CrUX. Because CrUX metrics represent a 28-day rolling collection period, field LCP improvements do not register in full immediately after deploying a fix. Instead, the 75th percentile LCP score reflects a blend of pre-fix and post-fix user sessions, shifting gradually over four weeks until the historical window fully turns over.

Interpreting Post-Deployment LCP results

Removing lazy loading from an above-the-fold image resolves artificial delays in resource discovery and scheduling, which directly reduces resource load delay and, in the case of JavaScript-based lazy loading, element render delay. However, total LCP duration is the sum of four distinct sub-parts: Time to First Byte (TTFB), resource load delay, resource load duration, and element render delay.

If lab verification confirms that the image request now starts immediately after the HTML document arrives at high priority, the lazy-loading bottleneck is resolved. If the overall LCP metric remains above the 2.5-second threshold after resource load delay is minimized, the remaining latency lies in other sub-parts-typically slow server response times (high TTFB), render-blocking stylesheets delaying paint, or an unoptimized image file size increasing resource load duration.