Oversized images

Compare the image's intrinsic size — the dimensions of the file — against its rendered size, the CSS pixels it occupies.

Multiply the rendered width by the device pixel ratio to get the pixels actually needed. A 400 CSS-pixel column on a 2× display needs an 800-pixel image, not a 3000-pixel one.

The ratio of file pixels to needed pixels is the waste factor, and because image data scales with area, a 2× excess in each dimension is a 4× excess in data.

That is why this defect is so expensive: the numbers people quote are widths, and the cost is the square of the width.

Uploads straight from a camera or a phone, which produce four- and five-thousand-pixel files, stored and served unchanged.

A CMS that generates thumbnails but whose template references the original. The resized variants exist and nothing points at them.

Retina assets served to everyone. An image prepared at 2× for high-density screens is twice the linear size and four times the data, delivered to devices that cannot use it.

Backgrounds and hero images sized for the widest possible desktop and served to phones at the same dimensions.

Logos and icons exported as large PNGs where an SVG would be a fraction of the size and sharp at every scale.

Resizing reduces the pixel dimensions. This is what fixes an oversized image, and it is the step most often skipped.

Compressing reduces the bytes per pixel by lowering quality or choosing a better encoder. It helps an image that is the right size and heavy; it does not fix one that is the wrong size.

Serving variants means producing several sizes and letting the browser choose, with `srcset` and `sizes`. This is what handles a page viewed on both a phone and a desktop.

Running a compressor over a 3000-pixel image and declaring the problem solved is the most common non-fix: the file gets smaller and still carries fifty times the pixels the layout uses.

In the browser, hover an image in the Network panel: it reports both the intrinsic and the rendered size, and flags the difference.

In the console: `[...document.images].map(i => ({ src: i.currentSrc, natural: i.naturalWidth, rendered: i.clientWidth }))`. Any row where `natural` greatly exceeds `rendered` times the device pixel ratio is waste.

Sort the page's requests by size in the Network panel. On most sites the top of that list is images, and the largest one is usually the hero.

Check the phone viewport as well as the desktop. An image that is correctly sized for a 1200-pixel column is oversized by a factor of nine on a 400-pixel screen.

Resize to the largest size the layout can display, times the device pixel ratio you intend to support. Beyond 2× the difference is not perceptible and the data cost continues to grow.

Generate variants and serve them with `srcset` and a correct `sizes` attribute, so a phone downloads a phone-sized file.

Use an image CDN or a build step that produces the variants automatically. Doing it by hand works once and decays immediately.

Replace large PNG logos and icons with SVG, which is smaller and resolution-independent.

Do the resize before the compression. Order matters: compressing first and resizing second discards the compression work.

`images.oversized` compares each image's intrinsic dimensions against the size it is rendered at on the crawled page and reports the ones substantially larger, with both measurements.

`images.dimensions` and `images.weight` report the raw sizes, and `images.inventory` gives the full list per page so the largest contributors are visible rather than inferred.

`images.lcp` identifies the image that is the largest contentful paint element, which is the one where oversizing costs the most perceived load time.

`images.cdn` reports whether images are delivered through a service capable of resizing on request, which decides whether the fix is a configuration or a build change.