Largest Contentful Paint: what delays it

Largest Contentful Paint (LCP) is the time it takes for the largest element visible on screen, often the main image or the headline, to appear after the page starts loading. Google rates it good up to 2.5 seconds and poor beyond 4.

That time splits across four steps: the server response, finding the image, downloading it, then drawing it on screen. Knowing which step runs long tells you where to look. It is one of the things our audit measures on website speed.

What LCP measures, exactly

According to web.dev, the element can be an image, a background image, the first frame of a video or a block of text, as long as it sits in the visible part of the screen. The clock starts when the visitor opens the page.

The visible part of the screen differs between a phone and a desktop, so the element measured can change from one device to the other. Google recommends judging LCP on three out of four visits, with phones and desktops counted separately.

Where the time goes before the content shows

web.dev splits LCP into four steps, and gives the share of time each one should take on a healthy page.

The server response, about 40% of the time. Redirects, the connection, then the server building the page. Slow hosting, or a page rebuilt on every visit, adds up here.
The delay before the image starts downloading, under 10%. It grows when the image is only referenced deep inside a stylesheet or a script, or when it is lazy-loaded even though it is visible right away. web.dev is blunt about it: never lazy-load the main image.
Downloading the image, about 40%. Its weight, its format, its size compared with the screen, and the server it comes from: an image served from another domain needs an extra connection first.
Drawing it, under 10%. The image has arrived but is not shown yet, because stylesheets or scripts are blocking rendering. When the element is a headline, a font that has not arrived yet can keep it invisible.

This split is a reference point: if the server response takes most of the time on its own, a lighter image will not be enough.

What we find on the sites we audit

35%have an LCP above 4 seconds, in the range Google rates as poor

This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.

This figure uses real-visit data when Google publishes it for the site, and our own measurement under mobile conditions otherwise.

Field data and lab data measure different things

Field data comes from real visits. Google publishes it in the Chrome UX Report, collected from Chrome users' browsers, and only for sites with enough visitors to form a reliable sample. Many small sites are not in it.

A lab measurement loads the page under fixed conditions: the same simulated device and the same network on every run. It can be repeated, and it exists for every site. What it misses are the redirects and slow connections some visitors run into, which is why web.dev itself notes gaps between the two.

Our audit does both. Each page in scope is measured in a browser throttled to match a typical phone on an ordinary network, and the score rests on those measurements. When Google publishes field data for the site, the report shows it side by side, and the 4-second threshold for the whole site is judged on it.

What the audit checks around LCP

A slow LCP is a result. The report also records what explains it, so the fix targets the right step.

The LCP of each page in scope, on phone and on desktop.
Server response time, the first of the four steps.
Stylesheets, scripts and fonts that block display.
The weight, format and pixel width of images, compared with the size they are shown at.
Whether the page tells the browser about its main resource early, so it is not discovered late.

Short fixes, and fixes that take a project

When the time is lost on the image, the fix is often short: an image in the right format and at the right size, loaded right away instead of lazily, and announced to the browser in the page code.

When it is lost at the server, or when the content only appears once JavaScript has run, it takes a project: better-suited hosting, page caching, or a way of building pages that sends the content to the browser ready to display.

A slow LCP is often the symptom of a site that is slow everywhere. The guide on why a website is slow goes through the causes in the order a page meets them.

What this check doesn't tell you

We measure under our own conditions: one browser, a fixed phone profile, the pages in scope. We read field data when Google publishes it for your site; when it does not, the report says so.

LCP depends on what the page shows at the time of measurement. A visual that changes between visits, personalized content or a consent banner can change the element measured and the time recorded.

By Quentin Mathis, Z29K · updated September 28, 2026