LCPLighthouseCore Web VitalsDiagnosticsTutorial

How to Diagnose Slow LCP with Lighthouse (Step-by-Step)

Learn how to find your LCP element, read Lighthouse audits, compare lab vs CrUX data, and build a prioritized fix list when Largest Contentful Paint is over 2.5 seconds.

PageSpeed Exporter Team··7 min read

Slow Largest Contentful Paint (LCP) means the largest visible element on your page — usually a hero image, headline block, or video poster — takes too long to render. Lighthouse diagnoses LCP in under 30 seconds by identifying the exact DOM element, listing every audit that delayed it, and estimating fix impact in milliseconds.

This step-by-step guide shows how to read that data and turn it into a prioritized fix plan.


What Counts as Slow LCP?

| Rating | LCP time | Action |

|---|---|---|

| Good | ≤ 2.5s | Monitor only |

| Needs improvement | 2.5s – 4.0s | Fix within sprint |

| Poor | > 4.0s | Urgent — affects rankings and conversions |

Google uses real-user data (CrUX) at the 75th percentile for ranking. Lighthouse provides lab data in controlled conditions. Both matter — lab data tells you why; field data tells you whether real visitors experience it.


Step 1: Run a Mobile Lighthouse Audit

  1. Go to speedexporter.com and enter your URL
  2. Select Mobile strategy — Google indexes mobile-first
  3. Run the audit and wait for results (~15–30 seconds)

Mobile throttling (Slow 4G, mid-tier CPU) exposes issues that desktop hides. A site with 1.8s desktop LCP often shows 3.5s on mobile.

Tip: Test your homepage, your highest-traffic landing page, and one template you know is slow (e.g., /products/handle or /blog/post-slug).

Step 2: Read the LCP Metric Card

On the results page, find Largest Contentful Paint in the metrics grid. Note:

  • Value — e.g., 3.8 s
  • Score — 0–100 sub-score (not the overall performance score)
  • Color — green / amber / red

If LCP is red, scroll to Opportunities and Diagnostics next — the metric card alone does not tell you the cause.


Step 3: Identify the LCP Element

Lighthouse includes a dedicated audit: "Largest Contentful Paint element" (largest-contentful-paint-element).

This audit shows:

  • Node selector — the CSS selector or description of the element (e.g., img.hero, #main-content h1)
  • Snippet — truncated HTML of the element
  • URL — for images, the full image URL being loaded
What you are looking for:

| LCP element type | Usual cause |

|---|---|

| hero or product photo | Slow download, no preload, wrong format, lazy-loaded by mistake |

| | Large poster image or autoplay blocking |

| Text block (

,

) | Web font blocking render, slow TTFB delaying HTML |

| Background image via CSS | Discovered late in waterfall, no preload possible on CSS bg |

Download the JSON report and search for "largest-contentful-paint-element". The details.items[0].node object contains the selector and bounding rect.


Step 4: Map Audits to LCP Delay

LCP is delayed by anything that happens before the LCP element renders. Check these audits in order of typical impact:

4.1 Server response time (TTFB)

Audit: server-response-time

If TTFB exceeds 600ms, every paint metric shifts right. Fix caching and hosting before image optimization.

Diagnosis signal: LCP element is in the initial HTML but appears late — the HTML itself arrived slowly.

4.2 Render-blocking resources

Audit: render-blocking-resources

Lists CSS and JS files that blocked the first paint. Each entry includes wastedMs — estimated LCP improvement if deferred.

Diagnosis signal: LCP element is in HTML but browser had not finished parsing blocking scripts/stylesheets.

See: Fix render-blocking resources guide

4.3 LCP resource load delay and duration

Audits: lcp-lazy-loaded (if LCP image was lazy-loaded — critical error), uses-optimized-images, modern-image-formats, uses-responsive-images

Diagnosis signal: LCP element is an image discovered late or downloaded slowly.

Fix pattern:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<img src="/hero.webp" width="1200" height="630" fetchpriority="high" loading="eager" alt="...">

4.4 Client-side rendering

Audit: largest-contentful-paint-element with element inside #root or #__next that appears only after JS runs

Diagnosis signal: LCP element not in initial HTML — React/Vue SPA or client-only rendering.

Fix: SSR, SSG, or streaming server components so the LCP element is in the first HTML chunk.


Step 5: Compare Lab LCP vs CrUX Field Data

PageSpeed Exporter includes CrUX field data in the JSON export (fieldData.url and fieldData.origin).

| Scenario | Meaning |

|---|---|

| Lab LCP poor, CrUX LCP good | Real users on fast networks; lab throttling is stricter — still fix for mobile UX |

| Lab LCP good, CrUX LCP poor | Real users hit slow regions, ads, or A/B tests not in lab test |

| Both poor | Confirmed problem — prioritize fixes |

Field LCP uses the same 2.5s / 4.0s thresholds but reflects actual Chrome users over 28 days. Check Google Search Console → Core Web Vitals for URL-group level field data.


Step 6: Build a Prioritized Fix List

Sort opportunities by estimated savings (ms) × confidence. Lighthouse does this in the Opportunities section — trust the ordering but verify:

  1. TTFB / caching — if server-response-time fails
  2. Remove lazy-load from LCP image — if lcp-lazy-loaded fails
  3. Preload + WebP + dimensions on LCP image
  4. Defer render-blocking JS/CSS not needed for first paint
  5. Reduce unused JS affecting main thread (helps LCP indirectly via less contention)

Export the JSON and use this prompt in ChatGPT or Claude:

Attached is my Lighthouse JSON. My LCP is [X]s on mobile.
1. What is the LCP element?
2. List every audit contributing to slow LCP sorted by wasted ms
3. Give me the exact fix for each — code or config
4. Estimate LCP after fix #1 only

Or use the dedicated LCP + AI tutorial.


Step 7: Verify the Fix

After deploying changes:

  1. Re-run Lighthouse on the same URL and strategy
  2. Confirm LCP metric card is green (≤ 2.5s in lab)
  3. Check largest-contentful-paint-element — verify the element is unchanged or intentionally updated
  4. On Starter/Pro plans, use before/after comparison on PageSpeed Exporter to snapshot score delta
  5. Monitor GSC Core Web Vitals report over 28 days for field confirmation
Do not declare victory from a single lab run — run three audits and take the median. Lighthouse scores vary ±5 points between runs.

Common LCP Diagnosis Mistakes

| Mistake | Why it fails |

|---|---|

| Optimizing favicon or logo when hero is the LCP element | Fixes the wrong resource |

| Adding lazy-load to all images including hero | lcp-lazy-loaded audit fails — makes LCP worse |

| Fixing CLS before LCP | CLS fixes do not help LCP; fix loading path first |

| Testing desktop only | Mobile LCP is the ranking signal |

| Ignoring TTFB | Image optimization cannot fix a 1s server wait |


Diagnosis Workflow Summary

Run mobile Lighthouse audit
        ↓
Read LCP metric (target ≤ 2.5s)
        ↓
Find LCP element audit → note selector + URL
        ↓
Check TTFB → render-blocking → image audits
        ↓
Compare lab vs CrUX field data
        ↓
Prioritize fixes by wasted ms
        ↓
Deploy → re-test → monitor GSC

Further Reading


Sources


Further reading

Try it yourself

Run a free Lighthouse audit on any URL and get the full JSON report for your AI agent — no account required.

Analyze a URL for free