Image Optimization for Core Web Vitals

Core Web Vitals measure three things, and images dominate two of them. Largest Contentful Paint is the time until the biggest above-the-fold element finishes rendering, and on a typical page that element is a hero image or a product photo. Cumulative Layout Shift measures unexpected movement, and the most common cause is an image that loads without reserved space and pushes everything below it down.

That makes images the first place to look, and it also means the work is bounded — a handful of specific changes, most of which are one-time. The order below is by effect: serving fewer bytes matters most, then reserving space, then telling the browser what to prioritise. Doing them out of order tends to produce a lot of activity and a small improvement.

One framing worth keeping: the metric is what a real visitor experiences on a mid-range phone over mobile data, not what a lab test reports on a fast connection. A 900KB hero image that scores fine locally is a slow page for a large share of real traffic, and that is what the field data will say.

The LCP image cannot render before it has downloaded, so its size in bytes sets a floor on the metric that no amount of loading-strategy tuning gets under. Two changes address it, and together they routinely take a hero image from 900KB to under 150KB.

The first is format. Converting a JPEG hero to WebP typically saves 25 to 35% at matching quality, and AVIF saves more again. Both are supported by every current browser, so this is close to free — the same picture, considerably fewer bytes, no visible difference.

The second is dimensions, and it is the one people skip. An image displayed 800 pixels wide should be somewhere around 1600 pixels of source data to look sharp on a high-density screen — not 4000. Shipping a camera-resolution file and letting CSS scale it down means the browser downloads and decodes every one of those pixels before discarding most of them, and the cost lands squarely on LCP.

Quality is the third, smaller lever. Around 80 is the point where further reductions start to be visible on photographs, and most images shipped from a design tool are well above that with nothing to show for it.

Cumulative Layout Shift from images has one cause and one fix. If an image element has no dimensions, the browser does not know how tall it will be, lays the page out as if it were empty, and then reflows everything below once the image arrives. That reflow is the shift.

The fix is to set the width and height attributes on every image element, with the real pixel dimensions of the file. Modern browsers use them to compute an aspect ratio and reserve correctly proportioned space even when CSS overrides the rendered size — so setting them does not conflict with responsive styling, which is the old objection to doing it. Where the dimensions are genuinely unknown ahead of time, an explicit aspect-ratio in CSS achieves the same thing.

The pattern to watch for is any image whose dimensions come from data — a CMS field, an API response, a user upload. Those are the ones that ship without attributes, because there was no literal to type. Storing intrinsic width and height alongside the file at upload time is the durable fix, and it is much easier to add at that point than to backfill later.

Once the bytes are small and the space is reserved, the remaining wins are about ordering. Three attributes do the work, and two of them are frequently used backwards.

Lazy loading defers an image until it is near the viewport, which is exactly right for everything below the fold and exactly wrong for the LCP element. A lazily-loaded hero image cannot start downloading until layout and script have progressed far enough to determine it is visible, which adds a delay to the one request you most wanted early. Applying loading="lazy" to every image on a page is a common blanket change that makes LCP measurably worse.

Priority hints are the counterpart. Adding fetchpriority="high" to the hero image tells the browser to fetch it ahead of other subresources, which is useful because a browser cannot know which image is the LCP element until it has done enough work to lay the page out. This is one attribute on one element per page and it is often worth a couple of hundred milliseconds.

Responsive sources are the third. A srcset with a sizes attribute lets the browser pick a file matched to the device's viewport and pixel density, so a phone downloads a phone-sized image instead of the desktop one. That is where the largest real-world saving lives, because mobile is where the constraint bites and where a single fixed-size image is most wasteful.

A preload link tells the browser to start fetching a resource before it would otherwise find it. For images this is worth doing in one specific situation: when the hero image's URL is not in the initial HTML — because it comes from CSS, or from JavaScript, or from a client-rendered component — the browser cannot begin the request until it has parsed and executed enough to discover it, and preloading recovers that lost time.

When the image is a plain element in the server-rendered HTML, the browser's preload scanner finds it almost immediately and a preload link adds nothing. Preloading several images makes things actively worse: they compete with each other and with the resources the page needs to render at all.

So the rule is one preload at most, for a hero image whose URL is genuinely late-discovered, and otherwise put the image in the HTML and let fetchpriority do the work.

A lab test runs once, on one connection, from one location, and gives a repeatable score that is useful for comparing two versions of a page. It is not what Core Web Vitals assessment uses. That comes from field data — real visits on real devices — which is aggregated over 28 days and weighted toward the mid-range Android phones that make up most mobile traffic.

The practical consequence is patience. A fix deployed today does not move the field number today, because the window still contains four weeks of the old behaviour. Use lab tools to confirm the change did what you intended, and the field data to confirm it mattered.

It also means the LCP element may not be what you assume. Lab tools report which element they measured, and it is regularly a surprise — a background image, a logo, a block of text on a page where the image loaded faster than expected. Check what is actually being measured before optimising the wrong thing.