Properly Size Images

This audit fires when an image file is meaningfully larger, in pixels, than the box it's actually displayed in. A 3000px-wide photo shown in a 400px-wide card is a common example: the visitor downloads roughly 7x more image data than their screen can even show.

What it means

Lighthouse compares each image's natural (intrinsic) dimensions against its rendered CSS dimensions, adjusted for device pixel ratio. If the natural size is significantly larger, it flags the wasted bytes. This is different from using a next-gen format, which is about compression efficiency for a given size. This audit is purely about serving the right size in the first place.

Why it matters

Oversized images are wasted network transfer, plain and simple, and on mobile connections that transfer time is not free. When the oversized image is also your Largest Contentful Paint element, which it often is (hero images and product photos are frequent LCP candidates), the extra bytes translate directly into a slower LCP. If that same LCP image is also loading lazily, see deferring offscreen images for the fix.

How to fix it

The standard fix is srcset combined with sizes, which lets the browser pick the right file for its own viewport and pixel density instead of you guessing one size for everyone:

<img
  src="/product-800.jpg"
  srcset="/product-400.jpg 400w, /product-800.jpg 800w, /product-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 400px"
  alt="Product photo"
>

• srcset lists the available file widths (the w descriptor is the image's real pixel width, not a display size).
• sizes tells the browser how wide the image will actually be rendered at each viewport width, so it can pick the smallest file that's still sharp enough.
• Always set explicit intrinsic width/height attributes (or an aspect-ratio in CSS) alongside srcset, so the browser can reserve layout space before the image loads, which also helps your Cumulative Layout Shift score.
• If you use a CDN or image service (Cloudinary, imgix, a WordPress plugin, Next.js <Image>), it can usually generate the resized variants and the srcset markup automatically from a single source file, which is far less error-prone than exporting fixed sizes by hand.

How to verify

Re-run the test on a representative page; the flagged images and their estimated savings should shrink to zero once every breakpoint has an appropriately sized source. Spot-check in DevTools by inspecting the actual naturalWidth of the loaded image against its rendered width.