What Is the LCP Element? How to Find and Optimize It

What Is the LCP Element?

When a performance tool says your page has a slow Largest Contentful Paint (LCP), the next useful question is not simply “How do I improve LCP?” It is: Which element is actually producing the LCP?

That element is called the LCP element. It is often a hero image, but it can also be a heading, a paragraph, a CSS background image, or video content. More importantly, it is not simply the largest DOM element on the page. The browser applies specific eligibility, visibility, and sizing rules when deciding which rendered content becomes an LCP candidate. (web.dev)

Understanding that distinction makes LCP debugging much more precise.

Direct Answer

The LCP element is the content element associated with the page's Largest Contentful Paint: the largest eligible image, text block, or other supported content that the browser has rendered within the viewport during the loading experience.

The element can change while the page loads. For example, a heading may initially be the largest rendered content, then a hero image may become the LCP element once it finishes loading. Browsers therefore track a sequence of LCP candidates rather than assuming one element from the beginning. (web.dev)

INTERNAL LINK: What Is Largest Contentful Paint?

What Can Be an LCP Element?

Not every visible DOM element is eligible for LCP.

Current LCP guidance identifies these main candidate types:

For video, the browser can use the poster image or the video's first presented frame according to the LCP calculation rules. For text, the candidate is generally the block-level element containing the relevant text nodes. (web.dev)

This creates an important practical lesson: the visually largest object you notice is not automatically the LCP element.

A large decorative background, low-information placeholder, invisible element, or unsupported element type may not qualify. Chromium also uses heuristics intended to exclude content that is unlikely to represent meaningful page content. (web.dev)

How Browser Selection Works

Imagine a page with this structure:

<h1>Build Faster Websites</h1>

<img
  src="/hero.webp"
  alt="Website performance dashboard"
>

The browser may render the <h1> first.

At that moment, the heading could become an LCP candidate.

Later, the hero image finishes downloading and appears. If its eligible rendered area is larger than the previous candidate, the <img> becomes the new LCP candidate.

LCP reporting therefore evolves as content appears. A newly rendered element only replaces the previous candidate when it qualifies and is larger according to the LCP sizing rules. (web.dev)

This is why inspecting only the HTML source cannot reliably tell you which element produced LCP.

How LCP Size Is Calculated

The browser does not simply calculate:

CSS width × CSS height

and choose the biggest number.

LCP primarily considers the portion of eligible content that is actually visible within the viewport. Content extending beyond the viewport or clipped from view does not fully contribute to its LCP size. For images resized beyond their intrinsic dimensions, the calculation also prevents enlargement from artificially producing an oversized LCP candidate. (web.dev)

For text, the browser considers the rectangle containing the relevant text rather than treating the entire CSS box—including margins, borders, or padding—as content.

That means a huge <div> containing a small sentence does not automatically become LCP merely because the <div> itself fills the screen.

The LCP Element Can Change

A common misconception is that every URL has one fixed LCP element.

It does not.

Even the same page can produce different LCP elements for different visits because viewport dimensions, responsive layouts, personalization, initial scroll position, and visible content can differ between users. Field debugging guidance from web.dev explicitly warns against assuming a single element will always be the LCP candidate for a page. (web.dev)

Consider a responsive homepage:

Desktop:
large hero image → LCP

Mobile:
large heading → LCP

Both results can be correct.

This is one reason laboratory testing and real-user data should complement each other rather than be treated as interchangeable.

How to Find the LCP Element

Chrome DevTools

Record a page load in Chrome DevTools' Performance panel.

Chrome surfaces an LCP marker in the performance timeline. Selecting it provides details about the LCP event and helps investigate the element and the timing components responsible for the delay. Current DevTools guidance also breaks LCP into TTFB, resource load delay, resource load time, and element render delay where applicable. (developer.chrome.com)

This is usually the fastest method for debugging a specific page locally.

JavaScript

The Largest Contentful Paint API also exposes the candidate element.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const latest = entries[entries.length - 1];

  console.log("LCP element:", latest.element);
  console.log("LCP time:", latest.startTime);
  console.log("LCP size:", latest.size);
});

observer.observe({
  type: "largest-contentful-paint",
  buffered: true,
});

LargestContentfulPaint.element references the associated DOM element, while the performance entry also exposes information such as its size and timing. (developer.mozilla.org)

For production Real User Monitoring, however, calculating the final LCP metric correctly involves more edge cases than simply taking an arbitrary observer entry. web.dev recommends using tooling such as the web-vitals library where appropriate because it handles several metric-specific details. (web.dev)

Why the Element Matters

Knowing that your LCP is 4 seconds tells you there is a loading-performance problem.

Knowing the LCP element tells you what loading path to investigate.

If the LCP element is an image, investigate when the image becomes discoverable, its loading priority, transfer time, decoding, and whether rendering waits on other work.

If it is text, the issue may involve server response time, render-blocking CSS, web fonts, or JavaScript delaying the text's appearance.

If JavaScript creates the LCP element after hydration or another client-side process, resource compression alone may accomplish little—the larger problem may be that the browser discovers or renders the content too late. Google's LCP optimization guidance specifically separates these delays because improving one component does not necessarily improve the final LCP if another remains the bottleneck. (web.dev)

INTERNAL LINK: How to Optimize Largest Contentful Paint

LCP Element vs LCP Resource

These terms are related, but they are not identical.

The LCP element is the rendered content element—for example:

<img src="/hero.webp" alt="">

The LCP resource is the external resource required to render it:

/hero.webp

An image-based LCP usually has an LCP resource.

A text-based LCP using a system font may not require a separate LCP resource at all. Chrome's LCP timing breakdown therefore omits resource-loading phases when there is no resource to load. (developer.chrome.com)

This distinction prevents a common debugging mistake: searching for an image optimization problem when the LCP delay is actually caused by rendering.

Common Misconceptions

“The hero image is always the LCP element.” No. It is common, but the browser determines the actual candidate from rendered eligible content.

“The biggest DOM node becomes LCP.” No. LCP uses content-specific eligibility and visual sizing rules rather than raw DOM dimensions. (web.dev)

“My page has one permanent LCP element.” Not necessarily. The candidate may differ by viewport, user, content, and page-load conditions. (web.dev)

“Optimizing the LCP image file always fixes LCP.” No. Resource discovery, TTFB, render-blocking work, JavaScript, and element render delay can all dominate the final result. (web.dev)

SeoNest Recommendation

Start every LCP investigation by identifying the actual element before changing code.

Then classify the bottleneck:

element → required resource → discovery → loading → rendering

For an image LCP, make sure the browser can discover important above-the-fold resources early. Avoid unnecessarily lazy-loading the LCP image, and investigate resource priority or preloading when the normal loading path discovers it too late. For text LCP, focus more heavily on HTML delivery, critical CSS, fonts, and rendering dependencies. (web.dev)

Finally, verify the change using both lab diagnostics and real-user data when sufficient field data is available. LCP is a Core Web Vital, and Google currently recommends an LCP of 2.5 seconds or less at the 75th percentile, evaluated separately across mobile and desktop experiences. (web.dev)

FAQ

Is the LCP element always an image?

No. Images are common LCP candidates, but text blocks, supported CSS background images, and video content can also become LCP.

Can an H1 be the LCP element?

Yes. If the heading forms the largest eligible rendered text block during the relevant loading period, it can become the LCP element.

Can a CSS background image be LCP?

Yes, an image loaded through CSS url() can qualify. A CSS-generated gradient itself is not an LCP image candidate. (web.dev)

Can the LCP element change during loading?

Yes. Browsers can emit multiple LCP candidates as progressively larger eligible content renders.

Does the LCP element directly affect SEO?

LCP is one of Google's Core Web Vitals, and Google documents that Core Web Vitals are used by its ranking systems. However, good Core Web Vitals do not guarantee high rankings, and Google explicitly advises considering page experience holistically rather than treating a single metric as an isolated ranking formula. (developers.google.com)

Final Takeaway

The LCP element is the largest eligible piece of rendered content the browser identifies during the loading experience, not simply the largest HTML element.

Finding that element turns LCP from an abstract score into a concrete engineering problem. Once you know whether the candidate is an image, text block, background image, or other supported content, you can trace what delayed its discovery, loading, and rendering—and optimize the part of the loading path that actually matters.

Sources

1. W3C Web Performance Working Group — Largest Contentful Paint, Working Draft, July 13, 2026. (w3.org) W3C specification
2. Philip Walton and Barry Pollard — Largest Contentful Paint (LCP), web.dev, updated September 4, 2025. (web.dev) web.dev LCP documentation
3. Philip Walton and Barry Pollard — Optimize Largest Contentful Paint, web.dev, updated March 31, 2025. (web.dev) LCP optimization guide
4. Chrome for Developers — Performance Insights, Chrome DevTools documentation. (developer.chrome.com) Chrome DevTools performance documentation
5. web.dev — Debug Performance in the Field, guidance on identifying real-user LCP candidates. (web.dev) Field performance debugging guide
6. MDN Web Docs — LargestContentfulPaint: element property. (developer.mozilla.org) MDN LargestContentfulPaint.element
7. Google Search Central — Understanding Core Web Vitals and Google Search results, updated December 10, 2025. (developers.google.com) Google Search Central Core Web Vitals documentation