What LCP actually measures
Largest Contentful Paint marks the moment the biggest element in the viewport finishes rendering — usually a hero image, a background image, a video poster, or a large block of text. It's Google's proxy for "when does the page look loaded to the person waiting on it." The threshold for a good score is 2.5 seconds at the 75th percentile of real visits; 2.5–4s is "needs improvement," and past 4s is poor.
The 75th-percentile part matters and trips people up. Your own fast connection loading a warm cache is not the number Google grades. The field data in the Chrome UX Report — real Chrome users, slower devices, worse networks — is what feeds rankings. A page that scores 1.8s in Lighthouse on your laptop can still fail LCP in the field. Always confirm against field data, not a single lab run.
Find the element that's actually slow
Before changing anything, identify which element is the LCP. Open Chrome DevTools, go to the Performance panel, record a load, and look for the "LCP" marker on the timeline — it names the exact node. In Lighthouse, the "Largest Contentful Paint element" audit does the same. Nine times out of ten it's one of these: a hero image loaded late, a web font that delays a text block, or a slow server response that pushes everything back.
That last one is the quiet killer. LCP can't happen before the HTML arrives, so a slow Time to First Byte caps your best possible LCP no matter how you optimize the image. If your TTFB is 1.2s, you've spent half your budget before a single pixel paints. Fix the server response first — caching, a CDN, faster queries — then optimize what renders.
The four fixes that move LCP most
1. Preload the LCP image. The browser discovers the hero image late because it's buried in CSS or lazy-loaded. Tell it early:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
And never lazy-load the LCP image — loading="lazy" on the hero is one of the most common self-inflicted LCP failures. Lazy-load everything below the fold, load the hero eagerly.
2. Serve the right image format and size. A 1.5 MB PNG hero is a guaranteed fail on mobile. Convert to WebP or AVIF, and serve responsive sizes so phones don't download desktop-resolution art:
<img src="/hero.webp" srcset="/hero-800.webp 800w, /hero-1600.webp 1600w"
sizes="100vw" width="1600" height="900" fetchpriority="high" alt="Product dashboard">
The width/height attributes do double duty here — they also prevent the layout shift that would hurt your Cumulative Layout Shift score.
3. Kill render-blocking resources. CSS and synchronous JavaScript in the <head> block the browser from painting. Inline the critical CSS, defer the rest, and add defer to scripts. This is a whole topic on its own — the mechanics are covered in fixing render-blocking resources, and the analyzer flags every blocking file on your page.
4. Fix font-driven text LCP. When the largest element is text, a slow web font delays it. Use font-display: swap so text renders immediately in a fallback, and preload the font file:
@font-face {
font-family: 'Inter';
src: url('/inter.woff2') format('woff2');
font-display: swap;
}
What good looks like after the fix
A typical content page that started at 4.2s LCP — slow TTFB, a huge unoptimized hero, a render-blocking stylesheet — lands around 1.8–2.2s after: edge-caching the HTML, converting the hero to a sized WebP with fetchpriority="high", and deferring non-critical JS. None of these are exotic; they're the same handful of levers on almost every site. LCP is one of the three Core Web Vitals, and it's usually the easiest of the three to move because the cause is almost always a single identifiable element.
Re-test in the field after deploying, and give it 28 days — the Chrome UX Report is a rolling 28-day average, so the field number lags your fix by up to a month even when the lab score improves immediately.
FAQ
Q: Why does my LCP pass in Lighthouse but fail in Search Console? A: Lighthouse is a lab test on your machine; Search Console reports field data from real Chrome users on slower devices and networks (the 75th percentile). Always trust the field number for ranking purposes, and remember it's a rolling 28-day average, so it updates slowly after a fix.
Q: Can lazy loading hurt LCP?
A: Yes — lazy-loading the largest above-the-fold element (usually the hero image) is one of the most common causes of poor LCP. Load the LCP element eagerly with fetchpriority="high" and only lazy-load images below the fold.
Q: Does TTFB affect LCP? A: Directly. LCP can't occur until the HTML is delivered, so a slow Time to First Byte sets a floor on your LCP. If your TTFB is high, fix the server response with caching and a CDN before optimizing the rendered content.
Q: What's the target for a good LCP? A: 2.5 seconds or less at the 75th percentile of real page loads. Between 2.5 and 4 seconds needs improvement, and above 4 seconds is poor.