Image Compression for Core Web Vitals: LCP & CLS

Updated: September 29, 2026

Quick answer: Find the Largest Contentful Paint element first. If it is an image, shrink its bytes and make sure it is a plain img tag that is not lazy-loaded. For CLS, set width and height on every image so the browser can reserve space.

Core Web Vitals scores pages on three metrics: LCP (how fast the main content appears), CLS (how much the layout moves), and INP (how fast the page responds to taps). Images feed directly into the first two.

This is not a Core Web Vitals explainer — web.dev covers the general theory. This is the short version for one question: which image change moves which metric, and by how much.

Which metric is your image hurting?

Metric	Good threshold	What images do to it	The fix
LCP	≤ 2.5 s	The largest image is often the largest element, so its bytes and start time set LCP	Right-sized file, fast discovery, no lazy-loading
CLS	≤ 0.1	An image without dimensions pushes text down when it arrives	width and height attributes
INP	≤ 200 ms	Mainly unrelated to compression; huge decodes can contribute	Rarely an image problem — check scripts first

Run PageSpeed Insights on the page and read the LCP breakdown before changing anything. It tells you whether time went to the server, the download, or a late start. The fixes are different for each.

How images drive LCP

LCP stops the clock when the largest element renders. On content pages, that element is usually the hero image, so its download sits directly on the critical path.

Transfer arithmetic makes the stakes concrete. On a 4 Mbps connection, a 200 KB image takes about 0.4 seconds to download. A 2 MB image takes about 4 seconds — the difference between passing and failing on its own.

But bytes are only one of three delays:

• Late start. An image hidden in a CSS background or inserted by JavaScript is discovered only after CSS or scripts run. The download can be fast and still start late.
• Low priority. Browsers fetch plain img tags early. Lazy-loaded first images wait, sometimes until the user scrolls.
• Transfer time. Only this part responds to compression.

Fix LCP in five steps

1. Confirm the LCP element. PageSpeed Insights names it. Do not assume it is the hero — sometimes a headline block wins, and then image work changes nothing.
2. Right-size the file. Export for the largest slot, pick the format, and compress at a tested quality. The before-you-upload workflow covers this in five steps; a hero target is under 200 KB.
3. Make it a plain img tag. Content images belong in HTML, not in CSS backgrounds, so the browser sees the URL immediately and can prioritize it. Backgrounds have different loading rules — see background image compression.
4. Remove lazy-loading from the first screen. Keep loading="lazy" for below-the-fold images only. If your CMS adds it globally, override it for the hero — most themes offer a toggle.
5. Re-measure. Compare the LCP breakdown, not the file size. A 60% smaller file that still starts late improves nothing.

Fix CLS with two attributes

CLS from images has exactly one cause: the browser learns the image's size only when it arrives, so text and buttons shift to make room.

The fix is two attributes. Set width and height on every img, and the browser computes the aspect ratio before the first byte arrives. Any modern CMS keeps these automatically if the fields are filled in — the failure mode is pasting in images without dimensions or using editors that strip them.

A page can load in 1.2 seconds and still feel broken because the buy button moved twice. CLS fixes are free: no compression, no quality trade-off, just metadata.

Compress locally, measure honestly

One habit worth pairing with all of this: compress in the browser instead of uploading to a compressor server. LessMB processes JPG, PNG, WebP, AVIF, and HEIC locally with WebAssembly — files never leave your machine, and it is free with no signup. For heroes with a hard budget, LessMB's target-size mode hits a number like 150 KB directly, which is exactly what LCP work often needs.

Then trust the field data. Lab runs on your fast desktop hide the phones and slow networks where Core Web Vitals are actually scored.

FAQ

Does converting to WebP improve Core Web Vitals?

It shrinks bytes, which helps only when the LCP element is an image and transfer is the slow part. Discovery and priority can still dominate. Check the LCP breakdown before and after.

Should the LCP image be lazy-loaded?

No. Lazy-loading delays the image the visitor is waiting for. Keep the first screen eager and lazy-load below the fold.

How does compression affect CLS?

It does not. Image CLS comes from missing width and height attributes. Set them and the browser reserves the space.

What are the Core Web Vitals thresholds?

Good LCP is 2.5 s or less, good CLS is 0.1 or less, good INP is 200 ms or less, all measured at the 75th percentile of real visits.

Sources and related reading

• web.dev: Core Web Vitals and Optimize LCP
• Related: Optimize website images before upload, compress images without losing quality