Largest Contentful Paint (LCP) is the Core Web Vital for loading. It records the time from when the user starts loading a page to when the largest image, video poster or text block visible in the viewport finishes rendering. Google rates LCP as good at 2.5 seconds or less and poor above 4 seconds, measured at the 75th percentile of real visits.
What counts as the LCP element
Candidate elements include img elements, image elements inside SVG, video poster images (and the first frame of a video, in recent Chrome versions), elements with a background image loaded through CSS url(), and block-level elements containing text. The browser keeps updating the candidate as larger elements render, and stops once the user interacts.
On SaaS homepages the LCP element is usually the hero image or product screenshot, or the hero headline when there is no large image.
The four parts of LCP
web.dev breaks LCP into subparts, which is the most useful way to find the slow step.
- Time to First Byte: how long the server takes to start responding
- Resource load delay: time between first byte and the browser starting to fetch the LCP resource
- Resource load duration: how long the LCP image or font takes to download
- Element render delay: time between the resource finishing and the element painting
Common fixes
Make the LCP resource discoverable in the initial HTML, not injected later by JavaScript. Do not lazy-load the hero image. Give it fetchpriority="high" and serve it in a modern format at an appropriate size. Reduce server response time with caching or a CDN. Keep render-blocking CSS and JavaScript small, and avoid client-side rendering for above-the-fold content.
<!-- Hero image: eager, high priority, sized -->
<img
src="/img/dashboard-hero.avif"
width="1200" height="720"
fetchpriority="high"
alt="Product dashboard showing pipeline by stage" />Framework notes
Image components in frameworks such as Next.js can set priority or preload hints for above-the-fold images, but they need to be told which image is the hero. Client-rendered pages often have long element render delay because nothing paints until JavaScript loads, so rendering hero content on the server usually helps LCP.
Example
A hero screenshot loaded by JavaScript
A fictional analytics SaaS, Chartwise, renders its homepage hero, including a large product screenshot, in a client-side React component. Field LCP on mobile is well above the 2.5 second threshold. The subpart breakdown shows most of the time is resource load delay: the browser does not know about the image until the JavaScript bundle runs.
Rendering the hero on the server, putting the image in the initial HTML with fetchpriority="high", and serving a smaller mobile variant brings the image request forward.
Common mistakes
Lazy-loading the hero image
loading="lazy" on the LCP image delays it. Only lazy-load images below the fold.
Only compressing images
Compression helps load duration, but on many pages the bigger cost is load delay or server response time. Measure the subparts first.
Questions
Yes. Google assesses mobile and desktop field data separately, and mobile is usually harder to pass.
No. Only elements visible in the viewport are candidates.
Chrome DevTools' Performance panel and Lighthouse identify the LCP element in a lab run. PageSpeed Insights shows field LCP from CrUX alongside a lab diagnosis.
