Why Image Size Isn’t Usually the LCP Problem

Since Largest Contentful Paint (LCP) was introduced, the standard advice for improving it has been straightforward: make your images smaller. Compress them, resize them appropriately, serve modern formats. It’s easy to measure excess bytes and easy to implement fixes, and plenty of sites still serve needlessly large images. But when we looked at field data from real Chrome navigations to see where time actually goes during page loads, image download time was almost never the bottleneck.

Instead, the time between the initial request and when the LCP element finally renders is dominated by other parts of the loading sequence. To see where the real opportunities are, we broke LCP down into its four subparts and analyzed 75th-percentile (p75) values for origins in the CrUX dataset, then split those origins into “good,” “needs improvement,” and “poor” LCP buckets.

The Four LCP Subparts

Every page load can be divided into these phases:

  • Time to First Byte (TTFB): from the user initiating navigation until the browser receives the first byte of the HTML document.
  • Resource load delay: the time between TTFB and when the browser starts loading the LCP resource. If no resource is needed, this is 0.
  • Resource load duration: the time to download the LCP resource itself. Again, 0 if no resource is needed.
  • Element render delay: the time between the resource finishing and the element rendering fully.

For most pages, the LCP element is an image, so we focused on navigations with a subresource image LCP.

Download Time Is the Shortest Subpart

Looking at the p75 data, image load duration is the smallest component of LCP — in all three LCP buckets. It grows for origins with poor LCP, but even then it’s not where time is mainly spent. For the majority of origins with poor LCP, downloading the LCP image accounts for less than 10% of the p75 LCP time. No matter how aggressive your compression, the potential LCP gain is small for the typical origin.

Mobile networks were once blamed for slow image downloads, but that’s also shifting. For origins with poor LCP, the median p75 image load duration on mobile is only 20% slower than on desktop.

TTFB: A Mostly Physical Limit

Every network navigation includes some TTFB — DNS lookups, connection setup, and the round trip to the server can’t be eliminated. Even the median origin with good LCP spends more than half a second on TTFB at its p75. The gap between good and poor origins shows where the opportunity lies. For at least half of the origins with poor LCP, the p75 TTFB of 2,270 milliseconds alone makes it nearly impossible to hit the 2.5-second “good” LCP threshold.

You can’t beat physics, but a CDN can reduce the distance between users and your servers. More guidance is available in the Optimizing TTFB guide.

Resource Load Delay: The Overlooked Culprit

Unlike TTFB, resource load delay can practically be eliminated with the right serving architecture. It measures the time from the first byte of HTML until the browser actually starts requesting the LCP image. For years, the focus has been on download duration, but the delay before the browser even knows to start the download has been largely ignored.

The median site with poor LCP waits 1.3 seconds between TTFB and the image request — almost four times longer than it spends downloading the image. That’s more than half of the 2.5-second budget gone before the image request is even made.

Long dependency chains are a common cause. A simple example: a page loads a style sheet, layout happens, and a background image becomes the LCP element. Only after all those steps does the browser learn it needs to fetch the image. HTTP Archive crawl data shows a clear correlation between longer request chains and slower LCP.

The fix is to let the browser discover the LCP resource as early as possible. Use a standard <img> tag in the HTML so the preload scanner finds it quickly, or add a <link rel="preload"> tag or HTTP header for images that won’t be in <img> elements. If your page makes many requests early on, the browser often can’t identify the LCP element until layout. Annotating it with a fetchpriority="high" attribute — and avoiding loading="lazy" — signals to the browser to make the request immediately.

Render Delay: The Hidden Side Effect of Optimization

Render delay is the time between the LCP image being loaded and it actually appearing on screen. It can stem from a long main-thread task or from a UI decision to keep the element hidden. For the typical origin, this isn’t a huge opportunity — but optimizations elsewhere can shift time into this bucket.

If you preload the LCP image so it arrives quickly, you eliminate load delay, but the time will reappear as render delay if the page isn’t ready to display the image — say, due to a large render-blocking style sheet or a client-side rendering app that must load all its JavaScript first. This is why server-side rendering or static HTML often wins on LCP.

Measure All Subparts, Not Just Images

Optimizing LCP effectively requires looking at the full loading sequence, not just image bytes. Every segment of the timeline deserves attention, since the largest gains are usually elsewhere. The web-vitals library’s attribution build includes timings for all LCP subparts. The Chrome User Experience Report (CrUX) currently exposes TTFB and LCP, with more data planned. For local testing, the Web Vitals extension, the JavaScript snippet in the Optimize LCP article, and Lighthouse’s “Largest Contentful Paint element” audit all include the subpart breakdown. More LCP subpart tooling is also coming to the DevTools Performance panel.