Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) measures how quickly the largest content element visible in the initial viewport becomes rendered. It is a Core Web Vital used to represent perceived loading performance.

LCP identifies the largest qualifying image, text block, or other content element visible in the viewport during page loading. The browser records the render time of the current largest candidate and may update that candidate as more content appears.

For practical frontend work, LCP is usually affected by the time required to obtain the HTML, discover critical resources, download them, and render the final element. Common contributors include slow server response, render-blocking CSS or JavaScript, late discovery of images, and expensive rendering work.

A useful debugging approach is to determine which element became the LCP element and then separate the delay into phases such as server response, resource loading, and rendering. Optimizing an unrelated asset may have little effect if it does not influence the actual LCP candidate.

LCP is measured in real browsers and can differ substantially between laboratory tests and real users. For field data, factors such as device capability, network conditions, caching, and geographic distribution can change the observed result.

Key points

• LCP focuses on the largest qualifying content element visible in the initial viewport.
• The LCP candidate can change while the page continues loading.
• Images, text blocks, and other rendered content can become LCP candidates.
• Slow server responses, resource discovery, downloads, and rendering can all delay LCP.
• Debug the actual LCP element before choosing an optimization.

Interview questions

What is Largest Contentful Paint?

LCP is a Core Web Vital that measures when the largest qualifying content element visible in the viewport is rendered. Typical candidates include prominent images and text blocks. It is intended to approximate when the main content of a page becomes visible to the user.

What can cause a poor LCP score?

A slow server response can delay the point at which the browser receives the page. Critical resources such as CSS, JavaScript, and the LCP image can also be discovered or downloaded too late. Rendering work on the main thread can further delay when the element is painted.

How would you debug a page with poor LCP?

I would first identify the actual LCP element using browser performance tooling or field diagnostics. Then I would inspect the timeline to determine whether the delay comes primarily from server response, resource discovery and loading, or rendering. For an image candidate, I would check whether it is discovered early, appropriately sized, efficiently encoded, and loaded with suitable priority. Finally, I would validate the change using both controlled tests and real-user measurements when available.

Why might an LCP image load late even though it is visible immediately?

The browser may not discover the image until it has processed other resources or client-side markup. CSS backgrounds and JavaScript-inserted images can therefore have different discovery behavior from an image directly available in the initial HTML. Improving early discovery and avoiding unnecessary dependency chains can reduce the delay. The exact fix should be based on the resource waterfall and the actual LCP element.

Why should frontend engineers distinguish LCP from total page load time?

LCP targets a user-visible loading milestone rather than the completion of every resource on the page. A page can continue downloading analytics, secondary images, or other noncritical assets after its main content has appeared. Conversely, a page can finish many background tasks quickly while its primary visible content remains delayed. Optimizing LCP therefore requires focusing on the critical path for the actual LCP candidate.