AmonFlux
IMAGE & PDF SUITE

Image Optimisation for Core Web Vitals: A Working Checklist

By Marco Caturano 10 min readPublished 18 March 2026 · Updated 30 August 2026

Page speed advice usually starts and ends with "compress your images". Compression matters, but it is one of at least five factors, and on most sites it is not the one holding the score back. Serving a perfectly compressed image that is four times larger than its display size, loaded lazily when it is the first thing on screen, will still produce a poor result.

The two metrics images actually affect

Largest Contentful Paint measures how long it takes for the biggest visible element to render. On a typical page that element is an image, which makes image delivery the dominant factor in the score.

Cumulative Layout Shift measures how much content jumps around while the page loads. Images cause this whenever the browser does not know how much space to reserve, so the text reflows the moment the image arrives.

The third metric, Interaction to Next Paint, is largely about JavaScript and is not something image work will fix. If that is your problem, compressing images is wasted effort.

Start with dimensions, not compression

The single most common waste is serving an image far larger than it is ever displayed. A 3000 pixel wide photograph rendered into an 800 pixel column is carrying roughly fourteen times the pixel data it needs. No compression setting recovers that.

  1. Measure the widest the image is ever displayed, in CSS pixels, across all your breakpoints.
  2. Multiply by two to cover high-density displays. That is your maximum useful width.
  3. Export at that size. Anything beyond it is bytes the visitor downloads and the browser immediately throws away.
  4. For images whose display size varies a lot between mobile and desktop, generate two or three widths and let srcset choose.
Multiplying by three for very high density screens is almost never worth it. The perceptual difference between 2x and 3x is marginal and the file size difference is not.

Loading attributes, and the lazy loading mistake

Lazy loading defers images until they are near the viewport. It is genuinely useful for everything below the fold and actively harmful for anything above it.

Applying loading="lazy" to every image, which many content systems do by default, delays the hero image by an extra round of layout and discovery. That directly worsens Largest Contentful Paint, which is the exact metric people are usually trying to improve when they enable it.

Image positionloadingfetchprioritydecoding
Hero or first visible imageeager (the default, omit it)highomit
Other above-the-fold imagesomitomitasync
Everything below the foldlazyomitasync

Setting fetchpriority to high on the hero image tells the browser to request it ahead of other resources rather than queueing it behind stylesheets and scripts. On image-led pages this alone frequently moves Largest Contentful Paint by several hundred milliseconds.

Eliminating layout shift completely

Layout shift from images is entirely preventable and the fix is trivial: always set the width and height attributes on the img element to the intrinsic pixel dimensions of the file.

Browsers use those two numbers to compute an aspect ratio and reserve the correct space before a single byte of the image has arrived. The attributes do not fight your CSS. As long as your stylesheet sets width to a percentage or similar and height to auto, the image still scales responsively.

  • Use the real pixel dimensions of the exported file, not the display size.
  • If you serve several widths through srcset, the aspect ratio must be identical across all of them or the reserved space will be wrong.
  • For images inside a picture element, the attributes go on the inner img.
  • Web fonts and injected banners cause layout shift too. If the score stays poor after fixing images, look there next.

The checklist, in the order that pays off

  1. Resize every image to at most twice its largest display width. This is usually the biggest single saving available.
  2. Add width and height attributes everywhere. This removes layout shift entirely and takes minutes.
  3. Remove lazy loading from anything visible without scrolling, and add fetchpriority="high" to the hero image.
  4. Convert photographs to AVIF or WebP with a fallback, using a picture element.
  5. Set compression quality between 70 and 85 and verify against your most detailed image.
  6. Serve two or three widths through srcset for images whose display size changes significantly between mobile and desktop.
  7. Only after all of the above, look at a content delivery network or automated image pipeline. Infrastructure does not fix a badly sized image.

Measure after each step rather than doing all seven and hoping. Field data from real visitors is more trustworthy than a synthetic test on a fast connection, and the two often disagree sharply.

Common questions

Does lazy loading help or hurt my score?

Both, depending on placement. Below the fold it reduces the bytes needed for the initial render and helps. Above the fold, and especially on the largest visible image, it delays exactly the element the metric is measuring and hurts.

Do I need a CDN to pass Core Web Vitals?

No. A CDN reduces latency, which helps, but it will happily deliver an oversized image very quickly. Correct dimensions, format and loading priority get most sites into the good range without any infrastructure change.

How many widths should I generate for srcset?

Two or three is almost always enough: roughly mobile, tablet and desktop. Beyond that the returns are tiny and you are multiplying build time and storage for a saving measured in a handful of kilobytes.

Should background images in CSS get the same treatment?

They need correct sizing and format just as much, but they cannot carry width and height attributes and the browser discovers them later because it must parse the stylesheet first. If a CSS background image is your largest visible element, moving it into a real img element usually improves the score by itself.

Try it yourself

The settings described above are all adjustable in the tool. Files stay on your device; nothing is uploaded to a server.

Open the image converter

Related guides