Why Image Optimisation Decides Your Core Web Vitals

Core Web Vitals are three measurements of what a page actually feels like to use: how long until the main content appears, whether things move around while you are reading, and whether the page responds when you tap something.

Images sit squarely in the middle of two of the three. On a typical content page, images are both the largest thing to download and the most common cause of content jumping about. Getting them right is the highest-leverage performance work available on most sites.

The three metrics#

Largest Contentful Paint (LCP)#

What it measures: the time from when the page starts loading until the largest text block or image visible in the viewport has finished rendering.

Threshold: 2.5 seconds or less is good. Above 4 seconds is poor.

On most content pages, the largest element is an image — a hero, a featured image, a product shot. When that is true, LCP is essentially a measurement of how quickly one image arrives and paints.

Cumulative Layout Shift (CLS)#

What it measures: how much visible content moves unexpectedly during the page's lifetime. It is a score, not a time — the sum of the layout shifts, each weighted by how much of the viewport moved and how far.

Threshold: 0.1 or less is good. Above 0.25 is poor.

This is the metric behind the experience of reaching for a link and having it slide away as an image loads above it.

Interaction to Next Paint (INP)#

What it measures: how quickly the page visually responds to user interactions — clicks, taps, key presses — across the whole visit. It replaced First Input Delay as a Core Web Vital in March 2024.

Threshold: 200 milliseconds or less is good. Above 500 ms is poor.

INP is mostly about JavaScript, but images contribute indirectly: decoding a very large image occupies the main thread, and a main thread that is busy cannot respond to a tap.

One important detail about all three: Google assesses them at the 75th percentile of real user loads, not the average and not a lab test. A quarter of your visitors can exceed the threshold and the page still passes. Equally, a page that is fast on your machine can fail on the devices and connections your visitors actually have.

How images drive LCP#

Four things determine when your LCP image finishes painting.

1. When the browser discovers it exists. If the image is in the initial HTML as an <img> tag, the browser's preload scanner finds it almost immediately. If it is set by CSS as a background image, the browser must first download and parse the CSS. If it is inserted by JavaScript, later still. Each layer of indirection costs time before the download even starts.

Use a real <img> element for your LCP image. This alone often saves several hundred milliseconds.

2. How big the file is. The most direct lever. A 2 MB hero on a typical mobile connection is several seconds of transfer on its own; the same image well optimised at 150 KB is a fraction of a second.

3. What else is competing for bandwidth. A browser has a limited number of connections. If your hero image is queued behind four render-blocking stylesheets and a font file, it waits.

4. Priority. Browsers guess at what matters. You can tell them: fetchpriority="high" on the LCP image moves it up the queue.

Putting those together, an optimised hero image looks like this:

<img
  src="hero-1200.webp"
  srcset="hero-600.webp 600w, hero-1200.webp 1200w, hero-2000.webp 2000w"
  sizes="100vw"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="A description of the photograph"
>

Note what is not there: no loading="lazy". Lazy-loading your LCP image is the most common self-inflicted performance wound on the web. It tells the browser to defer the exact fetch you need to happen first.

How images cause layout shift#

The mechanism is simple. The browser lays out the page as HTML arrives. When it reaches an <img> with no dimensions, it does not know how tall the image will be, so it reserves nothing. Everything below sits where it would go with a zero-height image. Then the file arrives, the browser learns the real dimensions, and everything below jumps down.

The fix is one attribute pair:

<img src="photo.webp" width="1200" height="800" alt="…">

Set the intrinsic pixel dimensions of the file. Modern browsers compute an aspect ratio from them and reserve correctly proportioned space before the image arrives — CSS can still resize the image freely with width: 100%; height: auto. The two are not in conflict.

Other image-adjacent causes of CLS worth checking:

• Images inside containers with no reserved space, such as carousels or embedded media.
• Web fonts swapping, which reflows text around images. font-display: swap with a well-matched fallback, or size-adjust, reduces this.
• Content injected above the fold after load — cookie banners, notification bars, late-loading advertising slots. If something will appear there, reserve its space in the initial layout.

That last point is worth stating plainly for anyone monetising with display advertising: an ad slot with no reserved height is a layout-shift generator. Give every slot a fixed minimum height in CSS matching the ad size you expect. This is the single most common CLS problem on ad-supported sites, and it is entirely avoidable.

The image work that moves the metrics#

Ordered by impact:

1. Resize to display dimensions. Halving width and height quarters the pixel count. Nothing else has this leverage.

2. Serve modern formats. WebP is typically 25–35% smaller than JPEG at equivalent quality with universal current-browser support. AVIF is smaller still where you can provide a fallback.

3. Set width and height on everything. Eliminates the most common source of CLS, costs nothing.

4. Use srcset and sizes. Phones download phone-sized files. This is often the largest real-world saving, because most of your traffic is mobile.

5. Lazy-load below the fold, never above it. loading="lazy" on everything except the LCP image.

6. Prioritise the LCP image. fetchpriority="high", and consider a <link rel="preload"> if it is discovered late.

7. Compress by eye. Quality 75–82 for photographs, verified at display size.

Measuring properly#

Field data — what real visitors experienced — is what Google uses. Find it in the Core Web Vitals report in Google Search Console, or in the Chrome UX Report data shown at the top of PageSpeed Insights.

Lab data — a simulated load — is what you use to debug. Lighthouse in Chrome DevTools, or WebPageTest for a detailed waterfall.

The two disagree often, and when they do, field data is right. A lab test on a fast desktop with a wired connection is not representative of a mid-range Android phone on a congested mobile network, which is what a large share of your visitors are using.

When debugging, throttle. DevTools can simulate slow 4G and a 4× CPU slowdown. Every performance problem that matters becomes visible under those conditions, and most of them are invisible without.

A realistic view of the SEO impact#

Core Web Vitals are part of Google's page experience signals. They are one input among many, and relevance and content quality dominate.

The honest framing:

• Good Core Web Vitals will not make a thin page rank.
• Poor Core Web Vitals can cost you against an equally relevant competitor who is faster.
• The effect on whether visitors stay is larger and more immediate than the effect on ranking. A page that takes six seconds to show anything loses people before Google's opinion is relevant.

Optimise images because the page is better, and accept the search benefit as a side effect rather than the goal.

A short checklist#

• LCP image is a real <img> element, not a CSS background
• LCP image has fetchpriority="high" and no loading="lazy"
• Every image has width and height attributes
• Images are served as WebP or AVIF with a fallback
• Images are exported at roughly 2× display size, not larger
• srcset and sizes are set for anything that varies with viewport
• Below-the-fold images use loading="lazy"
• Advertising and embed slots have reserved heights
• Tested on throttled mobile, not just desktop
• Field data checked in Search Console, not just Lighthouse

---

Our free image compressor handles the resize and format conversion in one pass, in your browser.

Related: how to reduce image size for a website and JPG vs PNG vs WebP vs AVIF.