Largest Contentful Paint (LCP)
Largest Contentful Paint is the Core Web Vital that measures when the largest visible content element finishes rendering in the viewport. The 'Good' threshold is 2.5 seconds or less at the 75th percentile of real users. LCP is typically the hero image, main heading, or first large block of text — whatever dominates the initial visible viewport.
Also called: LCP · Last updated: May 27, 2026 · By Joseph W. Anady
Why it matters.
LCP is the user-facing equivalent of 'when does the page start to feel loaded?' If the largest element takes 4 seconds to appear, the user perceives a slow page even if the rest of the content arrived faster. The LCP element is almost always either the hero image, a large heading, or a major above-the-fold image block. Optimizing LCP usually means optimizing one specific element.
How it works.
Chrome's LCP measurement runs from page load start until the largest element finishes rendering. The 'largest element' is determined by visual size in the viewport, weighted toward content elements (img, video, background images, large text blocks). The measurement updates as larger elements appear, with the final LCP locked when the user interacts or the page becomes idle.
2026 reality check.
LCP failures are the second-most-common CWV failure in 2026, behind INP. The 2026 culprits are usually: oversized hero images (10MB raw photos served without optimization), Cloudflare proxy adding 100-300ms TTFB, client-side rendering frameworks (React/Vue/Angular) requiring JS execution before LCP element renders, third-party fonts blocking text rendering.
Data points
- Good threshold: <=2.5 seconds at 75th percentile of CrUX field data
- Needs Improvement: 2.5-4 seconds
- Poor: >4 seconds
- Measured by Chrome's LargestContentfulPaint Performance API
- Approximately 30% of sites fail LCP at 75th percentile in 2026 (industry data)
First-hand insight from ThatDeveloperGuy.
ThatDeveloperGuy's LCP optimization stack: hero images converted to AVIF (best compression) with WebP fallback and JPG fallback via picture element, fetchpriority='high' on the LCP image, preload directive in HTML head, dimensions explicitly set to prevent layout shifts, lazy-loading explicitly DISABLED on the LCP image (default lazy delays LCP), no client-side rendering of LCP content (server-side only). Result: sub-1.5 second LCP on every TDG client site.
How TDG approaches it
TDG's standard LCP optimization: hero image as picture element with AVIF + WebP + JPG sources, fetchpriority='high', explicit width/height attributes, preload link in HTML head, server-side rendered HTML, font-display: swap on custom fonts. Sub-1.5 second LCP target on every page.
Common mistakes.
- Hero image not preloaded (browser discovers it late in the parsing pipeline)
- Hero image lazy-loaded (defeats the purpose — LCP element should load eager)
- Hero image served at full DSLR resolution (use AVIF + WebP at appropriate dimensions)
- Client-side rendered hero (React/Vue/Angular delays LCP element until JS executes)
- Custom fonts blocking text-based LCP (use font-display: swap)
FAQ.
Is my LCP element always an image?
Usually but not always. Can be a heading, a large text block, a video poster image, or a CSS background-image. Use Chrome DevTools Performance panel to identify your actual LCP element.
What's the difference between LCP and FCP?
FCP (First Contentful Paint) is when ANY content first appears. LCP is when the LARGEST content element finishes rendering. FCP is usually earlier (200-800ms); LCP comes later and is the more meaningful metric.
How do I improve LCP?
Optimize the LCP element first: compress hero images to AVIF + WebP, preload them, serve at appropriate dimensions, use fetchpriority='high'. Then reduce TTFB (server response time), reduce render-blocking resources (defer non-critical CSS/JS), and use a faster hosting platform.
Does using Cloudflare help LCP?
Sometimes — it can speed up TTFB via edge caching. But Cloudflare adds a TLS handshake and potentially adds 50-200ms latency for the first request. For most small sites, direct hosting with a good CDN-free setup matches or beats Cloudflare.
What if my LCP is 3 seconds — is that bad?
Yes — fails 'Good' threshold (2.5s). Falls in 'Needs Improvement' (2.5-4s). Above 4s = 'Poor'. Google's Page Experience signal docks pages that fall into 'Needs Improvement' or 'Poor.'
Maintained by Joseph W. Anady at ThatDeveloperGuy. Back to glossary · Suggest a term