Improve image delivery

Improve image delivery is the Lighthouse 13 insight that flags images whose download is larger than it needs to be. It appears in PageSpeed Insights and in the Performance panel of Chrome DevTools, and it replaces four older audits at once: "Serve images in next-gen formats", "Efficiently encode images", "Use video formats for animated content" and "Properly size images" (Lighthouse source code, replacesAudits in core/audits/insights/image-delivery-insight.js, version 13.5, retrieved 18 October 2026). This guide explains how to read the insight, which of its four reasons to tackle first, and how to fix the two causes that have no guide of their own here: weak compression and animated GIFs.

From PerfDelta's measurements: Of 5,509 measured home pages, Lighthouse reports image savings for properly sized images on 74% of home pages (median saving 1663 ms); modern image formats on 49% of home pages (median saving 2152 ms). More in the data section below.

How the insight decides that an image is too large

For every image that was downloaded during the load, Lighthouse compares the number of bytes with what an efficiently encoded file of the same format would need for the pixels that are actually displayed, taking the device pixel ratio into account. The difference is the estimated saving. Images with an estimated saving below 4 KiB are not listed (Chrome for Developers, Improve image delivery). The insight does not change the performance score directly; it explains part of the Largest Contentful Paint and of the page weight.

Reading the table in PageSpeed Insights

The insight shows one row per image with three columns: the URL, the resource size and the wasted bytes. Under each image there are one or more sub-rows with a reason and the saving for that reason. The reasons use fixed wording, so you can tell them apart at a glance:

Reason in the report	What it means	Fix
Using a modern image format (WebP, AVIF) or increasing the image compression could improve this image's download size	JPEG or PNG where WebP or AVIF would be much smaller	Serve images in next-gen formats
Increasing the image compression factor could improve this image's download size	the format is fine, the quality setting is too high	section on compression below
This image file is larger than it needs to be (…) for its displayed dimensions (…)	more pixels delivered than displayed	Properly size images
Using video formats instead of GIFs can improve the download size of animated content	animated GIF	section on GIFs below

One image can carry two reasons, for example a 2,400-pixel JPEG shown at 600 pixels. The savings in the sub-rows are not simply additive, because a smaller file in a modern format saves less than the sum of both estimates. Fix the size first and re-test; the format saving shrinks with it.

Which image to fix first

• The LCP image. Open the LCP breakdown insight and check whether the LCP element is one of the listed images. If it is, every saved kilobyte shortens the resource load duration of LCP directly. That makes it the most valuable row in the table, even if another image wastes more bytes.
• Images above the fold. They compete with the LCP image for bandwidth during the first seconds.
• Large images further down. They mostly cost data volume. If they are lazy-loaded correctly, they hardly affect LCP; the lazy loading guide covers the rules.

The insight only sees images loaded during the test. A carousel that loads all slides at once shows up in full; one that loads slides on demand only with the first slide.

Compression: when the format is right but the file is still too big

The reason "Increasing the image compression factor" means that the file is already in a reasonable format but saved at a quality setting higher than the eye can distinguish at the displayed size. This used to be the separate audit "Efficiently encode images". Typical causes are photos exported from an editor at 100 percent quality, CMS uploads that are passed through without re-encoding, and PNG used for photographs.

Practical settings that are a good starting point for photographs (check the result visually, especially on faces and gradients):

# JPEG with mozjpeg at quality 75 to 80
cjpeg -quality 78 -progressive -outfile hero.jpg hero-original.ppm

# WebP at quality 75
cwebp -q 75 hero-original.png -o hero.webp

# AVIF with libavif, roughly comparable visual quality at a smaller size
avifenc --min 20 --max 30 --speed 6 hero-original.png hero.avif

# Batch job with sharp (Node.js)
const sharp = require('sharp');
await sharp('hero-original.jpg').resize({ width: 1600 }).webp({ quality: 75 }).toFile('hero.webp');

Re-encode from the original, not from an already compressed file, otherwise artefacts add up. For logos, icons and screenshots with flat colours, use SVG or lossless WebP instead of a lossy setting. If your CMS creates image sizes on upload, set the quality there once (in WordPress, for example, the wp_editor_set_quality filter) so that every future upload benefits.

Animated GIFs: replace them with video

GIF compresses animation poorly. A short screen recording or animated illustration of a few seconds often weighs several megabytes as GIF and a fraction of that as MP4 or WebM. The reason "Using video formats instead of GIFs" appears for exactly this case. Convert the file and embed it as a muted, looping video, which behaves like a GIF for the visitor:

# Convert with ffmpeg
ffmpeg -i animation.gif -movflags +faststart -pix_fmt yuv420p -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" animation.mp4
ffmpeg -i animation.gif -c:v libvpx-vp9 -b:v 0 -crf 41 animation.webm

<video autoplay loop muted playsinline width="640" height="360" poster="animation-poster.jpg">
  <source src="animation.webm" type="video/webm">
  <source src="animation.mp4" type="video/mp4">
</video>

Keep width and height on the video so that it reserves space and does not cause layout shifts. Animated WebP or AVIF are an alternative where a video element is not possible, for example in some email-style editors.

Image CDNs and automatic optimization

If many images are affected, fixing them one by one does not scale. An image CDN or an image service in your platform can deliver the right format, size and quality per request: the browser sends Accept: image/avif,image/webp, the service answers with the best format it supports and scales to the requested width. Shopify, Next.js (next/image), Cloudflare Images and most WordPress image plugins work this way. Check after switching that the LCP image is still served from your own origin or from a connection opened early, otherwise the gain in bytes is lost to an extra connection setup; the preconnect and preload guide explains the hints for that.

Checking the result

1. Re-run PageSpeed Insights and compare the wasted bytes per image; rows below 4 KiB disappear from the list.
2. In the LCP breakdown, the resource load duration should have dropped if the LCP image was on the list.
3. In DevTools, open the Network panel, filter by Img and check the Type column (avif, webp) and the transferred size.
4. Confirm the effect on LCP in the field data over the following weeks.

The free PerfDelta website speed test lists the image savings per page for several pages of your site at once, mobile and desktop, and shows them next to the field data and the values of your competitors.

Frequently asked questions

Is "Improve image delivery" the same as "Serve images in next-gen formats"?

It includes it. The insight combines next-gen formats, compression, animated content and image size in one table. The old audit names no longer appear in Lighthouse 13.

Why is an image still listed after I converted it to WebP?

Usually because it is still delivered at a larger size than displayed, or because the WebP was saved at a very high quality. Check the reason in the sub-row; it names the remaining cause.

Does the insight affect the performance score?

Not directly. Insights carry no weight in the score. Smaller images shorten LCP and Speed Index, and those metrics do count.

Why are some images on my page not listed?

Images with an estimated saving below 4 KiB are left out, and images that were not loaded during the test, such as lazy-loaded images far down the page, cannot be evaluated.