Image Optimisation for Core Web Vitals: A Working Checklist
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.
- Measure the widest the image is ever displayed, in CSS pixels, across all your breakpoints.
- Multiply by two to cover high-density displays. That is your maximum useful width.
- Export at that size. Anything beyond it is bytes the visitor downloads and the browser immediately throws away.
- For images whose display size varies a lot between mobile and desktop, generate two or three widths and let srcset choose.
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 position | loading | fetchpriority | decoding |
|---|---|---|---|
| Hero or first visible image | eager (the default, omit it) | high | omit |
| Other above-the-fold images | omit | omit | async |
| Everything below the fold | lazy | omit | async |
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
- Resize every image to at most twice its largest display width. This is usually the biggest single saving available.
- Add width and height attributes everywhere. This removes layout shift entirely and takes minutes.
- Remove lazy loading from anything visible without scrolling, and add fetchpriority="high" to the hero image.
- Convert photographs to AVIF or WebP with a fallback, using a picture element.
- Set compression quality between 70 and 85 and verify against your most detailed image.
- Serve two or three widths through srcset for images whose display size changes significantly between mobile and desktop.
- 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 converterRelated guides
- JPEG, PNG, WebP and AVIF: How to Choose the Right Image FormatFour formats cover almost every job on the web, and picking the wrong one costs you either file size or quality. This guide explains what each format actually does and when to reach for it.
- What the Quality Slider Really Does, and How to Set ItQuality 80 is not 80 percent of anything. Here is what the number actually controls, why it behaves differently on different images, and a repeatable way to find the lowest setting you can get away with.
- Making a Video File Smaller Without Making It Look BadVideo size is governed by four settings that interact. Change them in the right order and you can often cut a file by three quarters with no visible difference.