LCP Above Target, Why the Main Content Takes Too Long to Appear

LCP above target. That is the flag when the largest piece of content on a page takes longer than 2.5 seconds to appear, and LCP stands for Largest Contentful Paint, one of the three Core Web Vitals that search engines treat as the real measure of a page’s speed. The report names the metric, the measured value, and the device it failed on, because the same page can pass on desktop and fail on mobile. If the report layout is new to you, the guide to reading an Enterramon test walks through every section.

The largest contentful element is usually the hero image, a large heading, or a video poster, the first thing a visitor sees that tells them the page is actually loading. LCP measures when that element finishes rendering. A page can load every background script and still feel slow if the main content sits behind them, which is why LCP is the metric that best matches the human experience of waiting for a page.

What LCP measures

The check looks at the largest visible element as the page loads and times when it finishes rendering. The target is 2.5 seconds, and the report flags the metric when it passes that. Past 4 seconds the finding escalates, because at that point the main content is taking so long that a large share of visitors will have left before it appears.

It is measured in a real browser, on a throttled connection that mimics a mid-range mobile device, which is why a site that feels instant on a fast office connection can still flag. The throttle is deliberate, it shows how the page performs for the visitor who is not on a gigabit line with an empty cache, and that visitor is most of the real world.

Our own benchmarks show how close the average site is to the line. Across every test on the global analytics page, the average Largest Contentful Paint sits at roughly two seconds on both desktop and mobile, and the slowest ten percent of pages run past 3.6 seconds, deep into the failing zone. The finding is not an edge case, a large share of tested sites live on or past the target, which makes LCP the metric most worth fixing when your report flags it.

The score and the metric

LCP is one of the heaviest components of the performance score, worth more credit than most other checks, because it is the single best predictor of whether a visitor stays. When LCP is inside target the page earns the full credit, between target and the outer limit it earns partial credit, and beyond the outer limit it earns none. The finding appears whenever the page misses the full credit.

That makes LCP the metric most worth chasing when the report flags it. A slow LCP usually points at one of three things, a heavy hero image that has to download before it can show, render-blocking scripts and stylesheets sitting ahead of the content, or a slow server response delaying everything that follows. Fix the specific cause and LCP moves, which is why the finding carries its own diagnosis rather than a generic slow page warning.

Finding the element that takes the blame

The first step is knowing which element is the largest contentful one, because fixing the wrong element fixes nothing. The report and the browser developer tools both name it, usually the hero image or the main heading. Once you know what it is, the fix splits into three routes that map to the three common causes.

If the element is an image, make it arrive sooner. A plain image tag is discovered by the browser’s own HTML scanner early in the load, so the usual bottleneck is either the download itself or render-blocking stylesheets ahead of it, while a hero image served as a CSS background only starts loading once the stylesheet that names it has been fetched and parsed. Serve the image in a modern format at the size it actually displays, and remove anything render-blocking that sits ahead of it. If the element is a heading or text block, the delay is almost always the server or the render-blocking resources in front of it, which points at the other two routes.

The three fixes in practice

Fix the image first. The hero image is the usual LCP element. The simplest boost is fetchpriority high on the image tag itself, which tells the browser to prioritise this image in its fetch queue over everything else, and modern browsers respond to it faster than to a separate preload hint. Add it to the hero image and make sure the image does not carry loading lazy, because lazy loading deliberately defers the fetch until the image is near the viewport, which directly fights everything LCP wants.

    <img src="/images/hero.webp" width="1600" height="900" fetchpriority="high">

If the page also uses a preload hint, a responsive image needs more than a plain href. When the hero image has srcset and sizes for different screens, preload it with imagesrcset and imagesizes instead, because a plain href makes the browser fetch one fixed image and then fetch again when it works out which srcset candidate it needs, doubling the download of the biggest asset on the page.

    <link rel="preload" as="image"
          imagesrcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
          imagesizes="100vw">

Then remove render-blocking weight. Scripts and stylesheets that load before the content delay everything behind them. Defer scripts that do not need to run immediately, inline the critical CSS that styles the above-the-fold content, and move third-party tags off the critical path. Every kilobyte of blocking weight ahead of the hero image is milliseconds added to LCP.

Then check the server. If the image is small and nothing blocks it, the delay is the response itself. A slow Time to First Byte pushes every other metric back, because the browser cannot fetch the image until the server answers. Edge caching, origin optimisation, and removing redirects all shorten the path, and the report flags that route separately when it is the cause.

If the site is WordPress, none of the code above is something you type, and little of it should need to be. Current WordPress marks the first image in the page content as high priority on its own, so a hero image added as an image block usually gets the fetchpriority boost without help, and the block itself offers the stored image sizes, so pick the one closest to the width it shows at instead of full size. The middle route is what a caching or optimisation plugin does for you, with settings for deferring scripts and generating critical CSS, but change those one at a time and test, because a setting that defers everything can break sliders and forms. Page caching is the WordPress form of the server fix, either from your host or the same plugin, a CDN layer in front of the site, which many hosts include or offer free, serves the heavy files from the nearest edge instead of the origin, and the TTFB finding in your report will say if that is the route you actually need.

Watching LCP come down

Re-test after each change, because LCP responds fast when the cause is real. The report gives the measured value every run, so you can watch it fall toward the 2.5 second line and past it. This site is the proof that the fixes work. After we trimmed the heaviest assets and removed a duplicated script library, our own largest content dropped to under a second on both desktop and mobile, and the LCP finding disappeared from the report.

LCP and total page weight move together, so the fixes here overlap with the performance work covered across the other guides in this series. Trim the heavy files, remove the duplicates, and the main content appears sooner, which is the visitor experience the metric exists to measure.