LCP Subparts: Breaking Down The Slowest Paint

Largest Contentful Paint (LCP) has long been a frustrating metric to optimize because it bundles several distinct delays into one number. If your LCP is slow, it’s not obvious whether the problem is server response time, image loading, or something on the client side. Google’s newer LCP subparts split the metric into four phases, and with the recent addition of subpart data to the Chrome UX Report, you can now see for real visitors where the time actually goes.

The Four Components Of LCP

LCP subparts divide the metric into these stages:

  1. Time to First Byte (TTFB): Server response time for the document request.
  2. Resource Load Delay: Time before the LCP image request starts.
  3. Resource Load Time: Time spent downloading the LCP image.
  4. Element Render Delay: Time after the image arrives before the element is painted.

The load delay and load time components only apply when the LCP element is an image or background image. For text-based LCP elements, those two subparts are always zero.

Measuring And Visualizing Subparts

A lab-based tool like DebugBear's website speed test can show how much each subpart contributes to the total LCP. In a typical waterfall view, you'll often see that TTFB and image load time dominate the entire score, accounting for more than three-quarters of the delay.

The LCP Image Discovery view narrows the waterfall to just the requests that matter for displaying the LCP image. Depending on the page setup, each LCP stage may contain a single request, or you may see additional resources entering the critical path.

Time To First Byte

The first delay is fetching the HTML document itself. Connection setup is rarely the issue; the majority of the TTFB is spent waiting for the server to generate the HTML. Speeding up that server-side generation, or caching the HTML output to avoid generating it per request, is the direct fix for a slow TTFB.

Resource Load Delay

The ideal loading path is a simple <img> tag near the top of the HTML, letting the browser discover and fetch the image immediately. A resource load delay means something is getting in the way of that immediate start.

A common culprit is a lazy-loading JavaScript library. The browser must download the library, complete layout, and render the first content before the library detects that the image is in the viewport and triggers its request. The LCP image request is then blocked behind that entire sequence.

Two optimizations fix this. First, switch from a lazy-loading library to the native loading="lazy" attribute, which removes the JavaScript dependency. Better yet, don't lazy-load the LCP image at all — otherwise the browser can't initiate the fetch until after the HTML is fully parsed. Google's guidance is to eliminate resource load delay entirely.

Resource Load Time

This subpart is the most intuitive: the image must be downloaded before it can be displayed. Keeping the image on the same domain as the HTML avoids the cost of a new connection. Other levers here include switching to a more efficient modern image format, serving responsive images at the displayed size, and deprioritizing other resources that compete with the LCP image for bandwidth.

Element Render Delay

Render delay is the least intuitive subpart. Everything is loaded, yet the browser isn't ready to paint. For text-based LCP elements, render-blocking scripts and stylesheets are the usual cause, since text can't appear until those finish and the browser completes rendering.

Interestingly, render delay can also increase after a good optimization. Preloading the LCP image eliminates load delay and fetches the image earlier, but if the image finishes downloading before the page can render, that time gets shifted into the render delay subpart. The LCP score improves overall, but the bottleneck photograph simply moves to the next stage.

Field Data: LCP Subparts In CrUX

Lab tests don't always reflect real-user conditions. In February 2025 Google began publishing LCP subpart data in the CrUX report, though it's not yet shown in PageSpeed Insights. Third-party tools like DebugBear's Web Vitals tab surface these metrics.

One especially useful piece of field data is the LCP resource type, showing whether visitors saw a text or image LCP element. That detail matters because different visitors to the same URL can get a different LCP element based on viewport size, cookie banners, or other content differences. Google only reports subpart data for image LCP elements. If the LCP element is text for most of your visitors, the subpart breakdown won't apply to them. But a text LCP is easier to analyze: everything beyond TTFB is render-delay.

Monitoring Subparts With Real-User Data

CrUX data has its own limitations — it covers only high-traffic pages and updates slowly, taking about four weeks to reflect a deployed change. For tracking subpart scores across all pages and reviewing individual visitor experiences, a real-user monitoring tool can provide dedicated dashboards for each component and a per-visit waterfall showing the LCP image and its timing breakdown.

Granular LCP data, both in the lab and in the field, makes it far easier to prioritize work and confirm that an optimization actually targets what's slowing down the largest content element for your users.