LCP Issue: Longer Than 2.5s (Mobile): What the Search Console Warning Means and How to Fix It

"LCP issue: longer than 2.5s (mobile)" means that for a group of similar pages on your site, more than a quarter of real mobile visits took longer than 2.5 seconds to show the main content. Search Console didn't run a test. It is reporting what actual Chrome users experienced over the last 28 days. That's why the warning often shows up on a site whose Lighthouse score looks fine.

Here is what the warning measures, why your own tests may not reproduce it, and how to find which part of the load is actually slow.

What the warning actually means

Search Console's Core Web Vitals report uses real-user data from the Chrome UX Report (CrUX). It sorts each URL into one of three LCP bands:

• Good: 2.5 seconds or less.
• Needs improvement: over 2.5 seconds, up to 4 seconds. This is "LCP issue: longer than 2.5s".
• Poor: over 4 seconds. This shows up as "LCP issue: longer than 4s".

Three details in how the report works explain most of the confusion:

1. It grades the 75th percentile, not the average. Google defines Group LCP as the time it takes for 75 percent of visits to a URL group to reach LCP. Your typical visit can be quick and the page still fails, if the slowest quarter of visits is slow enough.
2. It grades groups of pages, not single URLs. Search Console groups similar pages, such as all your product pages, and gives the whole group one status. The example URL it shows is one member of that group. That URL is not necessarily the slowest page in it.
3. Mobile and desktop are graded separately. A group can be Good on desktop and failing on mobile. The "(mobile)" in the label tells you which report you're in.

LCP is the metric more sites fail. According to the 2025 Web Almanac, 74 percent of desktop pages have a good LCP, but only 62 percent of mobile pages do. So if you see this warning, you're in a large group.

The threshold is still 2.5 seconds, by the way. A rumour that Google lowered it to 2 seconds is not true.

Why your own test probably passes

A Lighthouse or PageSpeed lab run is one simulated page load, on one device profile, from one location. Search Console's number comes from 28 days of real visits: cheaper phones, patchy mobile networks, first visits with nothing cached, and visitors who arrived from an ad with tracking parameters that skip your CDN cache.

Those slower visits are exactly the ones that end up in the 75th percentile. A green lab score tells you the page can be fast. It doesn't tell you it is fast for the quarter of visitors Google is grading. The full explanation of that gap is its own article.

Check the field data first. In PageSpeed Insights, the "Discover what your real users are experiencing" section at the top is CrUX data. The lab score below it is the simulation. If the top section fails and the bottom passes, trust the top one.

The four parts of LCP

Every LCP time is the sum of four sequential parts. Knowing which one is slow tells you what to fix. Google's definitions:

• Time to First Byte (TTFB): from the visitor starting the page load until the browser receives the first byte of HTML.
• Resource load delay: from TTFB until the browser starts downloading the LCP image.
• Resource load duration: how long the LCP image itself takes to download.
• Element render delay: from the image finishing until the element is actually painted.

Google's rough guideline is that TTFB and load duration should each be about 40 percent of your LCP, and the two delays should each be under 10 percent. The delays are pure waste: time when the browser could be working on your main content and isn't.

The real-world data says the delays are where poor sites lose. Looking at origins with poor LCP, Chrome's own analysis found median 75th-percentile times of:

Subpart	Median for poor-LCP origins
Time to First Byte	2,270 ms
Resource load delay	1,290 ms
Resource load duration	350 ms
Element render delay	360 ms

Look at the last three rows. These sites spent almost four times as long waiting to start downloading the LCP image as actually downloading it. Most image-compression advice targets the 350 ms row. The bigger problems are the server and the discovery delay.

Step 1: Find your slow subpart

You have two ways to see the breakdown:

• Field data: since February 2025, the CrUX API and CrUX History API report the four subparts at the 75th percentile, for origins or individual URLs. One limitation: they only cover pages where the LCP element is an image. That's most pages, though. The Web Almanac found the LCP element is an image on 76 percent of mobile pages.
• Lab data: the Chrome DevTools Performance panel has an LCP breakdown insight that splits a recorded load into the same four parts. Record with network and CPU throttling turned on, or you'll be measuring a load that's much faster than your visitors get.

Use the field data to pick the subpart, and the lab trace to see why it's slow.

Step 2: Fix a slow TTFB

If TTFB alone takes up most of your 2.5 seconds, nothing else on the page can save you. Common causes:

• No CDN, or HTML that bypasses it. Static assets are cached at the edge but every HTML request goes back to a single origin server, possibly on another continent from your visitors.
• Cache-busting query strings. Ad and email traffic arrives with utm_ or gclid parameters, and many caches treat each one as a new page. That traffic is mostly mobile and mostly first visits.
• Redirect chains. Every hop (http to https, bare domain to www, old URL to new) adds a full round trip before the HTML even starts.
• Slow server-side work. Uncached database queries, or personalisation that stops a page from being cached at all.

Step 3: Fix resource load delay

This is the most common avoidable problem. The browser can only start downloading an image once it knows the image exists. Anything that hides the image from the initial HTML adds delay:

• A lazy-loaded LCP image. Google is unusually blunt about this one: "Never lazy-load your LCP image." The 2025 Web Almanac still found 16 to 17 percent of pages doing it, often because a theme or plugin applies loading="lazy" to every image on the page.
• An image injected by JavaScript. If your hero image only appears after a JavaScript framework renders the page, the browser can't find it until that JavaScript has downloaded and run. A preload tag doesn't fully fix this. If the image is preloaded but the <img> is still rendered client-side and marked lazy, it still paints late.
• A CSS background image. The browser doesn't find it until the stylesheet has downloaded and been parsed.
• No priority hint. Add fetchpriority="high" to the LCP <img> so the browser downloads it before other images. Use it sparingly: Google notes that setting high priority on more than one or two images stops it helping. Only 17 percent of mobile pages with an LCP image use it.

The fix is the same in every case: put a plain <img> with a real src in the server-rendered HTML, don't lazy-load it, and give it fetchpriority="high".

Step 4: Fix element render delay

The image has arrived, but the page hasn't painted it yet. The usual causes are render-blocking CSS and JavaScript in the <head>, web fonts holding up a text LCP element, and client-side rendering. Google calls a large gap between TTFB and First Contentful Paint "a classic sign" of a site that relies heavily on client-side rendering. If you're on Shopify, render-blocking scripts in Liquid themes are the usual culprit. On WordPress, see fixing Core Web Vitals on WordPress.

Step 5: Validate the fix in Search Console

Once you've deployed a fix, open the issue in the Core Web Vitals report and start validation. Search Console then tracks the issue for 28 days. It counts as fixed only if no URL on your site shows it during that 28-day window.

So expect a slow feedback loop. Since CrUX is a rolling 28-day window, the warning can stay up for weeks after a fix that worked. Watch the trend in the CrUX History API or PageSpeed Insights field data rather than waiting for the status to flip.

The short version

1. Trust the field data. If Search Console says the page fails, a lab pass doesn't change that.
2. Find the slow subpart before changing anything.
3. Check the delays first. On poor-LCP sites, server time and the wait before the image starts downloading usually dwarf the download itself.
4. Make the LCP image discoverable: a plain <img> in the HTML, not lazy-loaded, with fetchpriority="high".
5. Validate and wait 28 days.

If you're also seeing the INP warning, fixing INP is a separate job, done on the main thread rather than the network. And if you'd rather have the slow subpart traced and fixed for you, that's what the performance fix service does.