Lighthouse says “Properly size images” — what it measures and the fix

2026-10-19

You run Lighthouse on your site and one line keeps coming back: Properly size images, with a list of files and a number of kibibytes you could save. You've already compressed every image. Compressing them harder doesn't make the line go away the way you'd expect. That's because the audit isn't really about compression.

What follows about Lighthouse comes from the Chrome for Developers page Properly size images (checked 2026-10-08).

What the audit measures

Per that page, Lighthouse compares, for each image on the page, the size at which the image is rendered with the size of the actual image file — and the rendered size accounts for the device pixel ratio. If the difference works out to at least 4 KiB, the image fails the audit. The report lists those images along with the potential savings in KiB.

In plain terms: you're sending more pixels than the screen uses. A photo that is 2400 pixels wide but displayed in a box 600 pixels wide carries pixels nobody will ever see, and every visitor downloads them anyway.

One update worth knowing: the same page notes that, as of Lighthouse 13, this audit has moved into the Improve image delivery insight. If you're on a newer version and don't see the old title, look there.

The device pixel ratio part

"Rendered size" isn't just the box in your CSS. High-density screens use more than one physical pixel per CSS pixel, and Lighthouse factors that in. For example, an image shown 400 CSS pixels wide on a screen with a ratio of 2 needs 800 pixels to look sharp. Sending 800 is right; sending 2400 is what the audit is flagging.

So the target width for an image is: the width it is displayed at × the device pixel ratio you're designing for. Check the displayed width in your browser's developer tools — inspect the image and read its rendered size.

Why compressing harder is the wrong lever

Compression makes each pixel cheaper. It doesn't remove any. A 2400-pixel image compressed to the bone is still a 2400-pixel image in a 600-pixel box: you've degraded its quality to make up for pixels you didn't need to send in the first place.

Resizing removes what the audit is actually measuring. And the image usually looks better afterwards, because you can afford a normal quality setting on a file with the right number of pixels.

Fixing it with our resize tool

• Note the displayed width and the device pixel ratio you're targeting, and multiply them.
• In the resize tool, keep Keep aspect ratio on and enter that width — or use one of the common-width buttons (3840, 1920, 1280, 800, 640, 320) if one fits.
• Drop in every image that shares the same slot — all your blog thumbnails, say — and they're resized to the same width in one pass.

Do not enlarge if smaller is on by default, so an image that's already smaller than your target is left alone rather than blown up. Resized files are named with their new width — photo_resize_800.jpg — which makes it easy to keep track when you produce more than one size.

One image, several widths

The documentation's main recommendation is responsive images: generate several versions of each image and let the page pick the right one per screen, typically with the HTML srcset and sizes attributes. It also points to image CDNs, which generate versions on request, and to SVG for vector graphics like icons and logos, which scale to any size from one file.

If you're producing the versions by hand, run the same image through the resize tool at each width you need — 640, 1280 and 1920, for instance. Each pass saves a file with its width in the name, ready to list in a srcset.

The short version

• The audit compares real pixels with rendered size (device pixel ratio included) and flags differences of at least 4 KiB (Chrome for Developers, checked 2026-10-08).
• Since Lighthouse 13 it lives inside the Improve image delivery insight.
• Target width = displayed width × device pixel ratio.
• Resize to that width; compression alone leaves the extra pixels in place.