Image Optimization for Core Web Vitals: Fix Your LCP

You run Lighthouse on the homepage. The score lands at 47, painted in angry red. Largest Contentful Paint sits at 5.8 seconds, and when you dig into the trace, the culprit is embarrassing: a 2.1MB hero JPEG, served at full desktop resolution to a phone.

Welcome to image optimization core web vitals work: the unglamorous, high-leverage job of making your pictures weigh less. LCP is the most image-driven of the three Core Web Vitals, and images are almost always the heaviest thing on the page.

Unlike most Core Web Vitals guides, this one gives you concrete KB budgets per image type and a worked audit you can repeat in DevTools. I build SnapShrink, a 100%-in-browser image compressor, so shrinking pictures is quite literally my day job.

Why LCP is usually an image problem

LCP measures when the largest visible element on screen finishes rendering, and on most pages that element is an image: a hero banner, a product photo, a featured post image. Text and CSS arrive in milliseconds, while a 2MB picture takes seconds on a mobile connection. Since Google wants LCP under 2.5 seconds, image weight is usually the whole battle.

Here is the math that makes it obvious. The HTML, CSS, and fonts on a typical marketing page weigh 100 to 300KB combined. One unoptimized hero image can weigh ten times that. The LCP element has to download, decode, and paint before the metric stops, so every extra megabyte stretches the timeline on a real mobile connection. Shrink the image and the metric usually follows.

Find your LCP image in under two minutes

Open Chrome DevTools, run Lighthouse from the Performance panel, and open the generated report. Scroll to the LCP element in the diagnostics section and click it; DevTools highlights the exact image on your page and shows its size and format. Note the file weight and the rendered dimensions, because the gap between the two is where your savings live.

The routine, step by step:

1. Run Lighthouse on the page with mobile emulation on. The default settings are fine; you want the same conditions Google scores.
2. In the report, find "Largest Contentful Paint element" under Diagnostics and click it. DevTools jumps straight to the image in the Elements panel.
3. Compare natural and rendered dimensions. If the file is 2400 pixels wide but renders at 390, you are shipping six times the pixels anyone sees.
4. Cross-check in the Network tab: filter by Img, sort by Size, reload with the cache disabled. The heaviest files float to the top, and the LCP image is usually one of the first three rows.

Set a KB budget before you touch a codec

Every image optimization core web vitals project I have run started with a budget, not a compressor. Decide the file size each image type is allowed before you touch anything: hero images get 150KB on desktop, 80KB on mobile; thumbnails get 30KB; avatars and icons get 15KB or ship as SVG. A budget turns optimization into a number you can verify.

Image type	Desktop budget	Mobile budget
Hero / banner	150KB	80KB
Product / feature shots	100KB	60KB
Card thumbnails	30KB	30KB
Avatars / icons	15KB (or SVG)	15KB (or SVG)

These are the ceilings I start from. They assume photographic content saved as WebP at quality 75 to 85. Illustrations and screenshots with flat colors compress far better, so treat the numbers as ceilings to stay under. If you like working backwards from the number, you can compress an image to an exact KB target in the browser instead of guessing at quality sliders.

The re-encode walkthrough: 2.1MB to about 110KB

Take the 2.1MB hero from our Lighthouse trace: a 2400x1600 JPEG served to every device. Resize it to the largest width the layout actually renders, 1600 pixels here, re-encode it to WebP at quality 80, and the file drops to roughly 100 to 140KB with no visible difference on screen. That single change typically cuts LCP by two to four seconds on a mobile connection.

The loop, in order:

1. Resize to the rendered width first. If the layout never shows the hero wider than 1600 pixels, a 2400-pixel source is pure wasted bytes. Resizing is the cheapest win in the whole process.
2. Pick WebP as your default. For photographic content it typically cuts 25 to 35 percent off an equivalent-quality JPEG. Keep the JPEG only if you still support truly ancient browsers; everything modern renders WebP.
3. Set quality between 75 and 85. Below 75, banding creeps into skies and gradients. Above 85, the file size climbs fast for differences nobody can see. I default to 80 and adjust by eye.
4. Compare the result against the original at 100 percent zoom. If you cannot spot the difference on a careful look, your users will not spot it at all. Ship it.
5. Re-run Lighthouse. The LCP number should move a lot. If it barely budges, the LCP element was not the file you optimized, and the audit in the second section sent you to the wrong image.

I built SnapShrink's free browser-based image compressor for exactly this loop: drop in the hero, resize, pick WebP, and everything re-encodes on your machine with nothing uploaded.

Your image optimization core web vitals questions, answered

Three questions come up every time image optimization core web vitals work lands on a developer's desk: whether lazy loading fixes LCP, whether AVIF is worth the hassle, and whether compression or responsive images matter more. Here are the short answers, with the tradeoffs that change the decision in practice.

Will lazy-loading the hero fix my LCP?

No. It usually makes LCP worse. Lazy loading defers offscreen images, but the LCP image is on screen by definition, so you would be adding delay to the exact thing you are trying to speed up. Mark the LCP image with fetchpriority="high", consider a preload link for it, and lazy-load everything below the fold. Google's guide to optimizing LCP walks through prioritizing the LCP element in detail.

Is AVIF worth switching to?

Not as your first move. AVIF typically shaves another 15 to 25 percent off WebP at matched visual quality, but encoding is slower and the tooling is thinner. Nail WebP first; add AVIF later.

Compression or responsive images: which first?

Compression first, responsive images second. Re-encoding one hero from JPEG to WebP can remove 70 to 90 percent of its weight in ten minutes. Responsive images with srcset and sizes stop you shipping desktop pixels to phones, which matters, but it is a code change across templates. Do the quick win this afternoon; schedule the srcset work for the sprint.

Back to that homepage scoring 47. Find the LCP image, give it a KB budget, re-encode it, and run Lighthouse again. LCP should drop hard, and the score usually follows it into the green. One page, one image, one afternoon.