What Is LCP? Largest Contentful Paint Explained

What is LCP? Largest Contentful Paint (LCP) is a Core Web Vitals metric that measures how long it takes for the largest qualifying image, text block, video poster, or other eligible content element in the visible viewport to render. A good LCP result is 2.5 seconds or less, measured at the 75th percentile of page visits and assessed separately for mobile and desktop. This guide explains how LCP works, which elements can determine the metric, why it becomes slow, and how to diagnose and fix the underlying performance problems.

The page may technically be loading during that time, but users do not experience the loading process as a collection of network requests. They see a screen gradually become useful.

Largest Contentful Paint (LCP) is designed to measure an important part of that experience: when the largest piece of visible content in the initial viewport has been rendered.

That sounds straightforward until you start investigating a slow result.

A page can have a small HTML document and still have a poor LCP. An image can be compressed perfectly and still arrive too late. A fast server can still produce a slow LCP if the browser does not discover the important resource quickly enough. And sometimes the LCP element is not an image at all.

Understanding those differences is what makes LCP useful.

Quick Answer: What Is LCP?

Largest Contentful Paint is a Core Web Vital that measures how quickly the largest visible content element in the initial viewport is rendered.

The LCP element is commonly:

• A large image
• A prominent image inside a hero section
• A large block of text
• A poster image or first frame associated with video
• Another qualifying large content element visible in the viewport

For a good LCP experience, the 75th percentile of page visits should have an LCP of 2.5 seconds or less.

The current thresholds are:

LCP	Assessment
2.5 seconds or less	Good
More than 2.5 seconds up to 4 seconds	Needs improvement
More than 4 seconds	Poor

LCP is measured from the beginning of the page navigation to the point at which the browser renders the relevant largest content element.

It is therefore not simply a measurement of “how long the website takes to load.”

That distinction is important.

Why Does LCP Exist?

Traditional page-load measurements often describe what the browser is doing rather than what the visitor is experiencing.

A browser might finish downloading several resources while the main heading, product image, article hero image, or other important content is still waiting to appear.

From a technical perspective, the page is making progress.

From the visitor’s perspective, it may still look empty.

LCP tries to put a number around the moment when the page’s main visible content has appeared.

This is why LCP is considered a user-centric performance metric. It is concerned with perceived loading speed rather than simply counting network activity.

A useful example is an article page.

Suppose the HTML arrives quickly. The navigation and footer are already rendered. Several small icons load. Analytics scripts execute.

But the large article title and hero image do not appear until 3.8 seconds after navigation.

The page may have been doing plenty of work before that point. The visitor is still waiting for the part of the page that makes it feel useful.

That is the problem LCP helps expose.

What Does LCP Actually Measure?

LCP looks at qualifying content that is visible within the viewport and identifies the largest candidate that has been rendered.

The important word here is candidate.

LCP does not simply look at the biggest file downloaded by the browser.

A 500 KB image somewhere below the fold is not automatically the LCP.

Likewise, a tiny logo may be downloaded before everything else but have no meaningful effect on the LCP measurement.

The measurement is concerned with the visual content that matters in the initial viewport.

Consider a typical article page:

• Logo at the top
• Navigation menu
• Large article heading
• Featured image
• Paragraph of introductory text
• Related content further down

If the featured image occupies the largest qualifying area in the initial viewport, it may become the LCP element.

If the image is not available quickly enough, however, the browser may initially render a large text block instead. The LCP candidate can change during loading.

That is one reason LCP debugging sometimes produces surprising results.

What Can Become the LCP Element?

The most common LCP candidates fall into a few categories.

Large Images

Images are extremely common LCP elements, particularly on:

• News sites
• Blogs
• Ecommerce pages
• Photography websites
• Landing pages
• Magazine-style websites
• Portfolio sites

A hero image or featured image is often the largest visual element visible when the page first opens.

The important point is that image file size is only one part of the problem.

A 150 KB image can still produce poor LCP if the browser discovers it late.

Conversely, reducing a 2 MB image to 200 KB can produce a significant improvement if image transfer time was the dominant bottleneck.

The job is to determine which problem you actually have.

Large Text Blocks

LCP is not an image-only metric.

A large heading, paragraph, or other text block can become the LCP element.

This matters because an LCP problem involving text may have little to do with image optimization.

The browser may be waiting for:

• HTML
• CSS
• Web fonts
• JavaScript
• Server response
• Rendering work

before the text can be painted.

Trying to solve such a problem by compressing images would obviously miss the cause.

Video Poster or First Frame

Video-related content can also participate in LCP measurement.

For example, a large video area near the top of a page may contribute to LCP through its visual representation.

This is one reason it is better to identify the actual LCP element before deciding what to optimize.

LCP Is Not the Same as Page Load Time

This is one of the most common misunderstandings.

A web page does not have one universal moment called “loaded.”

Modern pages continue doing work after the initial content appears.

JavaScript may continue executing. Analytics may send data. Images below the fold may continue downloading. Third-party widgets may initialize. Fonts may be requested.

None of that means the page’s LCP must keep increasing.

LCP is concerned with when the relevant largest content has been rendered.

For example:

Navigation starts: 0 ms
HTML begins arriving: 300 ms
Main CSS arrives: 650 ms
Hero image request starts: 900 ms
Hero image finishes downloading: 2,100 ms
Hero image is rendered: 2,250 ms
Other page resources finish: 4,000 ms

The LCP may be approximately 2.25 seconds even though the page continues loading until 4 seconds.

That is perfectly possible.

The 2.5-Second LCP Target

Google’s current Core Web Vitals guidance classifies LCP like this:

Result	LCP
Good	≤ 2.5s
Needs improvement	> 2.5s and ≤ 4s
Poor	> 4s

But there is another part of the definition that is easy to miss.

Core Web Vitals are evaluated using the 75th percentile of visits.

That means you should not look at one test and conclude that the page is “good” because it produced 1.8 seconds.

A single test is a sample.

Real users may have different:

• Devices
• Network connections
• Geographic locations
• Browser versions
• CPU performance
• Cache states
• Screen sizes
• Interaction patterns

A page that produces a 1.8-second LCP on a powerful desktop connection can behave very differently for someone using a slower mobile connection.

For that reason, field data becomes particularly valuable when evaluating whether users are consistently receiving a good experience.

Field Data vs. Lab Data for LCP

There are two broad ways you will encounter LCP data.

Field Data

Field data comes from real user experiences.

It can reveal patterns that a controlled test cannot.

For example, you might discover that your desktop tests consistently produce an LCP below 2 seconds while a substantial portion of mobile visitors experience 4-second LCP.

That is not necessarily a contradiction.

The tests are simply measuring different conditions.

Field data is especially useful for answering:

“What are my actual visitors experiencing?”

Lab Data

Lab testing is performed under controlled conditions.

Tools such as Lighthouse can load a page using a defined testing environment and report performance metrics.

Lab testing is useful because it makes investigation much easier.

You can change something, run the page again, inspect the waterfall, and compare the result.

It answers a different question:

“What is happening under this particular test configuration, and where should I investigate?”

The strongest performance workflow uses both rather than treating them as competing measurements.

Why Is My LCP Slow?

A poor LCP result usually has a cause somewhere in the loading and rendering chain.

For an image LCP, a useful way to think about the process is:

Server response → resource discovery → resource request → resource download → rendering

Each stage can introduce delay.

This is why simply saying “compress your images” is such an incomplete LCP recommendation.

Slow Server Response

Before the browser can discover much of the page, it needs the initial response.

If the server takes 1.5 seconds before delivering the document, there is already a substantial delay before the browser can begin discovering important resources.

Common contributors include:

• Slow hosting
• Poor backend performance
• Database queries
• Server-side rendering work
• Missing or ineffective caching
• High network latency

This is where TTFB becomes relevant.

A high TTFB does not automatically mean LCP will be poor, but it can consume a significant part of the time available for achieving a fast LCP.

Late Discovery of the LCP Resource

Imagine that your hero image is 200 KB.

You might assume that 200 KB is small enough.

But what if the browser cannot discover the image until several other resources have been processed?

The image might not begin downloading until 1.5 seconds after navigation.

Even a relatively small image can then arrive too late.

This is a resource discovery problem, not necessarily an image compression problem.

The LCP Image Is Too Large

Now consider the opposite situation.

The browser discovers the hero image immediately, but the file is several megabytes.

The request starts early, but the download takes too long.

Here, reducing the image’s dimensions, choosing an efficient format, or delivering an appropriately sized responsive image can help.

The key is to distinguish this from late discovery.

Render-Blocking CSS

CSS can delay the point at which content becomes visually usable.

The browser needs enough information about styles and layout to render the page correctly.

Large or unnecessarily complicated CSS can therefore become part of the LCP problem.

This does not mean “remove all CSS.”

It means identifying CSS that genuinely blocks the critical rendering path and reducing unnecessary work.

JavaScript Blocking the Main Thread

JavaScript can also interfere with rendering.

If the browser’s main thread is occupied with expensive JavaScript work, an element may have been downloaded already but still fail to appear promptly.

This creates an important distinction:

The resource can be available before it is actually painted.

Reducing JavaScript execution, splitting large tasks, delaying non-critical scripts, and removing unnecessary third-party code can therefore improve LCP in some situations.

But again, do not apply these fixes blindly.

A page with a 4-second image download does not become fast simply because you removed a JavaScript library.

The Four Parts of an Image LCP

For image-based LCP, modern performance diagnostics can be particularly useful when the overall number does not immediately tell you what to fix.

An image LCP can be thought of in four broad stages:

1. Time to First Byte

How long it takes before the initial server response begins arriving.

2. Resource Load Delay

The time between receiving enough information to discover the LCP resource and actually starting its request.

A late-discovered image often shows up here.

3. Resource Load Duration

The time required to download the resource.

This is where large files, slow connections, or inefficient delivery can become visible.

4. Element Render Delay

The delay between the resource being available and the browser actually rendering the LCP element.

This can point toward rendering, CSS, JavaScript, or other browser-side work.

These stages are useful because they turn a vague statement—

“LCP is 4 seconds”

—into a much more actionable question:

“Where did those four seconds go?”

That is the question you should ask during an optimization project.

How to Find the LCP Element

Before changing anything, identify the element.

In Chrome-based developer tools, performance diagnostics can help reveal which element was recorded as the LCP candidate.

PageSpeed Insights can also report the LCP element for the page being tested.

Suppose the report identifies:

<img class=”hero-image” …>

Now you have something concrete to investigate.

You can ask:

• When was this image discovered?
• When did its request start?
• How large is the file?
• Is the delivered image appropriately sized?
• Is it being loaded with the correct priority?
• Is CSS hiding or delaying it?
• Is JavaScript involved in inserting it?
• Is a third-party system serving it?
• Is the server response already consuming too much time?

Without identifying the element, optimization becomes guesswork.

How to Improve LCP

There is no universal LCP fix.

The right improvement depends on the bottleneck.

Improve the Initial Server Response

If the server is consistently slow, investigate the infrastructure before spending hours optimizing images.

Depending on the site, useful improvements can include:

• Full-page caching
• Better server-side caching
• Faster hosting
• Database optimization
• Efficient server-side rendering
• CDN usage
• Reducing unnecessary backend work

A faster server gives the browser an earlier starting point.

Make the LCP Resource Discoverable Early

If the LCP is an image, make sure the browser can discover it without unnecessary obstacles.

Be cautious with architectures where important visual content only becomes discoverable after JavaScript executes.

If the browser has to download JavaScript before it even learns that the hero image exists, the image has already lost valuable time.

Deliver the Right Image Size

Do not send a huge desktop image to a small mobile viewport simply because the CMS made it convenient.

Use appropriately sized responsive images.

For example:

<img

  src=”hero-1280.webp”

  srcset=”

    hero-640.webp 640w,

    hero-960.webp 960w,

    hero-1280.webp 1280w”

  sizes=”100vw”

  width=”1280″

  height=”720″

  alt=”Example hero image”>

The exact values depend on the design and layout.

The principle is simple:

deliver an image appropriate for the size the visitor actually needs.

Use Efficient Image Formats

Modern image formats can reduce transfer size while maintaining good visual quality.

But format selection should not become a checkbox exercise.

A smaller file is useful only if the browser can discover and render it in time.

A highly compressed image that is requested two seconds late may still produce a poor LCP.

Avoid Lazy-Loading the LCP Image

Lazy loading is useful for content that is below the initial viewport.

It is usually the wrong strategy for an image that is itself the primary above-the-fold content.

If the browser is told to wait before fetching the image that determines LCP, you have introduced an unnecessary delay into the critical path.

The exact behavior depends on the implementation and browser, so inspect the actual request rather than assuming a setting is helping.

Keep Critical CSS Manageable

The browser needs CSS to understand how content should be displayed.

Large amounts of unnecessary CSS can delay rendering.

Look for:

• Unused CSS
• Excessive framework styles
• Large stylesheet dependencies
• CSS loaded before it is needed
• Components that ship styles for features never used on the page

Do not remove styles simply to make a report look better. The goal is to reduce work without breaking the page.

Reduce Main-Thread Work

If the LCP resource has already arrived but the page still waits before painting it, investigate browser-side work.

Potential causes include:

• Large JavaScript bundles
• Long-running tasks
• Expensive DOM manipulation
• Third-party scripts
• Heavy client-side rendering

The fix is usually not “remove JavaScript.”

The useful question is:

What JavaScript is occupying the main thread before the user gets the main content?

That leads to much better decisions.

A Practical LCP Diagnosis Example

Consider a blog post with a large featured image.

A PageSpeed test reports:

LCP: 4.2 seconds

The first instinct might be to compress the image.

You inspect the image and discover that it is already only 110 KB.

So why is LCP still poor?

Looking at the loading sequence reveals:

• Server response takes 1.1 seconds.
• The HTML arrives.
• Several stylesheets are processed.
• A JavaScript-driven component initializes.
• Only then does the browser discover the featured image.
• The image downloads quickly once requested.
• The image renders shortly afterward.

The 110 KB image was not the main problem.

The problem was late discovery.

Now consider another page.

Its LCP is also 4.2 seconds.

This time:

• Server response is fast.
• The hero image is discovered immediately.
• The request starts early.
• The image is 2.8 MB.
• Downloading it takes most of the remaining time.

That is a completely different problem.

Both pages have:

LCP = 4.2 seconds

But they require completely different fixes.

This is why an LCP number by itself is not a diagnosis.

What Not to Do When Optimizing LCP

Do Not Chase a Perfect Score

Getting from 4.5 seconds to 2.4 seconds can represent a meaningful improvement.

Getting from 2.4 seconds to 2.3 seconds may not be worth replacing half the site’s architecture.

Performance work should be proportional to the problem.

Do Not Optimize Every Image

If the LCP element is a text heading, spending hours compressing images may have almost no effect on LCP.

Find the actual candidate first.

Do Not Treat Lighthouse as Real-User Data

A lab test is useful for diagnosis.

It is not a substitute for understanding how real visitors experience the page.

Use field data when it is available.

Do Not Assume Hosting Is Always the Problem

A slow server can absolutely hurt LCP.

But a fast server cannot compensate for an image that is discovered too late, enormous JavaScript execution, or an LCP resource that is otherwise delayed.

Performance is a chain.

The slowest part of the relevant chain deserves attention.

Do Not Install Five Optimization Plugins Before Diagnosing the Problem

This is especially relevant on CMS platforms.

Adding another caching, image, JavaScript, or “speed optimization” plugin may change several variables at once.

You can end up with:

• Duplicate optimization
• Broken scripts
• Cache conflicts
• Unexpected loading behavior
• Harder debugging

Measure first. Change one meaningful thing. Test again.

LCP and WordPress

WordPress sites frequently encounter LCP problems around:

• Featured images
• Page-builder output
• Themes
• Fonts
• Hero sliders
• Lazy-loading settings
• Caching
• CDN configuration
• Third-party scripts
• Above-the-fold CSS

But there is no universal WordPress LCP configuration.

Two WordPress sites can use the same theme and plugins and have completely different LCP behavior because their content, hosting, templates, images, traffic and configuration are different.

That is why a recommendation such as “enable this optimization setting” should never be treated as a guaranteed LCP fix.

The page needs to be inspected first.

How LCP Relates to SEO

LCP is one of the three current Core Web Vitals.

Core Web Vitals are used by Google’s ranking systems as part of the broader page-experience picture.

That does not mean improving LCP automatically moves a page to the top of search results.

A page still needs useful content, relevance, strong information architecture and many other qualities.

The better reason to improve LCP is that visitors should not have to wait unnecessarily for the content they came to see.

Search visibility and user experience can benefit from good performance, but LCP should not be treated as an isolated ranking lever.

LCP vs FCP: What Is the Difference?

These metrics are related but answer different questions.

First Contentful Paint (FCP) measures when the browser first renders something from the page.

That could be a small piece of text, a background, or another initial visual response.

Largest Contentful Paint goes further. It looks for the largest qualifying visible content element during the loading process.

A page can therefore have:

FCP: 1.0 seconds
LCP: 3.2 seconds

There is nothing contradictory about those numbers.

The browser showed something at one second.

The main visible content did not appear until 3.2 seconds.

That difference is precisely why both metrics can be useful.

LCP vs TTFB: Why They Are Not the Same

TTFB measures how quickly the browser begins receiving the server response.

LCP measures when the relevant largest visible content has been rendered.

A slow TTFB can contribute to slow LCP, but they are not interchangeable.

For example:

TTFB = 0.5 seconds
LCP = 4.0 seconds

The server responded reasonably quickly, but something later in the loading process is causing the delay.

Likewise:

TTFB = 2.0 seconds
LCP = 2.5 seconds

There is much less time available for everything that happens after the server response.

This is why LCP debugging should consider the entire loading path.

How to Check LCP

Several tools can help you investigate LCP.

PageSpeed Insights

Useful for getting both lab results and, when available, field data associated with the page.

It can also help identify the LCP element and provide diagnostics.

Google Search Console

The Core Web Vitals report can show groups of URLs with performance issues when sufficient field data is available.

This is useful when the question changes from:

“Why is this one page slow?”

to:

“Which groups of pages are consistently slow for our visitors?”

Chrome DevTools

DevTools is particularly useful when you need to understand what happened during loading.

The Performance panel can help connect network activity, rendering, scripting and paint events.

That is often where the answer becomes visible.

Real-User Monitoring

For larger sites, collecting performance data from actual visitors can provide a much more representative view of how pages behave across devices and networks.

A Better Way to Think About LCP

LCP is often described as “how fast the biggest element loads.”

That is useful for a beginner, but it is incomplete.

A better description is:

LCP tells you when the page’s largest relevant piece of visible content has been rendered, and diagnosing that number requires understanding everything that had to happen before that rendering could occur.

The distinction changes how you optimize.

If the LCP image is huge, reduce the cost of delivering it.

If it is discovered late, improve its discoverability.

If the server responds slowly, investigate the server path.

If JavaScript delays rendering, investigate main-thread work.

If CSS prevents the element from appearing, investigate the rendering path.

The metric stays the same.

The engineering problem changes.

LCP Optimization Checklist

Before declaring an LCP problem fixed, check:

• Have you identified the actual LCP element?
• Is the LCP element visible in the initial viewport?
• Is the server response unnecessarily slow?
• Is the LCP resource discovered early?
• Is an important image being lazy-loaded?
• Is the image larger than necessary?
• Is the correct responsive image being delivered?
• Are fonts delaying important text?
• Is CSS delaying rendering?
• Is JavaScript occupying the main thread?
• Are third-party scripts involved?
• Have you compared lab and field data?
• Did the change improve the actual bottleneck?
• Did you verify the result after caching and deployment conditions changed?

That last question is easy to overlook.

A performance fix is not finished when a local test looks better. You want to know whether the improvement survives in the environment your visitors actually use.

Final Verdict

LCP is not simply a contest to make a number under 2.5 seconds.

It is a way of asking a more useful question:

How long does a visitor have to wait before the main visible content of this page appears?

Once you look at LCP that way, the optimization process becomes much clearer.

Find the element.

Find when the browser discovered it.

Find what delayed its request or rendering.

Then fix the bottleneck responsible for the delay.

Sometimes that means a smaller image. Sometimes it means better caching. Sometimes the image was never the problem in the first place.That is the difference between following a performance checklist and actually diagnosing web performance.

Related Articles

Continue learning about Largest Contentful Paint and website performance with these related guides:

• Core Web Vitals Guide: LCP, INP, CLS, Testing & Optimization
  Understand how LCP fits into the wider Core Web Vitals framework.
• Website Speed Audit: A Step-by-Step Workflow to Find and Fix Performance Problems
  Learn how to identify slow LCP elements and other performance bottlenecks.
• Above-the-Fold Content and Critical Rendering: How to Speed Up the First View
  Explore how critical CSS, JavaScript, fonts, and image loading affect the first viewport.
• Mobile-First Website Speed Optimization: How to Build Faster Mobile Websites
  Discover ways to improve loading performance for mobile visitors.
• CSS and JavaScript Minification and Compression: A Practical Guide
  Learn how reducing file sizes can improve resource delivery and rendering.
• Gzip vs Brotli: Which Compression Method Is Better for Websites?
  Compare compression methods that reduce the size of transferred assets.
• Core Web Vitals Optimization Service: What a Professional Audit Includes
  Understand how a professional audit identifies and prioritizes LCP and other performance issues.

Recommended External Resources

• Google web.dev: Largest Contentful Paint: Learn how LCP works and which elements can qualify.
• Google web.dev: Optimize LCP: Follow practical steps to improve LCP.
• Google Search Central: Core Web Vitals: Understand Google’s guidance on Core Web Vitals.
• Google PageSpeed Insights: Review field data when available and lab diagnostics.
• Chrome DevTools Performance: Investigate rendering and resource-loading bottlenecks.

Recommended Resources

Use these resources to understand Largest Contentful Paint and troubleshoot slow loading performance:

• Largest Contentful Paint (LCP) explains how the metric works and which content elements can qualify.
• Optimize Largest Contentful Paint provides practical optimization guidance.
• Google Search Central: Core Web Vitals explains Google’s Core Web Vitals guidance.
• Google PageSpeed Insights helps diagnose performance issues using available field data and lab tests.
• Chrome DevTools Performance helps investigate browser rendering and loading behavior.