Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) is the time from when the page starts loading until the largest image or text block in the viewport is rendered. It is the closest single metric to the moment a visitor feels “the page has loaded.” LCP is one of the three Core Web Vitals.
The LCP element is usually a hero image, a large heading, a video poster image, or a block of text. It is whatever is largest on screen during load, so it can differ between mobile and desktop.
Why it matters
Until the main content appears, the page looks empty or unfinished to visitors, and many leave. LCP is also part of Google’s page experience signals, measured on real Chrome users. A slow lab LCP is a strong warning that real visitors on mobile see the same delay.
What we check
We read the LCP value from the Lighthouse mobile run in PageSpeed Insights:
| Result | LCP |
|---|---|
| Good | 2.5 s or less |
| Needs attention | over 2.5 s, up to 4 s |
| Poor | over 4 s |
These are the same thresholds Google uses for Core Web Vitals. Real-user LCP, when available, is covered in the field data guide.
Where LCP time goes
LCP time breaks down into four parts. Knowing which one is large tells you what to fix:
- Time to first byte: the server responds with the HTML.
- Resource load delay: the time before the browser starts downloading the LCP image. This is large when the image is discovered late, for example when it is set from JavaScript or a CSS background.
- Resource load duration: downloading the image itself. Large, unoptimized files make this slow.
- Element render delay: the image is ready but cannot be painted yet, usually because of render-blocking CSS or JavaScript.
For text-based LCP elements, only the first and last parts apply, plus web font loading.
How to fix
Make the LCP image discoverable in the HTML. Use a normal <img> tag in the server-rendered
markup instead of injecting it with JavaScript. Do not lazy-load it, and give it a high fetch
priority:
<img
src="/hero-1200.avif"
srcset="/hero-800.avif 800w, /hero-1200.avif 1200w"
sizes="100vw"
width="1200"
height="600"
fetchpriority="high"
alt="..."
/>
If the hero is a CSS background image, preload it so the browser can fetch it early:
<link rel="preload" as="image" href="/hero-1200.avif" fetchpriority="high" />
Shrink the image. Serve AVIF or WebP, size it for the slot it fills (use srcset and sizes),
and compress it. A hero image rarely needs to be more than a few hundred kilobytes.
Remove render-blocking resources. Inline the CSS needed for the first screen, load the rest
without blocking, and add defer to scripts:
<script src="/app.js" defer></script>
Speed up the server. A slow first byte delays everything else. See the server response time guide.
Serve images from your own origin or a fast CDN. Each extra origin costs a DNS lookup and a
connection. If the LCP image must come from another host, add
<link rel="preconnect" href="https://images.example.com">.
Watch your web fonts when the LCP element is text. Use font-display: swap (or optional) so
text shows in a fallback font instead of staying invisible while the font downloads.
Common mistakes
- Adding
loading="lazy"to the hero image. Lazy loading delays the LCP image on purpose. - Image sliders and carousels that render the first slide with JavaScript.
- Client-side rendered pages where the content only appears after a large bundle runs.
- A cookie banner or modal large enough to become the LCP element itself.