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
- Go to speedexporter.com and enter your URL
- Select Mobile strategy — Google indexes mobile-first
- 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
| 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
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
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:
- TTFB / caching — if server-response-time fails
- Remove lazy-load from LCP image — if
lcp-lazy-loadedfails - Preload + WebP + dimensions on LCP image
- Defer render-blocking JS/CSS not needed for first paint
- 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:
- Re-run Lighthouse on the same URL and strategy
- Confirm LCP metric card is green (≤ 2.5s in lab)
- Check
largest-contentful-paint-element— verify the element is unchanged or intentionally updated - On Starter/Pro plans, use before/after comparison on PageSpeed Exporter to snapshot score delta
- Monitor GSC Core Web Vitals report over 28 days for field confirmation
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
- What is LCP?
- Core Web Vitals overview
- Fix LCP using AI
- Shopify speed guide
- WordPress Core Web Vitals guide
- 5 quick Lighthouse wins