Google has used Core Web Vitals as a real ranking signal since 2021, and images are by far the most common reason a page fails them. Compressing your images correctly isn't just nice for users — it directly translates to a better LCP score, a better CLS score, and ultimately better search visibility. Here's how the pieces fit together.
What Core Web Vitals actually measure
Core Web Vitals are a small, opinionated set of metrics that approximate how a page feels to load and use:
- Largest Contentful Paint (LCP): how long it takes for the biggest visible element to appear. Should be under 2.5 seconds. Almost always an image or hero text.
- Interaction to Next Paint (INP): how responsive the page is to taps and clicks. Should be under 200ms. Mostly a JavaScript concern, not images.
- Cumulative Layout Shift (CLS): how much the page jumps around as it loads. Should be under 0.1. Images without dimensions are the classic offender.
Why images dominate LCP
On most modern web pages the largest contentful element is a hero image or a large above-the-fold photograph. The browser can't report LCP until that image has finished downloading and rendering. If the file is 2MB and the visitor is on a phone with 4G, even with a fast site you're looking at multiple seconds of LCP — well outside Google's "good" threshold.
Cut that 2MB to 200KB and the LCP for the same page on the same connection drops by an order of magnitude. This is why image compression is the single highest-leverage thing you can do for Core Web Vitals.
Why images dominate CLS
When the browser doesn't know an image's dimensions, it reserves zero space for it and reflows the page once the image finally loads. Every paragraph below the image jumps down — that's the layout shift CLS measures. The fix: always set width and height attributes (oraspect-ratio in CSS) on every image. The browser then reserves the right amount of space up-front, regardless of when the image actually arrives.
The image-side checklist for Core Web Vitals
- Compress. For photos, target around 200KB for hero images, 50–100KB for in-content images. Our free image compressor targets 1MB by default but you can re-run it on the output for smaller targets, or adjust settings in code.
- Resize. Don't serve a 4032px image to a 1200px slot. See our file size reduction guide for sensible defaults.
- Use modern formats. WebP saves 25–35% over JPG at the same quality. AVIF saves another 20% on top. See our format comparison.
- Set width and height. On every image. Even if you're using CSS to size it, declare the intrinsic dimensions on the
<img>element so the browser can reserve space. - Lazy-load below the fold. Add
loading="lazy"to images that aren't visible on initial render. The browser skips them until the user scrolls close. - Eager-load the LCP image. Conversely, do NOT lazy-load the hero image. Some teams add
fetchpriority="high"to it for a small extra LCP boost. - Preload critical images. Add a
<link rel="preload">for the hero image so the browser starts fetching it as early as possible.
How much does this actually move the needle?
On a typical content site with previously unoptimised images, a careful pass through these steps usually moves LCP from the red zone (>4s) into green (<2.5s) and CLS from yellow into green. Google's own data shows pages in the "good" zone for Core Web Vitals have measurably lower bounce rates and higher engagement. The SEO benefit is real but secondary; the retention benefit is the bigger story.
Diagnosing your own pages
Two free tools cover almost everything:
- PageSpeed Insights gives you lab + field data and specifically calls out oversized images, missing dimensions and missing modern formats.
- The Lighthouse panel in Chrome DevTools is the same engine, handy for iterating locally.
The bottom line
If your Core Web Vitals are bad, the fix is almost always compress, resize, declare dimensions, and lazy-load below the fold. Image work isn't glamorous, but it's the single highest-ROI optimisation you can do — and it directly feeds into how Google ranks your site.