What Is LCP and How to Fix It

Largest Contentful Paint (LCP) measures when the largest eligible image, text block, or video poster visible in the initial viewport finishes rendering. It is one of the three Core Web Vitals, alongside Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

Google classifies an LCP of 2.5 seconds or less as good, more than 2.5 seconds through 4 seconds as needing improvement, and more than 4 seconds as poor. Evaluate the 75th percentile separately for mobile and desktop rather than judging a page by its fastest visit.

Improving LCP starts with identifying the actual LCP element and the phase consuming the time. Compressing every image is not a complete diagnosis.

What LCP measures

Eligible candidates include images loaded through <img>, poster images for <video>, text-containing block elements, and some CSS background images. The browser reports the largest candidate seen so far, so the LCP element can change while the page loads. An image may also be downloaded before it is painted if CSS, JavaScript, a font, or an animation keeps it hidden.

LCP is concerned with loading experience. It does not tell you whether the page remains visually stable or responds quickly after it appears. Read it with the other Core Web Vitals, and treat the Lighthouse performance score as a diagnostic summary rather than the goal itself.

How to measure LCP correctly

PageSpeed Insights can show two distinct views:

• Chrome UX Report field data describes eligible real Chrome visits over a rolling 28-day period.
• Lighthouse lab data is one simulated load that helps reproduce a problem and inspect diagnostics.

Field data should guide the outcome; lab data and traces should guide the investigation. Test the exact page template that matters because the home page, product page, article, and authenticated application can have different LCP elements.

In Chrome DevTools, record a Performance trace with a cold cache and inspect the LCP marker. Note the element, its resource URL, request start, response timing, and paint time. Repeat under equivalent conditions. A single run can move because of server load, network routing, cache state, or third-party responses.

Use IndieTools Speed to follow measured page performance over time, but keep release annotations so a change in the chart can be connected to a deploy, campaign, or content update.

Break LCP into four phases

Google's LCP optimization guidance divides the metric into four parts:

1. Time to First Byte: navigation start until the first byte of HTML arrives.
2. Resource load delay: first byte of HTML until the LCP resource request begins.
3. Resource load duration: the time required to transfer the LCP resource.
4. Element render delay: resource completion until the element is painted.

For a text LCP element there may be no separate image request, but server, font, stylesheet, and rendering delays still matter. Compare phases instead of applying a universal millisecond budget. The largest phase usually identifies the first useful intervention.

Reduce Time to First Byte

No browser optimization can recover time spent waiting for the document. If TTFB dominates:

• inspect application traces and slow database or upstream requests;
• cache public HTML where its freshness rules allow it;
• avoid serial server-side requests needed only for secondary content;
• place compute and cached content near the audience;
• reuse connections and avoid unnecessary redirects;
• measure authenticated and uncached routes separately from public cached pages.

Do not hide a server delay by moving essential content into client-side JavaScript. That may make HTML arrive sooner while delaying resource discovery and meaningful rendering.

Make the LCP resource discoverable

An image in the initial HTML can be discovered earlier than one inserted after hydration or referenced only by late CSS. For a likely LCP image:

• render it in the server-generated markup;
• do not apply loading="lazy";
• provide responsive srcset and an accurate sizes value;
• use fetchpriority="high" selectively when the browser would otherwise give it the wrong priority;
• preload it only when it is genuinely late-discovered.

<img
  src="/images/launch-hero-1280.avif"
  srcset="/images/launch-hero-640.avif 640w,
          /images/launch-hero-1280.avif 1280w"
  sizes="100vw"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="Product dashboard showing the launch timeline"
>

Do not mark several images high priority. Competing high-priority downloads can delay the real LCP resource. Confirm the request order in the Network panel after changing priorities.

Shorten resource load time

Serve an image close to its rendered dimensions instead of asking a narrow mobile viewport to download a desktop original. Use an appropriate modern format and a quality setting that preserves the subject. Responsive variants usually matter more than converting one oversized file to a new extension.

Keep the image URL stable and cacheable. A CDN can reduce distance and origin work, but it cannot correct an unnecessarily large source or an inaccurate sizes attribute. Inspect the transferred bytes on representative mobile and desktop viewports.

For a video poster, optimize the poster as a first-class image. Loading the complete video early is rarely necessary for rendering its initial poster and can compete with critical resources.

Remove element render delay

When the resource finishes early but LCP occurs much later, investigate the main thread and presentation path:

• remove reveal animations that begin with the hero invisible;
• reduce render-blocking CSS to what the initial view needs;
• defer unrelated scripts without breaking their dependency order;
• split long JavaScript tasks and avoid synchronous work during startup;
• render essential copy and media on the server where practical;
• avoid waiting for a carousel or component library to initialize before showing the first slide.

The First Contentful Paint guide is useful when the whole page starts late. If FCP is early but LCP is late, focus on the LCP resource and its render path instead of broad changes.

Handle text and client-rendered LCP elements

A large heading can become the LCP element. If a web font delays it, preload only the required font file when appropriate, serve WOFF2, limit variants, and choose a font-display strategy that matches the design. A fallback font can paint sooner, but large metric differences between fallback and final fonts may introduce layout shift.

For client-rendered applications, inspect the initial response. If the principal content is absent until JavaScript fetches data and hydrates the page, the browser cannot paint it early. Server rendering or static generation can make the main content and its image URL discoverable sooner. Keep client-side code for behavior that actually needs it.

Validate the result

After each change:

1. Run several equivalent Lighthouse tests and compare the LCP phase breakdown.
2. Inspect a DevTools trace to confirm the intended request starts earlier or renders sooner.
3. Test narrow and wide viewports, cold and warm caches, and an ordinary mobile device.
4. Check CLS and interaction behavior for regressions.
5. Monitor field LCP after enough real visits enter the reporting window.

A lab improvement is evidence that the change affects the tested conditions. The production result is confirmed when representative field data improves without sacrificing usability, image quality, or another Core Web Vital.

Google's current LCP reference remains the authoritative definition and threshold source. Use it when browser behavior or eligible element rules change.