How to improve LCP by optimizing images

What LCP is and why it depends on images

Largest Contentful Paint (LCP) measures how long it takes for the largest element visible in the viewport to render while the page loads. Google considers an LCP of 2.5 seconds or less at the 75th percentile of real visits good, and it's one of the three Core Web Vitals alongside INP and CLS.

On the vast majority of pages —homepages, product pages, articles— that element is an image: the main banner, the product photo or the post's featured image. So improving LCP almost always means improving how one specific image loads.

The four parts of LCP

LCP time can be broken down into four parts. Finding the longest one tells you what to optimize:

1. Time to first byte (TTFB): how long the server takes to respond with the HTML.
2. Resource load delay: time between TTFB and when the browser starts downloading the image.
3. Resource load duration: how long the image takes to download.
4. Element render delay: time between the download finishing and the image being painted.

Images mainly affect parts 2 and 3. A useful rule of thumb from Google: on a well-optimized page, the delay parts should be minimal and most of the time goes to TTFB and the download.

Step 1: find your LCP element

Before optimizing, confirm which element it is. There are several ways:

• PageSpeed Insights or Lighthouse: the "Largest Contentful Paint element" diagnostic shows the exact node.
• Chrome DevTools > Performance: record a load and look for the LCP marker on the timeline.
• Search Console > Core Web Vitals: shows groups of URLs with issues based on real-user data.

The LCP element can differ between mobile and desktop. Check both.

Step 2: let the browser discover it early

The most common mistake is that the LCP image isn't in the initial HTML: it's inserted with JavaScript, it's a CSS background-image or it depends on a slider that initializes late. In those cases the browser can't start downloading it until much later.

Solutions, from best to worst:

• Use a regular <img> in the server-rendered HTML.
• If it must be a CSS background or is loaded with JS, add a <link rel="preload">:

<link rel="preload" as="image" href="/hero.avif" type="image/avif" fetchpriority="high">

If you use responsive images, preload supports imagesrcset and imagesizes to preload the right variant.

Step 3: give it high priority

By default, browsers download images at low priority until they know they're visible. The fetchpriority="high" attribute tells the browser from the start that this one matters:

<img src="/hero.avif" fetchpriority="high" width="1600" height="900" alt="…">

Most importantly: never put loading="lazy" on the LCP image. Lazy loading delays the download until the browser has computed layout, and it's one of the most frequent causes of slow LCP. The lazy loading and fetchpriority guide has the details.

Step 4: reduce its size

With the image discovered and prioritized, download time depends on its bytes. This is where optimization comes in:

• Correct dimensions. If the image displays at 1200 px, don't serve 4000 px. Use srcset to offer several sizes.
• Modern format. AVIF typically cuts size by 40–50% versus JPEG. Use <picture> with a WebP or JPEG fallback.
• Reasonable quality. For a hero image, AVIF 55–65 or WebP 80 are usually indistinguishable from the original.

A 400 KB JPEG LCP image can end up at 120–180 KB as AVIF. On an average 4G connection that's hundreds of milliseconds saved.

Step 5: avoid render delays

Even once the image has arrived, it may be slow to paint if:

• Blocking CSS or JavaScript delays the first render.
• The image is initially hidden (for example, a carousel that reveals it with an animation).
• A web font delays text and, with it, layout.

Keep critical CSS small, defer non-essential JavaScript and avoid entrance animations on the main image.

Common mistakes

• loading="lazy" on the first visible image.
• Hero as background-image without preload.
• Serving the same 2500 px image to phones.
• Sliders that load every slide with the same priority.
• Image CDNs with redirects or on a different domain without preconnect.

Frequently asked questions

How much does switching to AVIF improve LCP?

It depends on the connection and the original size, but if the image accounts for most of the load time, halving its size can cut hundreds of milliseconds on mobile.

Should I use preload and fetchpriority together?

If the image is already in the HTML as an <img>, fetchpriority="high" is enough. Preload helps when the browser can't discover the image early.

Can text be the LCP element?

Yes. If the largest block is a heading, LCP depends mostly on TTFB and font loading, not on images.

Why do Lighthouse and Search Console give different results?

Lighthouse is a lab test under simulated conditions. Search Console uses real-user data (CrUX) from the last 28 days. Changes take a few weeks to show up in field data.