Definition
Largest Contentful Paint (LCP) is a Core Web Vitals metric measuring the time from page load start to when the largest content element visible in the viewport finishes rendering. Google considers it the key load-performance signal for user perception of speed.
LCP is the single most-watched Core Web Vitals metric because it correlates strongly with perceived page speed. A site with great LCP feels fast; a site with poor LCP feels broken even if the rest of the load is fine. Google's threshold is 2.5 seconds — good below, needs improvement 2.5-4.0s, poor above 4.0s.
Most LCP problems trace to one of four causes: slow server response, slow resource load (large images, heavy JS), client-side rendering blocking paint, or render-blocking resources delaying the LCP element. Each has specific fixes; diagnosing which one is biting requires a Lighthouse trace or PageSpeed Insights run on the actual production URL.
Origin
LCP was introduced by Google's Chrome team in 2020 as part of the Core Web Vitals initiative, replacing earlier load-time metrics like First Meaningful Paint that didn't track perceived experience well.
How it works
- Run PageSpeed Insights or Lighthouse on the production URL.
- Identify the LCP element (usually a hero image or hero text block).
- Diagnose the bottleneck: TTFB, resource load time, or render delay.
- Fix the specific bottleneck — preload the LCP image, inline critical CSS, optimise server response.
- Re-measure; confirm LCP under 2.5s on real-device field data, not just lab data.
- Monitor field data (CrUX) over time — LCP drifts as content and dependencies change.
When to use it
Use when
- For every production website.
- Before any major rebuild or migration.
- After dependency updates that affect bundle size.
Skip when
- For pre-launch staging environments where the focus is functionality first.
- For internal tools where SEO and user-perception don't matter.
Key metrics
- 75th-percentile LCP from field data (CrUX)
- Lab LCP from Lighthouse
- LCP element identification
- % URLs in the 'Good' threshold
Examples
- The hero image was 1.8MB unoptimised. We compressed to 180KB and LCP dropped from 5.1s to 1.9s.
- The LCP element was being lazy-loaded — exactly the wrong element to defer. One config change fixed it.
- Our LCP looked great in lab tests and poor in field data. Real users were on slow networks the lab didn't simulate.
In practice at Makreate
Makreate website engagements treat Core Web Vitals as non-negotiable launch criteria. Every site we build ships with LCP under 2.5s on real-world conditions tested on mid-tier Android over throttled 4G — not just on a beefy laptop on fibre. The static-first architecture we default to (CDN-cached HTML, no SPA, image optimisation pipeline) makes hitting that threshold reliable rather than aspirational.
Website Development →Common mistakes
- Relying only on lab data — field data tells you what real users see.
- Lazy-loading the LCP element by accident.
- Shipping unoptimised images.
- Heavy JS frameworks that block paint.
- Not monitoring LCP over time — it drifts.
Frequently asked
What's a good LCP threshold?
Google's 'Good' threshold is under 2.5 seconds at the 75th percentile of field data. Aim for under 2.0s if you want headroom.
Does LCP affect SEO rankings?
Yes, modestly. Core Web Vitals are a ranking factor, but not as heavy as content relevance or links. Still, fixing LCP usually fixes other things too.
How do I find the LCP element?
Chrome DevTools Performance panel, PageSpeed Insights, or Lighthouse all flag it. It's usually a hero image, hero heading, or video poster.