Properly Size Images: Stop Serving Oversized Images

What this check flags

The audit compares each image's intrinsic dimensions (its real pixel size) against the dimensions it is rendered at, adjusted for the device's pixel ratio. When the file is meaningfully bigger than it is displayed, those extra pixels are pure waste: the browser downloads and decodes them, then throws them away by scaling the image down. This is distinct from compression; a perfectly compressed 2500px image is still oversized if it renders at 400px.

The stakes land hardest on mobile. A phone on a slow connection pays full download and decode cost for pixels it cannot show, which pushes out LCP if the oversized image is your hero, and quietly taxes every other image on the page. Multiply that across a gallery and you have shipped megabytes nobody needed.

A real example, and the fix

The classic offender is one giant fixed source doing duty for every screen. A 2400px file served to a phone that paints it at 375px is downloading roughly forty times the pixels it renders:

<!-- One oversized file for every device -->
<img src="/img/product-2400.jpg" alt="Trail shoe, side view">

Give the browser choices instead. The srcset lists the widths you have, and sizes tells the browser how much layout space the image occupies so it can pick before layout is even computed:

<img
  src="/img/product-800.jpg"
  srcset="/img/product-400.jpg 400w,
          /img/product-800.jpg 800w,
          /img/product-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="600"
  alt="Trail shoe, side view" loading="lazy">

Now a 375px phone at 2x pulls the 800w file, a desktop pulls the 1600w, and nobody over-downloads. Keeping width and height on the tag also reserves the box so you do not trade an image win for a layout shift. Skip loading="lazy" on your LCP image, though, since lazy-loading the hero delays the very paint you are trying to speed up.

Reading srcset and sizes

The descriptors trip people up because they answer different questions. This is what each part is actually telling the browser.

How to detect it

1. Lighthouse: the "Properly size images" opportunity lists each oversized image with its intrinsic size, display size, and the bytes you would save.
2. PageSpeed Insights: run the URL to see the same list against real devices, which matters because savings are largest on the mobile viewport.
3. DevTools Elements panel: hover any <img> and Chrome shows "intrinsic" versus "rendered" dimensions. A big gap between them is the audit in one glance.
4. DevTools Network panel: sort by size and filter to images. Heavy image transfers on a page with small display areas point straight at the offenders.

How to fix it

• Generate multiple widths of each image (say 400, 800, 1600) and wire them into srcset with accurate w descriptors.
• Write an honest sizes that reflects the real layout at each breakpoint, so the browser never over-fetches.
• Let your CMS do it. WordPress and most modern stacks auto-generate responsive sizes; make sure the feature is on and your theme outputs the sizes attribute.
• Cap the source. Do not upload a 4000px original for a slot that never exceeds 1200px; the largest srcset entry should match the largest real display size at 2x.

Pair this with format and compression wins from next-gen formats and efficient encoding, and see the broader image SEO guide for the full workflow.

FAQ

Is this the same as compressing images?

No. Compression reduces the bytes needed to store a given number of pixels; proper sizing reduces the number of pixels you send in the first place. An image can be flawlessly compressed and still fail this check because it is dimensionally too large for its slot. You usually want both fixes.

Why do I need sizes if I already have srcset?

Because the browser chooses a source before layout is calculated, it cannot yet know how wide the image will render. The sizes attribute tells it, so it can pick the right srcset entry up front. Omit sizes and the browser assumes full viewport width and over-fetches.

Does device pixel ratio matter here?

Yes, and the browser handles it for you. A 400px slot on a 2x phone genuinely needs an 800px source to look sharp, so "oversized" is judged against display size times pixel ratio, not raw CSS pixels. That is why a modest amount of extra resolution is fine, but forty times is not.

Should I lazy-load every image to fix this?

Lazy-loading defers below-the-fold images, which helps overall load, but it does not make an oversized file smaller, and lazy-loading your LCP image actively hurts by delaying the main paint. Size the images correctly first, then lazy-load the ones below the fold.

My CMS handles srcset. Why am I still flagged?

Often the largest generated size is still bigger than any real display slot, or the sizes attribute is a generic default that does not match your layout. Check that your uploaded originals are not enormous and that the theme emits a sizes value reflecting the actual rendered widths.