LCP Subparts

Largest Contentful Paint (LCP) can be analyzed as four timing components: time to first byte, resource load delay, resource load duration, and render delay. Breaking LCP apart helps identify whether the bottleneck is server response, resource discovery, downloading, or final rendering.

LCP measures when the largest qualifying content element becomes rendered in the viewport. For an image-based LCP, the overall time can be understood as a sequence from the initial document response through discovery and downloading of the LCP resource, followed by the browser's work to render it.

Time to first byte (TTFB) covers the interval from navigation initiation until the first response byte arrives. It is primarily influenced by connection setup, network latency, server processing, redirects, and caching behavior. A high TTFB delays everything that follows.

Resource load delay is the time between receiving the initial HTML and the browser starting to fetch the resource responsible for LCP. Large delays often indicate that the browser discovers the LCP resource late, for example because it is hidden behind client-side rendering, JavaScript execution, or inefficient markup.

Resource load duration is the time spent downloading the LCP resource after its request begins. Resource size, network throughput, compression, caching, and request prioritization can affect this phase. For an LCP that is text rather than an image, the corresponding loading contribution can be small or absent.

Render delay is the interval after the LCP resource has finished loading until the browser actually presents the LCP element. Long render delay can result from main-thread JavaScript, CSS processing, layout, rendering work, or other tasks that prevent the element from being painted promptly. Looking at all four phases helps distinguish network problems from browser-side rendering problems.

Key points

• LCP can be decomposed into TTFB, resource load delay, resource load duration, and render delay.
• High TTFB delays discovery and loading of subsequent resources.
• Resource load delay often reveals late discovery of the LCP resource.
• Resource load duration is dominated by the resource's transfer and network conditions.
• Render delay points toward browser-side work after the resource is available.

Interview questions

What are the four main LCP subparts?

The four commonly used components are TTFB, resource load delay, resource load duration, and render delay. TTFB measures how long it takes before the initial response starts arriving. Load delay covers late discovery or scheduling of the LCP resource, while load duration covers its transfer. Render delay is the remaining time before the browser actually presents the LCP element.

If LCP is poor but the LCP image downloads quickly, what would you investigate?

I would inspect TTFB, resource load delay, and render delay rather than focusing only on image transfer. If the request starts late, I would determine why the browser did not discover or prioritize the image earlier. If the image finishes downloading early but LCP occurs much later, I would investigate main-thread activity, CSS, layout, and rendering work. A performance trace can help establish which interval dominates.

How would you reduce LCP resource load delay?

The goal is to let the browser discover the LCP resource as early as possible and give it appropriate priority. For an important image, that can mean placing it directly in the initial HTML rather than requiring client-side JavaScript to reveal it. Appropriate preload or fetch-priority mechanisms can also help in suitable cases. The exact optimization should be validated with a trace because unnecessary preloading can compete with other critical resources.

What does a large render delay tell you about an LCP problem?

A large render delay means the LCP resource or content is available, but presentation is being postponed. I would inspect the main-thread timeline for long JavaScript tasks, style and layout work, and other operations competing with rendering. I would also check whether the LCP element is intentionally hidden or delayed by application logic. The optimization should target the blocking work rather than simply making the resource download faster.

How would you diagnose an LCP regression after a frontend deployment?

I would first compare the four LCP components before and after the deployment. A change in TTFB may indicate infrastructure or response changes, whereas increased load delay can indicate altered markup, resource discovery, or prioritization. Increased load duration may reflect a larger or less cacheable resource, while increased render delay often points to new JavaScript, CSS, or rendering work. I would combine field measurements with a representative browser trace to identify the changed part of the critical path.