Largest Contentful Paint
LCP / loading speed / hero image load / time to first byte
Largest Contentful Paint is the render time of the largest image or block of text visible without scrolling, measured from when the page starts loading. web.dev breaks it into four parts that add up with no gaps, and says time to first byte and resource load duration are usually about 40 percent each.
Mozilla defines it as the render time of the largest image or text block visible within the viewport, recorded from when the page first begins to load. It also lists what counts as contentful: image elements, images inside an SVG, the poster image of a video, anything with a background image, and groups of text nodes. In practice that means your hero image or your headline, whichever ends up bigger on screen.
The useful part is that the number is not a single thing. web.dev breaks every LCP into four subparts and is emphatic about the arithmetic: every page can have its LCP broken down this way, there is no overlap or gap between them, and together they add up to the whole. Time to first byte is the wait from the request until the first byte of the HTML arrives. Resource load delay is the gap between that and the browser starting to fetch the LCP resource. Resource load duration is fetching it. Element render delay is from the resource finishing to the element appearing.
Two of those four have the word delay in their names, and web.dev points out that this is a clue: those are the ones you want near zero. Its guideline proportions are time to first byte about 40 percent, resource load duration about 40 percent, and the two delays under 10 percent each.
It also says something that should keep anyone honest about the whole exercise. Those breakdowns are guidelines rather than strict rules, and if your LCP is consistently within 2.5 seconds, the relative proportions do not really matter.
In practice
This is what makes a performance quote checkable. If time to first byte is most of your LCP, the problem is the server or the hosting, and compressing images will not move it. If resource load duration dominates, the image is the problem and the server is fine. A proposal that does not say which subpart it is targeting has not looked.
Not the same as
- A page speed score
- That is one tool's summary. This is one measurement, made of four measurable pieces.
- Core Web Vitals
- That is the set of three. This is the loading one.
Why it matters to you
Website performance is sold with very little that a non-technical buyer can check, and this is the exception. The four parts are defined, they sum to the total with nothing hidden between them, and each one points at a different supplier. Server time is your host. Image weight is your build. Render delay is your code. Knowing which is dominant tells you who to talk to before anyone quotes for anything.
What to ask or check
- 01Which of the four subparts is the largest share of our LCP right now?
- 02Is our LCP already consistently under 2.5 seconds, in which case proportions do not matter?
- 03Does this proposal name the subpart it expects to improve?
What people get wrong
That a slow LCP means heavy images. Time to first byte is a guideline 40 percent of it, and web.dev is explicit that the four subparts cover the whole measurement with no gaps between them.
Red flags
- A performance proposal that never names which subpart it targets.
- Image optimization quoted for a page whose time to first byte dominates.
- Effort spent on proportions when LCP is already consistently under 2.5 seconds.
Who owns it
Split by subpart, which is the point. Time to first byte is the host, resource load duration is whoever builds the pages, and render delay is whoever writes the code.
Where you will see it
In PageSpeed Insights, in Search Console's Core Web Vitals report, and in the Chrome developer tools performance panel.