Largest Contentful Paint (LCP) is a Core Web Vitals metric that measures the time from when a page starts loading to when the largest visible content element — a hero image, headline, or product photo — finishes rendering. Google scores LCP under 2.5 seconds as "good," 2.5–4.0 seconds as "needs improvement," and over 4.0 seconds as "poor." Pages with poor LCP have 24% higher bounce rates.
LCP is the metric that tells you whether users can actually see and use your page fast enough to stay. Get it wrong and Google penalises you in rankings before a single visitor even notices the slow load.
What is Largest Contentful Paint?
LCP is one of three Core Web Vitals — alongside Cumulative Layout Shift (CLS) and Interaction to Next Paint (INP) — that Google uses as ranking signals within its Page Experience system. It addresses the user-first question: "When can I actually see the main content?"
The metric doesn't track when the last pixel loads. It tracks when the most important visual element — whatever dominates the above-the-fold viewport — becomes visible. Google chose this because it correlates most closely with perceived load speed: the subjective feeling of a page being fast or slow.
LCP is Google's preferred metric for perceived load performance because it answers the question users actually care about: "When can I see and use the main content?" It replaces older metrics like First Meaningful Paint that proved unreliable across site types.
What elements count for LCP?
The browser evaluates candidate elements throughout the loading process and continuously updates the LCP candidate until a user interaction occurs (click, scroll, keypress). At that point, the LCP is locked in.
| Element type | Counts for LCP? | Notes |
|---|---|---|
| img elements | Yes | Most common LCP element; includes picture elements |
| CSS background images | Yes | Only if loaded via url() and large enough |
| Video poster images | Yes | The static thumbnail before play |
| Large text blocks | Yes | h1, h2, p — text-only pages often score well |
| Below-fold elements | No | Must be in the initial viewport |
| Decorative icons | No | Too small to register as LCP candidate |
| Hidden elements (opacity: 0) | No | Must be visible to count |
LCP scoring thresholds
Google's field data comes from real Chrome users, not lab simulations. This is what matters for ranking — not Lighthouse scores alone.
| Rating | LCP time | User experience |
|---|---|---|
| Good | ≤ 2.5 seconds | Content appears quickly; user perceives the site as fast |
| Needs Improvement | 2.5 – 4.0 seconds | User notices delay; may become impatient |
| Poor | > 4.0 seconds | User perceives site as slow; high abandonment risk |
Pages with LCP under 2.5 seconds have 24% lower bounce rates than pages with LCP over 4 seconds, according to Google's own data.
What causes poor LCP?
Four root causes account for the vast majority of poor LCP scores:
- Slow server response time (TTFB). If the server takes 2 seconds just to send the first byte, LCP cannot be under 2.5 seconds no matter how fast the rest of the page loads. Fix: CDN, caching, faster hosting.
- Render-blocking resources. CSS and JavaScript files that block the browser from rendering any HTML until they finish downloading. Fix: inline critical CSS, defer non-critical JS.
- Slow resource loading. Large, uncompressed images or slow-loading fonts delay when the LCP element appears. Fix: WebP/AVIF images, preload the LCP element, system fonts.
- Client-side rendering. Pages built entirely with JavaScript must download, parse, and execute JS before any content appears. Fix: server-side rendering (SSR) or static site generation (SSG).
How to improve LCP
Improvements fall into three buckets by effort level:
Quick wins (under 1 hour)
- Compress and convert hero images to WebP or AVIF
- Add
<link rel="preload" as="image">for the LCP element - Set explicit
widthandheightattributes on all images - Enable browser caching headers
Medium effort (1–4 hours)
- Implement a CDN for static assets
- Inline critical above-the-fold CSS
- Defer non-critical JavaScript with
deferorasync - Upgrade to HTTP/2 if still on HTTP/1.1
High effort (4+ hours)
- Migrate to server-side rendering or static site generation
- Optimise database queries and API response times
- Implement edge caching at CDN level
- Move to faster hosting infrastructure
How to measure LCP
Use field data for ranking context, lab data for debugging:
- Google Search Console — Core Web Vitals report shows site-wide field data from real Chrome users. This is what Google uses for ranking.
- PageSpeed Insights — Per-page scores combining field data (CrUX) and lab data (Lighthouse). Shows the exact LCP element.
- Chrome DevTools — Performance panel lets you step through the loading timeline and identify exactly which element triggered LCP and when.
- WebPageTest — Tests from multiple locations and connection speeds; useful for identifying geographic performance gaps.
LCP vs. First Contentful Paint — which to optimise first?
FCP and LCP measure different things and require different fixes.
Optimise LCP when
- Your hero image or headline loads slowly
- Google Search Console flags poor Core Web Vitals
- Users are abandoning after the initial paint
- Your main content is an image-heavy design
- Bounce rate is high despite fast FCP
Optimise FCP when
- The page feels blank for 1–2 seconds before anything appears
- Render-blocking CSS is your biggest bottleneck
- Text content is your main LCP element
- Server response time (TTFB) is the primary problem
- You're using a heavy JavaScript framework
6 best practices for maintaining good LCP
- Preload the LCP image. Add
<link rel="preload" as="image" href="/hero-poster.webp">in your document head. This tells the browser to fetch it before the parser discovers it in the HTML body. - Never lazy-load above-the-fold images. Applying
loading="lazy"to your hero image delays LCP. Only lazy-load images that start below the visible viewport. - Use next-gen image formats. WebP is 25–35% smaller than JPEG at equivalent quality. AVIF is 50% smaller. Smaller file = faster render.
- Serve images from a CDN. A CDN delivers assets from the node nearest the user, cutting latency from hundreds of milliseconds to single digits.
- Set explicit image dimensions. Always include
widthandheightattributes. Without them, the browser doesn't know how much space to reserve, which also hurts CLS. - Test on real mobile hardware. Lighthouse simulates a mid-tier mobile device, but the cheapest Android phones in emerging markets are slower. Field data from Search Console captures this reality.
Adding loading="lazy" to your hero or banner image is one of the most common LCP killers. The browser deliberately delays fetching it, which pushes LCP out by 500ms–2 seconds. Above-the-fold images must load immediately — either omit the loading attribute or use loading="eager" explicitly.
Common LCP mistakes to avoid
- Lazy loading above-the-fold images — directly delays LCP by design.
- Not preloading the LCP image — browser discovers it late in parsing; preload moves it to the front of the queue.
- Using PNG for hero images — PNG files are 3–5x larger than WebP for photographs. Always use WebP or AVIF.
- Render-blocking third-party scripts — analytics, chat widgets, and ad scripts loaded synchronously in the head block all rendering. Use
asyncordefer. - Optimising only Lighthouse scores — Lighthouse uses a simulated environment. Your ranking depends on real-user field data in Search Console.
- Ignoring mobile — Google measures LCP separately for mobile and desktop; mobile typically scores worse and is what Google uses for mobile-first indexing.
Frequently asked questions
Under 2.5 seconds is "good." Between 2.5 and 4.0 seconds "needs improvement." Over 4.0 seconds is "poor." Google uses real Chrome user data from the field, not lab simulations, for ranking purposes.
Yes. LCP is one of three Core Web Vitals that feed into Google's Page Experience ranking signal. Poor LCP creates a disadvantage against competitors with equivalent content quality.
Images (img tags and CSS background images), video poster images, and large block-level text elements. Elements below the fold, decorative icons, and elements hidden with opacity: 0 do not count.
Google Search Console's Core Web Vitals report shows site-wide field data. PageSpeed Insights gives per-page scores. Chrome DevTools Performance panel identifies the exact LCP element and timing.
No. LCP measures when the largest visible element renders. Page load time measures when every resource finishes loading. A page can have good LCP at 2 seconds but a total load time of 8 seconds.
Related glossary terms
Sources
