Slow Largest Contentful Paint? Split the delay into four parts before you change anything

What the number measures and what counts as good

Largest Contentful Paint (LCP) is the time from the start of the page load until the largest piece of content in the first screen, often a hero image or a large heading, has been drawn. Google's guidance treats 2.5 seconds or less as good, assessed at the 75th percentile of page loads, so three out of four visits should be at or under that. A single slow-looking number does not say why. The same total can come from a slow server, a late discovered image, a big file or a blocked paint, and each needs a different fix.

• Find the element first: public speed reports name the LCP element for the page.
• Decide which device profile matters most and measure on that.
• Repeat the measurement; one run is not evidence.

The four parts and what each one points to

web.dev splits LCP into four parts that add up to the whole. Time to first byte is how long before the first response byte arrives. Resource load delay is the gap between that and the moment the browser starts fetching the LCP resource. Resource load duration is how long the fetch takes. Element render delay is the gap between the resource arriving and the element being painted. Its approximate ideal shares are about 40% for time to first byte, under 10% for load delay, about 40% for load duration and under 10% for render delay, and it stresses they are guides relative to one another, not absolute times. The two delay parts should be close to zero, because the other two involve unavoidable work.

This tells you where to look. A long first-byte share points at the server, caching or redirects, not the image. A long load delay means the browser found the resource late. A long load duration means a large file or a slow connection to it. A long render delay means something blocked painting after the resource was ready.

• Chrome DevTools' performance insights, Lighthouse and PageSpeed Insights can show the breakdown.
• The web-vitals library's attribution build reports the same four parts from real visits.

Common misdiagnoses

Compressing an image does nothing if the delay is in the first byte or in discovery. If the hero image is added by JavaScript, set as a CSS background or held in a lazy-loading attribute, the browser's early scanner cannot see it, so the fetch starts late. web.dev says the resource should be discoverable in the initial HTML and, if only CSS or script refers to it, preloaded with high fetch priority. It also says never to lazy-load the LCP image, because that always adds load delay, and to give high priority to only one or two images or the hint stops helping. Serving the image from the same origin as the page avoids extra connection set-up.

• Hero image behind a slider script: check whether it is in the HTML.
• Image marked lazy: remove that for the first-screen image only.
• Everything marked high priority: that dilutes the hint.

A safe first investigation

Run the public page through a speed report on the mobile setting twice and note the LCP element and the four parts. Do the same for the desktop setting if desktop visitors matter. Check the page source for the element: is it an image in the HTML, a background, or created by script? Note whether the first response is slow, using the report's server response figure. Do not send logins or source code; the page address and the figures are enough to decide which part to fix.

• Long first byte: look at hosting, caching and redirects before images.
• Long load delay: look at discovery, priority and lazy loading.
• Long load duration: look at file size, format and the connection used.
• Long render delay: look at render-blocking styles and scripts.

What fixes it and how the paid job is accepted

The repair targets the part that is long and changes only what you control in templates, images, fonts and scripts. It does not change hosting or promise a ranking. Our one-page job (posted test price from £495, untested, quoted after we run the page) is accepted when the median of five lab runs on two agreed device and network profiles meets the agreed threshold for the chosen metric, the second profile is no worse, every agreed element still shows, and you sign off. Real-visitor data follows later and is not a condition of payment. Send the page address and the report in your first enquiry, not credentials.