Largest Contentful Paint (LCP) – what it measures, thresholds and fixes in Webflow, Next.js and Astro

Definition

LCP (Largest Contentful Paint) is a web performance metric in Core Web Vitals that measures how long it takes for the page's largest visible element – often the hero image or the heading – to render. Under 2.5 seconds counts as good, over 4 seconds as poor.

Of Google's three Core Web Vitals, Largest Contentful Paint (LCP) is the one the visitor notices first: the moment the most important content on the page becomes visible. The metric has nothing to do with the healthcare term LCP (Liverpool Care Pathway); here it is purely about websites and web performance.

What is LCP and why is it a Core Web Vital?

LCP is one of three metrics in Core Web Vitals, together with INP (interactivity) and CLS (visual stability). Google chose LCP as the measure of perceived load time because it captures what the visitor actually notices: when the most important content appears. Older metrics such as "load" or "DOMContentLoaded" could show green numbers even though the screen was blank for several seconds.

Core Web Vitals are part of Google's assessment of page experience and are a ranking signal, albeit a weak one compared with the relevance of the content. The business effect is often bigger than the SEO effect: a website that shows its content quickly loses fewer visitors before they have had a chance to see the offer. We cover how performance fits in with the rest of the technical foundation in our website checklist for 2026.

Which LCP values count as good and poor?

According to web.dev, there are three levels: an LCP of at most 2.5 seconds is good, 2.5–4 seconds needs improvement and over 4 seconds is poor. The threshold is assessed at the 75th percentile of real page loads, so three out of four visits have to come in at 2.5 seconds or less for the page to pass. Mobile and desktop are assessed separately, and it is almost always the mobile value that fails a page.

It is important to keep two data sources apart. Field data from the Chrome User Experience Report (CrUX) shows how real visitors experience the page over the last 28 days and is what you see in GSC. Lab data from PageSpeed Insights and Lighthouse is a simulated load on a predefined device. Field data decides whether you pass; lab data helps you find the cause.

What counts as the LCP element on a page?

The LCP element is the largest visible content element within the viewport during loading. Candidates are images (<img> and <image> inside SVG), the poster or first frame of a video, elements with a background image via CSS url(), and block elements containing text. Size is measured as the visible area; parts outside the viewport do not count. Images with very low information density, such as single-colour placeholders or gradients, are disqualified as candidates.

On most company websites, the LCP element is the hero image or the H1 heading. You can see which element the browser chose in PageSpeed Insights under "Diagnostics" or in Chrome DevTools under the Performance tab. Check this first – many people spend time optimising the wrong image.

What causes slow LCP – and how do you find the cause?

Slow LCP is almost always down to one of four things: a slow server response, render-blocking CSS or JavaScript, large unoptimised images, or content that is rendered on the client only after JavaScript has run. Chrome splits the time up to LCP into four parts, and measuring them separately shows where the problem lies. The method is described in the Chrome DevTools documentation, and the guideline values for how the budget should be split are in web.dev – Optimize LCP.

• Time to First Byte (TTFB): the time until the browser receives the first byte of HTML from the server. Guideline: about 40 per cent of the total budget.
• Resource load delay: the time from TTFB until the browser starts fetching the LCP resource. Should be close to zero – lazy loading, or the image existing only in CSS or JavaScript, are typical reasons why it grows.
• Resource load duration: how long the actual download of the image takes. Guideline: about 40 per cent of the budget. Determined by file size, format and CDN.
• Element render delay: the time from the resource being fetched until the element is rendered. Grows when CSS, web fonts or JavaScript block rendering.

A key lesson from the breakdown: if TTFB alone takes 2 seconds, no amount of image compression will help. Start with the biggest part. There is more on how performance interacts with indexing and crawlability in our guide SEO audit 2026 – how to do one step by step.

How do you fix LCP in Webflow, Next.js and Astro?

The fixes are essentially the same – make the LCP element small, let the browser find it early and do not block rendering – but the tools differ between platforms.

Webflow. The most common cause of slow LCP in Webflow is that every image gets loading="lazy" by default, including the hero image. Lazy loading on the LCP element delays the fetch and needlessly increases the resource load delay. Set the hero image's loading mode to "Eager" in the image settings and add fetchpriority="high" as a custom attribute or through custom code, so that the browser prioritises that particular resource. Compress the hero image and deliver it as WebP – Webflow serves WebP automatically to browsers that support it, but a 4,000-pixel-wide original image is still heavy. If you want to go further and use AVIF, you do that manually through the compression tool in the Assets panel. If the LCP element is a heading rather than an image, the web fonts are what matter: self-host them or use font-display: swap so the text is not kept invisible while the font loads.

Next.js. The next/image component sets width and height automatically and lazy-loads by default. On the LCP image you set loading="eager" and fetchPriority="high", according to the Next.js documentation. In Next.js versions before 16, the priority property did the same thing in one step; it is now deprecated. Also make sure the hero section is rendered on the server (statically or via SSR) so that the image is in the HTML response from the start. A hero that only appears after client-side JavaScript has run results in poor LCP, whatever the image size.

Astro. Astro delivers static HTML without JavaScript by default, which is a good starting point for LCP. The image component from astro:assets optimises format and sets dimensions, but also lazy-loads by default – so set loading="eager" and fetchpriority="high" on the LCP image (the attributes are passed on to the image element); see Astro's image guide. Avoid putting the hero content in a client component with client:load unless it has to be interactive.

Whatever the platform, check the field data again after the fix. The lab value in PageSpeed Insights changes immediately, while the CrUX value in GSC needs up to 28 days to reflect the change. LCP is part of technical SEO, but rarely the whole explanation when a page is not showing up in search – we cover more causes in Website not ranking? 10 causes.