Short answer: Largest Contentful Paint (LCP) reports when the largest image, text block or video visible in the viewport is rendered, counted from when the visitor started navigating to the page. A good LCP is 2.5 seconds or less, measured at the 75th percentile of page loads.
What counts as the LCP element
The candidates are img elements, image elements inside an svg and videos. For a video, its poster image or first frame counts, whichever comes first. A background image loaded with url() also counts, though a CSS gradient doesn’t. So do block-level elements that contain text.
In Chromium-based browsers, LCP leaves out elements with an opacity of 0, elements that cover the full viewport and look like a background, and low-entropy placeholder images. Google tools don’t report LCP for pages loaded in a background tab.
The four subparts of LCP
Every LCP time breaks down into four subparts with no gap or overlap between them, and together they add up to the full LCP.
| Subpart | What it measures | Share on a well-optimized page |
|---|---|---|
| Time to first byte | From the start of the page load to the first byte of the HTML | About 40% |
| Resource load delay | From the first byte to when the browser starts loading the LCP resource | Under 10% |
| Resource load duration | How long the LCP resource itself takes to load | About 40% |
| Element render delay | From the end of that load until the LCP element is fully rendered | Under 10% |
From web.dev, “Optimize Largest Contentful Paint”, read November 3, 2026.
The two subparts with “delay” in their name should be as close to zero as possible. If the LCP element is text in a system font, nothing has to load, so the resource load delay and duration are zero.
How to improve LCP
- Find your LCP element in the lab results of PageSpeed Insights, which come from Lighthouse.
- If it’s an image, make sure the browser can find it in the HTML, or preload it if only a CSS or JavaScript file points to it.
- Give that image a high fetchpriority so it starts loading early, and keep it for one or two images at most.
- Never lazy-load the LCP image.
- Make the image smaller, for example in WebP or AVIF, and serve it close to your visitors.
- Don’t hide the LCP element until JavaScript runs, and reduce or inline the stylesheets that block rendering.
- Lower your time to first byte, which affects every step after it.
Our guides to lazy loading images, WebP and TTFB go deeper into steps 4, 5 and 7.
What LCP looks like on our pages
On November 3 we ran 4 of our pages through PageSpeed Insights on mobile: the home page, the SEO service page, SEO in Miami and the robots.txt guide. All 4 had an LCP of 1.2 seconds in the lab test, well under the 2.5-second mark. LCP also counts the unloading of the previous page, connection setup and redirects. For real visitors these can weigh more, so field and lab results can differ.
On all 4, the LCP element was text: a headline or a paragraph, not an image. Lighthouse's breakdown showed no resource to load. So element render delay ran from the first byte of the HTML until the text was painted: between 98% and 100% of the breakdown.
So on our pages, a faster LCP has to come from that render delay, not from images. Our Core Web Vitals guide explains how LCP sits next to INP and CLS.
Before you call your LCP fixed
- You know which element is the LCP element.
- The LCP image isn’t lazy-loaded.
- The browser finds the image in the HTML.
- The image is compressed and the right size.
- Nothing hides the element until scripts run.
- Field data shows 2.5 seconds or less.
RememberLCP is four times added together: the first byte, the wait before the resource loads, the load itself and the render. Shrinking one only helps if the time doesn’t move to another, so look at all four.
If you want pages that load their main content fast on phones, see our web design service.
Quick answers about LCP
What is a good LCP?
web.dev rates 2.5 seconds or less as good. To meet it for most users, measure the 75th percentile of page loads, with mobile and desktop counted separately.
Can text be the LCP element?
Yes. Besides images, video and background images, block-level elements with text count. If the text uses a system font, nothing has to download for it, so the resource load delay and duration are zero. With a web font, the font can be the LCP resource.
Should I lazy-load my hero image?
Not if it’s your LCP image. web.dev warns never to lazy-load the LCP image, because it always adds resource load delay. Load it normally and, if it starts late, raise its priority with fetchpriority.
Why didn’t a smaller image improve my LCP?
Because the time can move to another subpart. web.dev shows a page where compressing the image cut the load duration, but the element stayed hidden until JavaScript ran, so the LCP didn’t change.
Do I need a perfect breakdown?
No. The shares are guidelines, not strict rules. If your LCP stays within 2.5 seconds, the proportions matter less; long delays are what make the target hard to hit.
Sources
Read on November 3, 2026. web.dev: Largest Contentful Paint (LCP) and Optimize Largest Contentful Paint. Our own case: 4 of our pages in PageSpeed Insights on mobile, November 3, 2026.