Improving LCP: Finding the Culprit Element and Fixing Slow Loading

Why Your Site's LCP Is Still Red

You've opened PageSpeed Insights, gotten a green score, but LCP is still above 4 seconds. Or worse: on mobile, LCP has exceeded 2.5 seconds and Google has warned you that your ranking is at risk. You don't know which element on the page is the culprit, which network request is holding it back, and where to start.

This article was written precisely for that moment. Not to define LCP, not to cover the history of Core Web Vitals. It's so that in the next ten minutes, you can find the culprit element and know the correct order to fix it.

Finding the LCP Element in DevTools

The first step is to accurately identify the exact element that Google has recorded as LCP. Without this identification, any optimization is blind. Chrome does this in two steps:

1. Open the page in Incognito mode so that cache and extensions don't ruin the results.
2. Press F12 and go to the Performance tab. Click the record button (circle icon), refresh the page, and stop recording after full load.

In the output, look at the Timings section. Find the Largest Contentful Paint event. Click on it to see the element details at the bottom. It's usually an image, an <h1> tag, or a video. That element is the main culprit.

The second method is using Google's Web Vitals extension. This extension shows the LCP value live in the toolbar, and clicking on it highlights the exact element. This method is more practical than DevTools for quickly checking multiple pages.

An important note: LCP differs across pages. The homepage might have an image banner, the product page a large photo, and the article page a text headline. Find the LCP element separately for each page type. An optimization that works for the homepage won't necessarily work for the product page.

This Is Where People Go Wrong

Most people mistake LCP for the largest image on the page. That's not correct. LCP refers to the largest visible element in the viewport, not the largest element on the page. If a 2000-pixel image is at the bottom of the page and a small text headline is at the top, the LCP element is that headline. The result of this mistake? Optimizing an image that has no effect on the score and confusion in the reports.

Four Common Causes of Slow LCP

After identifying the element, it's time to find the root cause. There are four main reasons that push LCP past the 2.5-second threshold. The order in which you check these four items is just as important as the items themselves.

1. Server Response Delay (High TTFB)

If Time to First Byte is above 600 milliseconds, the entire loading process is delayed from the start. Double-check this number in the Network tab: the TTFB value in the Time column is that initial number. If it's high, the problem is the server, not the image or font.

Solutions in order of priority: enable server-side caching (like Redis or Varnish), use a CDN to serve static content, and check heavy database queries. If your site is on shared hosting and your TTFB is above 1 second, it's probably time to migrate to a hosting service with dedicated resources.

2. LCP Image with Wrong Format and Dimensions

The image that is the LCP element shouldn't be served in PNG or BMP format. WebP format with proper compression is usually 30-40% smaller. For conversion, use tools like cwebp:

cwebp -q 80 input.png -o output.webp

In addition to format, check the dimensions too. If you have a 4000-pixel image that's displayed at 800 pixels wide on the page, 80% of its size is wasted. Save the image at exactly the display dimensions. For responsive images, use srcset so the browser only downloads the version appropriate for the screen.

3. Render-Blocking JavaScript

If your LCP element is a text headline but it's rendered with JavaScript, the browser must first download the script, execute it, and then display the text. This means at least one extra round trip. Check whether the main text can be static in the HTML instead.

For non-essential scripts, use defer or async. Scripts that aren't needed for initial rendering should be loaded with defer so they execute after HTML parsing. If you have a third-party script (like live chat or analytics tools) that isn't critical, load it with a 3-5 second delay.

4. Web Fonts with Hidden Display

Custom fonts that aren't loaded with display: swap keep text hidden until the font is downloaded. This means your LCP is tied to font download time. In your CSS, add the font-display: swap rule so the browser first shows text with the default font and then replaces it with the custom font.

Also use preload for the main font:

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

This tells the browser to start downloading the font from the very beginning, not after CSS parsing.

The Correct Order for Fixing LCP Issues

The order of fixes is just as important as the fixes themselves. A common mistake is that people first go for image compression while their TTFB is 2 seconds. The result? Spending hours optimizing something that solves only 20% of the problem.

My recommended order:

1. Get TTFB below 600 milliseconds. If this number is high, everything else is ineffective. Implement server-side caching, CDN, and check server resources.
2. Place the LCP element statically in the HTML. If it's rendered with JavaScript, move it to the initial HTML.
3. Optimize the LCP image. Add WebP format, exact dimensions, and fetchpriority="high".
4. Configure fonts with swap and preload.

After each step, measure with PageSpeed Insights or SEO and webmaster tools. If after the first step LCP drops below 2.5 seconds, do the remaining steps with lower priority.

Correct Measurement Is Half the Cure

Another common mistake: measuring LCP only on desktop. Google uses Field Data for ranking, which is collected from real users' browsers. This data differs from the Lab Data you measure yourself. Mobile users with weaker internet, weaker hardware, and 3G networks have a different experience.

For more accurate measurement, use Chrome DevTools with Slow 4G network simulation and 4x CPU slowdown. Apply these settings in the Performance tab under Network conditions. If LCP is below 2.5 seconds under these strict conditions, your real users will almost certainly have a good experience.

Also check domain and DNS technical reports. Sometimes the problem is DNS or network infrastructure, not your site's code. A slow-responding DNS directly increases TTFB.

Frequently Asked Questions

How do I know which element is my site's LCP?

In Chrome DevTools, go to the Performance tab, start recording, and refresh the page. After stopping the recording, find the Largest Contentful Paint event in the Timings section. Click on it to see the exact element at the bottom. You can also use Google's Web Vitals extension, which highlights the LCP element live.

Does LCP need to be under 2.5 seconds?

Yes, to get a green score in Core Web Vitals, LCP must be under 2.5 seconds in 75% of real user visits. Values between 2.5 and 4 seconds are yellow (needs improvement), and above 4 seconds are red (poor). Google uses field data from real users for this assessment, not just lab data.

What's the difference between LCP and FCP?

FCP (First Contentful Paint) measures the time of the first display of any content on the page, even a small text or a background. But LCP measures the display time of the largest visible element. FCP usually occurs earlier than LCP, and improving LCP doesn't necessarily lead to FCP improvement. Both metrics are important, but LCP has a greater impact on user experience.

Is removing the LCP image a good solution?

No. Removing the main image only causes the browser to choose the next largest element as LCP, which might be the same image in smaller dimensions or a text element. If the image truly isn't necessary for the page, removing it makes sense. But if it's essential, optimizing its format, dimensions, and loading will yield better results. Remember that LCP always exists; you can only make it faster, not remove it.