How to Fix Poor LCP: 9 Powerful Troubleshooting Steps

Introduction

How to fix poor LCP starts with identifying which part of the page loading process is causing the delay. A slow Largest Contentful Paint (LCP) result can come from a sluggish server response, an oversized hero image, late resource discovery, render-blocking CSS or JavaScript, or delayed rendering. Applying random speed optimizations may not address the real problem. This practical troubleshooting guide explains how to diagnose poor LCP, identify the largest bottleneck, and apply targeted fixes that improve loading performance without introducing unnecessary changes. A poor Largest Contentful Paint score can be frustrating because the number itself does not tell you exactly what is wrong.

You may see an LCP of 4 seconds, 5 seconds, or even longer in PageSpeed Insights, but several very different problems can produce that result. The server might respond slowly. The browser might discover the LCP image too late. A large image might take too long to download. CSS or JavaScript might prevent the browser from rendering the content quickly.

That is why fixing LCP is rarely about applying one optimization.

The better approach is to find where the time is being spent, then fix the largest delay first.

This guide walks through that process step by step.

Quick Answer

To fix poor LCP:

1. Confirm the problem using real-user data when available.
2. Identify the actual LCP element.
3. Check whether the delay starts before the LCP resource is discovered.
4. Improve server response time if TTFB is high.
5. Make the LCP resource discoverable as early as possible.
6. Optimize the LCP image if an image is responsible.
7. Avoid lazy-loading the LCP image.
8. Reduce CSS and JavaScript that delay rendering.
9. Remove unnecessary redirects and third-party bottlenecks.
10. Retest under realistic mobile conditions.
11. Monitor field data after the change.

A good LCP is 2.5 seconds or less at the 75th percentile. Between 2.5 and 4 seconds needs improvement, while anything above 4 seconds is considered poor.

The important part is not simply reaching a better number in one laboratory test. You want the main content to become visible quickly for real visitors.

What Is Poor LCP?

Largest Contentful Paint measures when the largest visible content element in the viewport has rendered.

Depending on the page, that element could be:

• A large hero image
• A featured image
• A product image
• A prominent heading
• A large block of text
• A video poster or first video frame

LCP is therefore a measurement of perceived loading speed rather than a measurement of the entire page finishing.

A page can continue loading scripts, analytics, images, advertisements, and other resources after LCP has occurred.

For Core Web Vitals, the target is:

LCP	Assessment
Up to 2.5 seconds	Good
More than 2.5 seconds to 4 seconds	Needs improvement
More than 4 seconds	Poor

These thresholds are evaluated at the 75th percentile rather than by looking at one individual visit.

That distinction becomes important when troubleshooting because your own browser test may look considerably better than the experience reported by real users.

Start by Finding the LCP Element

Before changing anything, find out what the browser considers the LCP element.

This is the most important first step.

Suppose PageSpeed Insights reports:

LCP: 4.6 seconds

That number alone does not tell you whether the problem is an image, heading, server response, stylesheet, or rendering delay.

Look for the LCP element in the performance report.

If the LCP element is an image, investigate:

• Image file size
• Image dimensions
• Image format
• Image compression
• Resource discovery
• srcset and responsive images
• CDN delivery
• Lazy loading
• Preloading
• Render delay

If the LCP element is text, investigate:

• Server response
• CSS delivery
• Web fonts
• Render-blocking stylesheets
• JavaScript delaying rendering
• Main-thread work

The fix depends on the element.

The Four Places LCP Time Can Be Lost

A useful way to troubleshoot LCP is to think about the journey from navigation to rendering.

For an image LCP, the browser may spend time on several stages:

Server response → resource discovery → resource download → rendering

A delay at any of these stages can push LCP later.

For image LCPs, Chrome’s field data can also expose several related timing components:

• Time to First Byte
• Resource load delay
• Resource load duration
• Element render delay

These are particularly useful because they help distinguish between a resource that is slow to download and a resource that was discovered or rendered too late.

Do not treat the four values as a mathematical breakdown that must exactly equal the overall 75th-percentile LCP. They are aggregated measurements and are best used to identify where the problem is concentrated.

Step 1: Check Your Real-User LCP First

Before making changes, determine whether the poor LCP exists for real visitors.

Use sources such as:

• Google Search Console Core Web Vitals
• PageSpeed Insights
• Chrome UX Report data when available
• Your own Real User Monitoring system, if installed

Field data is particularly valuable because it reflects actual devices, networks, browsers, geographic locations, and page conditions.

A local test on a fast desktop connection cannot represent every visitor.

For example, you might see:

Your test: 1.8 seconds

Real-user data: 3.7 seconds

That does not necessarily mean the testing tool is broken.

Your users may be visiting through slower mobile networks, less powerful devices, or different geographic routes.

Why the 75th percentile matters

Core Web Vitals are evaluated using the 75th percentile.

That means you should not optimize around the fastest visits.

You are trying to improve the experience experienced by a large majority of visitors, particularly those on slower conditions.

This is also why one successful PageSpeed test should not be considered proof that the problem has been solved.

Step 2: Test the Page in PageSpeed Insights

Run the affected URL through PageSpeed Insights.

Look at both:

• Field data
• Lab data

They answer different questions.

Field data helps you understand what real visitors are experiencing.

Lab data helps you investigate the page under a controlled test environment.

This distinction is important when troubleshooting.

If field data is poor but the lab result is good, investigate differences in:

• Device mix
• Network conditions
• Geography
• Cached versus uncached visits
• Server locations
• Real-world traffic patterns
• Dynamic content

If both are poor, you have stronger evidence that the page has a reproducible performance problem.

Do not automatically assume that improving the Lighthouse score will solve every field-data problem.

Step 3: Check Time to First Byte

If the server takes a long time to respond, the browser cannot begin processing the page promptly.

This makes server response time an important part of LCP troubleshooting.

Check TTFB in your performance reports.

Possible causes of a slow server response include:

• Slow hosting
• Server-side application work
• Database queries
• Uncached pages
• Poor caching configuration
• Backend APIs
• Redirect chains
• Geographic distance from the server
• Traffic-related resource constraints

The solution depends on the cause.

Improve caching

If a page can be served from cache instead of being generated from scratch for every visitor, response time may improve significantly.

Caching can exist at several levels:

• Browser cache
• Page cache
• Server cache
• CDN cache
• Object or database cache

Do not install multiple caching systems blindly.

A complicated caching stack can create its own problems.

Review your hosting environment

If server response remains slow after reasonable caching and application optimization, hosting may be part of the problem.

Before changing hosts, however, establish that the server is actually the bottleneck.

Moving a website to a more expensive server will not fix an LCP problem caused by a late-discovered hero image or render-blocking CSS.

Step 4: Find Out Whether the LCP Resource Is Discovered Too Late

This is one of the most overlooked causes of poor LCP.

Imagine the browser needs a large hero image to paint the main content.

If the image URL is immediately visible in the HTML, the browser can begin discovering it early.

But what if JavaScript has to execute before the image URL becomes available?

The browser may spend valuable time doing other work before it even starts downloading the resource.

The image itself might be perfectly optimized.

The problem is that the browser started fetching it too late.

Common causes of late discovery

A critical image can be delayed by:

• JavaScript-generated markup
• CSS background images
• Client-side rendering
• Lazy-loading configuration
• Complex page builders
• Components that are initialized late
• Incorrect preload configuration
• Excessive HTML processing
• Scripts that modify the page before the image is available

When an LCP image is critical to the initial viewport, make sure the browser can discover it early.

Step 5: Do Not Lazy-Load the LCP Image

Lazy loading is useful for images that are below the initial viewport.

It is usually the wrong strategy for the image that is responsible for LCP.

A lazy-loaded LCP image can wait for conditions that are unnecessary because the browser already knows that the image is immediately needed.

For example:

<img src=”hero.webp” loading=”lazy” alt=”Example”>

If this image is the main visible image at the top of the page, lazy loading can introduce an unnecessary delay.

A critical above-the-fold image should generally be loaded eagerly.

For example:

<img src=”hero.webp” loading=”eager” fetchpriority=”high” alt=”Example”>

Use high priority deliberately rather than adding it to every image on the page.

The goal is to help the browser prioritize the resource that genuinely matters most.

Step 6: Optimize the LCP Image

If the LCP element is an image, image optimization deserves careful attention.

But “compress the image” is only part of the job.

Check all of the following.

Use an appropriate image format

Modern formats such as WebP or AVIF can significantly reduce image transfer size compared with unnecessarily large legacy formats.

The correct format depends on the image and browser support requirements.

Serve the correct dimensions

Do not send a 4000-pixel-wide image when the visitor needs a 1200-pixel-wide version.

Responsive images allow the browser to select an appropriate resource.

For example:

<img

  src=”hero-1200.webp”

  srcset=”

    hero-768.webp 768w,

    hero-1200.webp 1200w,

    hero-1600.webp 1600w”

  sizes=”100vw”

  alt=”Example hero image”>

The exact values should reflect your actual layout rather than being copied blindly.

Compress intelligently

Compression should reduce unnecessary bytes without visibly damaging the image.

Do not judge optimization by file size alone.

A tiny image that looks poor is not a successful performance optimization.

Use a CDN when appropriate

A CDN can reduce the network distance between visitors and static assets.

This can help image delivery, particularly for audiences spread across different regions.

But a CDN cannot fix a resource that the browser does not discover until several seconds into the page load.

Step 7: Check Whether CSS Is Blocking Rendering

The browser needs CSS to understand how the page should be displayed.

Large or poorly structured stylesheets can delay rendering.

Look for:

• Large CSS files
• Unused CSS
• Multiple stylesheet requests
• Render-blocking stylesheets
• CSS loaded from slow external domains
• Page-builder-generated CSS
• CSS that is needed only for content below the fold

The goal is not to remove CSS simply because it appears in a performance report.

The goal is to make the styles needed for the initial viewport available efficiently while avoiding unnecessary work.

Be careful with aggressive CSS optimization

Removing or delaying CSS without testing can create:

• Unstyled content
• Layout changes
• Broken responsive behavior
• Flashing styles
• Missing components

Performance improvements should not come at the cost of a broken page.

Step 8: Look for JavaScript Delaying the Initial Render

JavaScript can affect LCP even when the LCP element itself is an image.

Heavy JavaScript can consume the main thread and delay browser work needed to render the page.

Look for:

• Large JavaScript bundles
• Unnecessary libraries
• Third-party scripts
• Analytics
• Chat widgets
• Social widgets
• Advertising scripts
• Sliders and animation libraries
• Client-side rendering
• JavaScript-generated content

Ask a simple question:

Does this script need to run before the main content becomes visible?

If the answer is no, consider whether it can be:

• Deferred
• Delayed
• Loaded asynchronously
• Code-split
• Removed
• Loaded only when needed

Do not delay essential scripts simply to make a performance report look better.

Step 9: Investigate Third-Party Resources

Third-party services can create performance dependencies that you do not fully control.

Examples include:

• Advertising
• Analytics
• Embedded videos
• Social widgets
• Chat tools
• A/B testing platforms
• Marketing tags
• Consent-management systems

A third-party script does not automatically mean your LCP is poor.

The important question is whether it is delaying work required for the initial rendering of the main content.

If a marketing script can wait until after the critical content is visible, loading it later may be worth considering.

Step 10: Check for Redirects

Redirects add another step before the final page can be requested.

For example:

URL → redirect → HTTPS URL → www/non-www redirect → final page

A visitor should ideally reach the final URL without unnecessary hops.

Check:

• HTTP to HTTPS redirects
• www versus non-www redirects
• Old URL redirects
• Tracking redirects
• CDN redirects
• Plugin-generated redirects

One redirect may not destroy your LCP, but unnecessary chains can add latency before the actual document becomes available.

Step 11: Check Your Fonts

Fonts can affect the visual appearance of text-based LCP elements.

If a large heading is the LCP element, the browser may need to obtain and process the font before the final text presentation is ready.

Review:

• Number of font files
• Font file size
• Font formats
• External font providers
• Font loading strategy
• Number of font weights
• Whether every font weight is actually needed

Do not load six font weights when the site uses two.

Where appropriate, use efficient font formats and sensible loading behavior.

For text-heavy pages, typography can be part of the LCP investigation even when there is no large hero image.

Step 12: Check the Critical Rendering Path

LCP is affected by the chain of work required before the main content can appear.

A simplified sequence looks like:

HTML → resource discovery → CSS/JS processing → resource loading → layout → rendering

The longer or more complicated this chain becomes, the greater the opportunity for delay.

When troubleshooting, ask:

1. What does the browser need first?
2. What can be discovered immediately?
3. Which resources block rendering?
4. Which resources are competing for bandwidth?
5. Which scripts must execute before content can appear?
6. What is delaying the final LCP render?

This mindset is more useful than blindly applying every optimization listed by PageSpeed Insights.

Step 13: Use Chrome DevTools for Deeper Diagnosis

When PageSpeed Insights tells you that LCP is poor but does not make the cause obvious, Chrome DevTools can provide more detail.

Open the affected page in Chrome.

Then open:

DevTools → Performance

Record a page load and inspect the timeline.

Look for:

• LCP marker
• Network activity
• Main-thread activity
• Long tasks
• CSS processing
• JavaScript execution
• Image loading
• Rendering activity

The Performance panel can help you connect the LCP event with the work that happened immediately before it.

You can also save performance traces for later analysis, which is useful when debugging a complex page or comparing before-and-after results.

What you are looking for

Imagine the timeline shows:

HTML response: 0–1.2s
Hero image discovered: 2.0s
Hero image downloaded: 2.0–3.5s
LCP rendered: 3.7s

The problem is probably not simply image compression.

The image was discovered too late.

Now imagine:

HTML response: 0–0.5s
Hero image discovered: 0.6s
Image download: 0.6–3.2s
LCP: 3.4s

That points more strongly toward resource delivery and image size.

The diagnosis changes the optimization.

Common Poor-LCP Scenarios

Scenario 1: Large hero image

Symptom: LCP is an image and takes several seconds to download.

Check:

• File size
• Dimensions
• Format
• CDN
• Responsive images
• Network waterfall

Likely fixes:

• Resize
• Compress
• Use WebP or AVIF where appropriate
• Serve responsive variants
• Improve delivery
• Ensure early discovery

Scenario 2: Image loads quickly but LCP is still late

Symptom: The image appears to download early, but the LCP timestamp remains high.

Check:

• CSS
• JavaScript
• Main-thread activity
• Rendering delay
• Layout work

The image may not be the actual bottleneck.

Scenario 3: High TTFB

Symptom: The document itself arrives late.

Check:

• Hosting
• Page caching
• Database work
• Server-side processing
• CDN configuration
• Redirects

Improve the server-side path before spending hours optimizing front-end assets.

Scenario 4: LCP image is discovered late

Symptom: The hero image starts downloading well after the HTML arrives.

Check:

• JavaScript-generated markup
• CSS background image
• Lazy loading
• Page-builder output
• Resource priority

Make the critical resource discoverable earlier.

Scenario 5: Desktop looks fine, mobile is poor

Symptom: Desktop Lighthouse looks good while mobile LCP is significantly worse.

Check:

• Mobile image sizes
• Server response
• Network conditions
• JavaScript execution
• Responsive image selection
• Third-party scripts
• Mobile-specific layout

Do not optimize exclusively around a fast desktop computer.

What If Your LCP Is Text?

Not every page has an image as its LCP element.

A large heading or paragraph can become LCP when it occupies the largest portion of the visible viewport.

In this situation, image optimization will not solve the problem.

Investigate:

• TTFB
• CSS delivery
• Font loading
• Render-blocking resources
• JavaScript execution
• Main-thread work
• Client-side rendering

This is one reason identifying the LCP element should always come before choosing an optimization.

WordPress: How to Troubleshoot Poor LCP

WordPress sites often have several layers that can affect LCP:

• Theme
• Page builder
• Plugins
• Caching
• CDN
• Image optimization
• Fonts
• Advertising
• Analytics
• Third-party widgets

Do not activate every performance option at once.

Instead, establish a baseline and change one meaningful variable at a time.

Check your theme

A theme can add CSS, JavaScript, fonts, sliders, animations, and other resources before the main content becomes visible.

If the theme is responsible for unnecessary work, plugin-level optimization may have limited impact.

Check page-builder output

Page builders can produce additional markup, CSS, and JavaScript.

That does not mean page builders are automatically bad for Core Web Vitals.

It means you should identify whether the generated page is creating unnecessary work.

Check image settings

Make sure your LCP image is not:

• Excessively large
• Being lazy-loaded
• Served in an inefficient format
• Missing responsive variants
• Being delivered from a slow source

Check caching

Page caching can reduce server-side work and improve response time.

But verify the actual result instead of assuming that enabling a cache plugin means the server is now fast.

Be careful with optimization plugins

Features such as:

• Delay JavaScript
• Remove unused CSS
• Combine files
• Defer scripts
• Critical CSS
• Preload assets

can help, but their effectiveness depends on the site.

An aggressive configuration can also break functionality or create new rendering problems.

Should You Preload the LCP Image?

Preloading can help when a critical resource is difficult for the browser to discover early.

For example, a critical image that is otherwise hidden behind a CSS or JavaScript dependency may benefit from an appropriate preload.

But preload is not a universal LCP button.

Overusing preload can cause competing resources to fight for bandwidth.

Before adding one, ask:

Is this resource genuinely critical, and is the browser discovering it too late?

If the image is already present in the HTML and discovered immediately, adding another priority mechanism may provide little benefit.

Use resource prioritization deliberately.

Should You Use fetchpriority=”high”?

For an important LCP image, fetchpriority=”high” can help communicate that the resource is important.

For example:

<img

  src=”hero.webp”

  fetchpriority=”high”

  alt=”Example hero image”>

But do not add fetchpriority=”high” to every image.

If everything is high priority, the browser loses the ability to distinguish what matters most.

Use it for genuinely critical resources.

What Not to Do When Fixing LCP

Do not chase a perfect Lighthouse score

A 100 is not the objective.

A useful website that consistently delivers good Core Web Vitals to real users is more valuable than a page engineered solely to produce a perfect laboratory score.

Google itself advises against treating Core Web Vitals as a single ranking score or assuming that perfect tool results guarantee top search rankings.

Do not optimize only the image

Image optimization is important when the LCP element is an image.

But LCP can also be affected by:

• TTFB
• Resource discovery
• CSS
• JavaScript
• Fonts
• Rendering
• Third-party resources

Do not test only once

Performance varies.

A single test can be affected by:

• Network conditions
• Server conditions
• Cache state
• Test location
• Device characteristics

Run repeatable tests and look for consistent patterns.

Do not make five major changes simultaneously

If you change hosting, caching, JavaScript, CSS, images, and CDN configuration at the same time, you may improve the result without knowing why.

That makes future troubleshooting harder.

Change the biggest bottleneck first.

A Practical Poor-LCP Troubleshooting Workflow

Use this sequence when a page fails LCP.

Phase 1: Confirm

• Check Search Console field data.
• Check PageSpeed Insights.
• Record the current LCP.
• Test mobile conditions.
• Note whether lab and field results agree.

Phase 2: Identify

• Find the LCP element.
• Determine whether it is text, image, or video.
• Inspect the resource waterfall.
• Check TTFB.
• Check when the LCP resource was discovered.

Phase 3: Diagnose

If TTFB is high:

Investigate the server.

If resource discovery is late:

Improve HTML/resource discovery.

If the resource download is slow:

Optimize the resource and delivery.

If the resource arrives early but rendering is late:

Investigate CSS, JavaScript, layout, and main-thread work.

Phase 4: Fix

Apply the smallest high-impact change first.

Examples:

• Improve page caching
• Reduce server response time
• Remove unnecessary redirects
• Make the LCP resource discoverable earlier
• Remove lazy loading from the LCP image
• Compress and resize the image
• Improve responsive image delivery
• Reduce render-blocking CSS
• Defer non-critical JavaScript
• Reduce third-party work
• Improve font loading

Phase 5: Retest

Run the same test conditions again.

Compare:

• LCP
• TTFB
• LCP resource discovery
• Resource download time
• Render delay
• Overall page behavior

Phase 6: Monitor field data

A successful lab test is not the final step.

Continue monitoring real-user performance to determine whether the improvement survives outside the test environment.

Poor LCP Troubleshooting Checklist

Measurement

• Check field data
• Check lab data
• Record current LCP
• Test mobile
• Identify the LCP element

Server

• Check TTFB
• Check page caching
• Review hosting performance
• Check database/server-side work
• Remove unnecessary redirects

LCP resource

• Confirm the correct resource
• Check resource discovery
• Avoid lazy loading the LCP image
• Use an appropriate image format
• Resize oversized images
• Use responsive images
• Review CDN delivery
• Consider priority hints where appropriate

CSS

• Check render-blocking CSS
• Reduce unnecessary CSS
• Review critical styles
• Avoid unnecessarily large stylesheets

JavaScript

• Identify large scripts
• Check main-thread work
• Defer non-critical scripts
• Review third-party scripts
• Remove unnecessary libraries

Fonts

• Reduce unnecessary font files
• Review font weights
• Use efficient font formats
• Check font loading behavior

Verification

• Retest after changes
• Compare before and after
• Test multiple times
• Monitor field data
• Check for regressions

When Fixing LCP Is Not the Highest Priority

Sometimes a website has a poor LCP but an even more serious performance problem elsewhere.

For example, if users cannot interact with the page because of enormous JavaScript tasks, improving LCP by a few hundred milliseconds may not produce the biggest practical improvement.

Likewise, a small LCP improvement may not matter as much as fixing a broken mobile layout or intrusive interface.

Core Web Vitals should be treated as part of the overall page experience rather than isolated scores.Google’s current guidance explicitly notes that Core Web Vitals are one part of a broader page experience and that good scores do not guarantee top search rankings.

Final Verdict

Poor LCP is usually a diagnosis problem before it is an optimization problem.

If you start by compressing every image, delaying every script, installing another caching plugin, or changing your hosting provider, you may spend considerable time fixing things that were never responsible for the delay.

Start with the LCP element.

Then determine where the time is being lost:

server response → resource discovery → resource loading → rendering

Once the bottleneck is clear, the solution becomes much more targeted.

For an image LCP, that may mean making the image discoverable earlier and reducing its delivery cost. For a text LCP, it may involve server response, CSS, fonts, or rendering. For either case, JavaScript and third-party resources can become relevant when they interfere with the critical path.

The objective is not to make one Lighthouse report look perfect.The objective is to make the page’s main content appear quickly and consistently for real visitors.

Related Articles:

• What Is LCP? 7 Powerful Ways to Improve Loading Speed
• Why Your LCP Image Loads Slowly: 7 Critical Fixes
• How TTFB Affects LCP: 7 Critical Fixes for Faster Loading
• Image Optimization: 9 Powerful Ways to Speed Up Your Website
• Above-the-Fold Optimization: 7 Powerful Speed Fixes
• How to Eliminate Render-Blocking Resources: 9 Powerful Fixes
• How a CDN Improves Website Speed: 7 Powerful Benefits
• What Is TTFB? 7 Powerful Ways to Reduce Server Response Time
• Website Speed Audit: 9 Powerful Steps to Fix Slow Pages
• Core Web Vitals Guide: 9 Powerful Ways to Improve LCP, INP & CLS
• How to Eliminate Render-Blocking Resources and Speed Up Page Rendering
• Website Speed Optimization Checklist: 55 Powerful Fixes

Read More:

• Optimize Largest Contentful Paint:
  Caption: Learn how to identify LCP subparts and prioritize the changes most likely to reduce loading time.
• Time to First Byte (TTFB):
  Caption: Understand how server response time contributes to the time before page content can begin loading.
• PageSpeed Insights:
  Caption: Test a page, review available field data, and inspect diagnostic opportunities.
• Core Web Vitals:
  Caption: Review Google’s Core Web Vitals guidance and performance assessment criteria.
• Chrome DevTools Performance Overview:
  Caption: Investigate loading activity, rendering delays, and main-thread work using browser performance tools.