Largest Contentful Paint

Largest Contentful Paint (LCP) is the measurement of when the main content of a page appeared. The browser watches the visible area as the page loads. It identifies the single largest piece of content inside it, and records the moment that element finished rendering. Google publishes 2.5 seconds as the LCP threshold, taken from web.dev and checked on 3 August 2026. The internal LCP target used on this site’s own builds is 2.0 seconds, for headroom rather than for pride.

LCP is the one metric a business owner can verify by eye. Load your own site on your own phone, on mobile data, away from the office wifi, and count. If you finish counting before the page fills in, you have the answer that matters.

What LCP element and LCP image is usually the culprit

On an ordinary Australian small-business site, the LCP element is one of a very short list:

• The hero image. A full-width photograph at the top of the home page or a service page. This is the answer most of the time.
• A background image applied to the hero section rather than placed as an image. It counts, and it is harder to optimise because browsers discover it later.
• The headline block, on pages with no large image, where a heading and a paragraph of introductory text form the largest content element.
• A video poster frame, which is an image standing in for a video until it plays.
• A slider or carousel, which is often the worst case, because it loads several large images when only one is visible.

Knowing which LCP element it is matters, because the fix is completely different for each. Optimising the whole site because a report said LCP is slow is how a fortnight of work gets spent on the wrong thing.

The usual causes of a slow LCP

Four things dominate, and they compound.

The image is far larger than it is displayed at. A photograph straight off a camera or a stock library is often several thousand pixels wide and is being shown in a space a fraction of that size on a phone. The browser downloads every one of those pixels and then discards most of them. This is the single most common cause and also the cheapest to fix. It is covered properly in images and formats.

The browser finds out about the image late. A page is discovered in stages. The browser fetches the HTML, reads it, discovers it needs a stylesheet, fetches that, and only then discovers that the stylesheet references a background image. Every one of those steps is a round trip. An image referenced directly in the HTML is discovered immediately; an image referenced from a stylesheet, or injected by JavaScript after the page loads, is discovered several steps later. Same file, considerably slower.

Something is blocking rendering ahead of it. Stylesheets and scripts in the head of the document must be fetched and processed before the browser is permitted to paint anything. If a page pulls in a large stylesheet, several font files and a tag manager before it is allowed to draw, the hero image cannot appear no matter how small it is.

The server is slow to answer. Every millisecond the server spends assembling the page before the first byte leaves is a millisecond added to every metric downstream. This is where hosting genuinely does matter, and it is the subject of hosting and speed.

A fifth, less common but worth naming: lazy-loading applied to the hero image. Lazy loading is a good technique for images below the fold. Applied to the element at the top of the page, it deliberately delays the exact thing being measured. Some page builders and plugins apply it to everything by default. It is a one-setting fix that a supplier can make in minutes once someone points at it.

How to find yours: LCP metric loading tools including Lighthouse and DebugBear

Two tools, both free, and they answer different questions. Both PageSpeed Insights and the Lighthouse panel built into Chrome’s DevTools run the same underlying Lighthouse engine, so a score checked one way should roughly agree with the other. Paid monitoring services such as DebugBear track the same metric continuously across many pages rather than one address at a time. That is worth the subscription once a site is large enough that checking pages one by one stops being practical.

PageSpeed Insights will tell you which element it identified, by name. Enter your address, choose the mobile view, and look for the LCP element in the diagnostics. It will show you the actual file or the actual text block. It also breaks the LCP timing into phases: how long the server took, how long before the resource started loading, how long the download itself took, and how long between the download finishing and the pixels appearing. That breakdown is the fastest way to work out which of the four causes above is yours.

The Core Web Vitals report in Google Search Console will tell you whether real visitors are experiencing the problem, and on which group of pages. PageSpeed Insights tests one address once; Search Console reports what happened to actual people across the site. If Search Console says a template of forty service pages is failing, the fix is in the template, not on any one page.

The practical order is: Search Console to find out whether there is a problem worth money, then PageSpeed Insights on a representative page to find out what it is. Doing it the other way round produces a to-do list detached from anything a customer noticed. The full walkthrough is in how to test your own site.

What to hand a supplier: LCP score, fetchpriority and preload fixes

Not a screenshot of a score. Send the address you tested, the identified LCP element, the LCP phase breakdown, and the Search Console field figures for mobile. Ask which of the causes above applies, what the fix is, and whether it is a one-off change or a template change. Two of the standard, concrete fixes are worth naming by name rather than left as a vague “optimise it”. A fetchpriority="high" attribute on the LCP image tells the browser to fetch it before other, lower-priority resources. A preload hint in the document head gets a background or stylesheet-referenced image discovered as early as an ordinary <img> tag. Ask for the figure to be re-measured on real traffic a month after the change rather than in a lab immediately after it.

Where this sits in a build — who is responsible for the image pipeline, the render path and the server response — is set out on web development services. The vocabulary is in the glossary.