Largest Contentful Paint (LCP): Good Scores, Fixes & Guide
Largest Contentful Paint (LCP) measures when the main content finishes loading. A good LCP score is 2.5 seconds or less on mobile (same threshold for desktop). Scores above 4 seconds are classified as poor. LCP is one of Google's three Core Web Vitals and directly affects search ranking.
LCP is the Core Web Vital developers struggle with most. The Chrome UX Report shows about 40% of sites miss the recommended LCP threshold.
Why? LCP spans the full loading path: server response, resource discovery, transfer, and rendering. You need to find the slow sub-part before choosing a fix.
What is LCP?
Largest Contentful Paint marks when the main content finishes loading. It answers the user's question: "Is this page showing me what I came for?"
The element considered "largest" changes as the page loads. The browser reports the final LCP candidate once the user interacts or the page finishes loading.
LCP Thresholds:
| Device | Good | Needs Improvement | Poor |
|---|---|---|---|
| Mobile | ≤2.5s | 2.5–4.0s | >4.0s |
| Desktop | ≤2.5s | 2.5–4.0s | >4.0s |
Score Weight: LCP accounts for 25% of your Lighthouse Performance score.
What elements can be LCP:
<img>elements: 76% of mobile pages have an image as LCP<video>elements (poster image or first frame)- Elements with CSS
background-imageviaurl() - Block-level elements containing text: about 24% of mobile LCP elements
Why LCP matters
User experience
Users don't wait. When the main content takes too long, they assume the page is broken. The 2.5-second mobile threshold is based on research into user attention spans - after 3 seconds, users start losing patience and bouncing.
The visual impact is immediate: a blank or skeleton screen for 4+ seconds feels broken. A fully-rendered hero in under 2.5 seconds feels fast.
SEO impact
LCP is one of Google's Core Web Vitals ranking factors. Google uses field data (CrUX) from the 75th percentile - meaning 75% of your users need good LCP for it to count as "good" for ranking purposes.
Google describes Core Web Vitals as one part of page experience. Relevance still matters more, so treat LCP as a user experience requirement rather than a shortcut to higher rankings.
Business impact
Real-world case studies demonstrate significant revenue correlation:
| Company | LCP Improvement | Business Impact |
|---|---|---|
| Rakuten | Achieved good LCP | 61% higher conversion rate |
| Vodafone | 31% improvement | 8% more sales |
| Tokopedia | 55% (3.78s → 1.72s) | 23% better session duration |
| NDTV | 50% reduction | 50% better bounce rate |
| Agrofy | 70% improvement | 76% less load abandonment |
The pattern is consistent: faster LCP correlates with better engagement and conversion.
Start with field data
CrUX and Search Console report LCP at the 75th percentile, split by mobile and desktop. Start with the failing device group and URL pattern. Then reproduce one representative page in Lighthouse or Chrome DevTools.
Mobile-first indexing describes which page version Google crawls. It does not make desktop performance irrelevant. A slow desktop experience still affects desktop users, and CrUX reports it separately.
If URL-level CrUX data is unavailable, use origin data as context, not proof that the page passes. Low-traffic pages may have different templates and LCP elements from the home page.
LCP sub-parts breakdown
Google recommends breaking LCP into four sub-parts to pinpoint exactly where time is being wasted:
| Sub-part | Target % of LCP | What it measures |
|---|---|---|
| TTFB | ~40% (1.0s) | Time for server to return first byte |
| Resource Load Delay | <10% (0.25s) | Time before LCP resource starts downloading |
| Resource Load Duration | ~40% (1.0s) | Time to download the LCP resource |
| Element Render Delay | <10% (0.25s) | Time from download complete to painted |
These percentages are diagnostic guidelines, not fixed budgets. The two delay phases should be close to zero. TTFB and resource transfer take real network time, so they usually occupy most of a healthy LCP trace.
Why this matters
Each sub-part has different causes:
- High TTFB: Server issues, no caching, redirects, slow database
- High Load Delay: LCP image not discoverable in HTML, blocked by scripts
- High Load Duration: Image too large, no CDN, slow connection
- High Render Delay: Render-blocking CSS/JS, large DOM, client-side rendering
Measure first, then target the right sub-part. The 2026 LCP practices guide covers current Lighthouse Insights and newer browser features after you fix the basic loading path.
Common LCP issues
Poor LCP stems from a short list of causes. Here are the most impactful:
| Issue | Impact | Difficulty | Fix Time |
|---|---|---|---|
| Slow Server Response (TTFB) | High | Medium | Hours–Days |
| Render-Blocking Resources | High | Medium | Hours |
| Redirects | High | Low | Minutes |
| Prioritize LCP Image | High | Low | Minutes |
| LCP Lazy-Loaded | High | Low | Minutes |
| Resource Load Delay | High | Medium | Hours |
| Client-Side Rendering | High | High | Hours–Days |
| Large Images | Medium | Low | Minutes |
| Lazy Loading Above Fold | Medium | Low | Minutes |
| Total Byte Weight | Medium | Medium | Hours |
| Unminified JavaScript | Medium | Low | Minutes |
| Unused JavaScript | Medium | High | Hours–Days |
→ Diagnose your specific issue
How to measure LCP
Lab testing (development)
Lab tests give you controlled, reproducible results - but they represent synthetic conditions, not real users.
Chrome DevTools:
- Open DevTools → Performance tab
- Click record → reload page
- Look for "LCP" marker in timeline
- Hover to see which element and timing
Lighthouse: Run an audit in DevTools or via CLI. Check the LCP metric and related audits under "Opportunities" and "Diagnostics."
WebPageTest: Detailed waterfall analysis showing exactly when LCP happens relative to other resources. Use for deep debugging.
Field data (real users)
Field data is what Google uses for ranking. It represents actual user experience.
PageSpeed Insights: Enter your URL to see CrUX (Chrome User Experience Report) data. This is the same data Google uses for ranking decisions.
Google Search Console: The Core Web Vitals report shows which URLs pass or fail, grouped by similar pages.
Web Vitals JavaScript Library:
import { onLCP } from 'web-vitals'
onLCP((metric) => {
console.log('LCP:', metric.value, 'ms')
console.log('Element:', metric.attribution.element)
console.log('URL:', metric.attribution.url)
})Send this data to your analytics for real user monitoring.
To catch regressions automatically, set up Lighthouse CI in your deployment pipeline.
Lab vs field discrepancy
Common: your lab score is fine but field data fails. This usually means:
- Real users have slower connections than your test
- Real users hit pages you're not testing
- Third-party scripts behave differently in production
- Caching works in lab but not for first-time visitors
Always prioritize field data over lab scores.
Framework guides
Framework-specific optimizations for LCP:
Next.js
Nuxt
React
Vue
Svelte
Angular
Test your entire site
Checking LCP page-by-page misses the big picture. Your homepage might pass while 200 blog posts fail. Product pages might score well except for ones with large hero images.
Unlighthouse scans your entire site and surfaces LCP scores for every page. The CLI is free and runs locally. Cloud adds scheduled monitoring and historical tracking to catch regressions before users do.
Common myths
"schema.org improves LCP"
False. Structured data (JSON-LD) helps search engines understand your content and can improve Click-Through Rate (CTR) via rich results, but it has zero direct impact on LCP or load times. Focus on rendering performance, not meta tags.
"accessibility hurts performance"
False. Accessible sites are often faster. Semantic HTML is lighter than div soup. However, screen readers rely on the DOM being ready. A site with a fast LCP but blocked main thread (poor INP) creates a frustrating experience for assistive technology users. Fast LCP is the first step in digital accessibility.