Investigate a slow LCP

When LCP is slow, the reflex is to compress every image. Don’t start there. First find out which element is the LCP element, then find out where its time went.

Take a hero image. Between the moment the user hits Enter and the moment that image is on screen, the delay can hide in four places:

1. Time to first byte. The HTML itself arrives late, so nothing can start.
2. Resource load delay. The browser finds out about the image late, or gives it low priority.
3. Resource load time. The image is big or the connection is slow, so the download takes long.
4. Element render delay. The bytes are here, but the browser paints the image late.

Each one has a different fix, and fixing the wrong one wastes a day.

A slow first byte is a server or connection problem: slow backend, no CDN, no caching. A late discovery happens when the image URL hides inside a stylesheet as a background-image, or inside JavaScript that renders the page on the client. An <img> tag in the initial HTML gets found by the preload scanner in the first few kilobytes. A long load time is the one case where compression and modern formats help. And a render delay comes from something blocking paint after the image arrived: a big script, a font the browser is waiting for, or the image being hidden until some JavaScript runs.

Build the evidence chain

Here’s how I trace it in DevTools:

1. Open the Performance panel, check “Disable cache”, and record a reload.
2. Click the LCP marker on the timeline. DevTools shows you the element and, for an image, its URL.
3. Find that request in the Network panel. Look at when it started, its priority, its initiator, and how long it took.
4. Compare the moment the request finished with the LCP time.

Now the four cases separate themselves. Request started late? Fix discovery or priority: move the image into the HTML, or add fetchpriority="high" to the <img>. Request took long? Reduce bytes. Request finished early but LCP came much later? The problem is rendering, so look at the Main track between the two moments.

A quick experiment

Replace the LCP image with a tiny local file and record again. If LCP barely moves, image transfer was never the bottleneck, and no amount of compression would have helped.

Put the real image back and fix the delay the trace showed you.