What Size Should Images on a Website Actually Be?

Of everything you can do to make an image lighter, changing its dimensions is by far the most effective, and it is the one people reach for last. Halving the width and the height quarters the pixel count, and file size roughly follows. No amount of compression competes with simply not sending pixels nobody will see.

The rule, and the multiplier

Start from the largest size the image is ever displayed at, in CSS pixels, then multiply. A dense display packs two or three device pixels into every CSS pixel, so an image shown in a 400 pixel column needs about 800 pixels of real data to look sharp on a phone or a modern laptop.

Two times is the sensible ceiling. Three times is measurable in file size and very hard to see, because the returns fall away quickly once detail is beyond what the eye resolves at normal viewing distance.

displayed at 400px wide  ->  export at 800px
displayed at 800px wide  ->  export at 1600px
full-width hero          ->  1920px, occasionally 2560px

4000px is a photograph, not a web image.

Why the number is usually wrong

The default failure is uploading whatever came out of the camera or the design tool. A phone photograph is commonly 4000 pixels across and several megabytes; a thumbnail rendered at 120 pixels does not become smaller by being displayed small. The browser downloads all of it, decodes all of it into memory, and then throws almost all of it away during painting.

That cost lands on the metric Google measures most directly. Largest Contentful Paint is usually an image, and it is the one image on the page most likely to be oversized, because it is the biggest one.

A hero image is the most visible thing on the page and the most common reason the page is slow. It is worth measuring rather than guessing.

One size rarely fits

A layout that is 1200 pixels wide on a desktop may be 360 on a phone. Serving the desktop image to the phone wastes most of its bytes on the connection least able to afford them. The srcset attribute exists for this: you provide several widths and a description of how much space the image occupies, and the browser picks.

<img
  src="photo-800.jpg"
  srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  width="1600" height="900" alt="">

The sizes attribute is the part that gets skipped and the part that matters. Without it the browser assumes the image fills the viewport and chooses the largest candidate, which quietly undoes the entire arrangement.

Always declare width and height

Setting the intrinsic width and height attributes lets the browser reserve the right space before the image arrives. Without them, everything below the image jumps down when it loads, which is a Cumulative Layout Shift penalty on another metric Google ranks with.

The attributes do not fix the display size — CSS still controls that. They describe the aspect ratio, which is all the browser needs to hold the space.

A practical order of operations

1. Resize to about twice the largest displayed size. This is where most of the saving is.
2. Choose the right format for the content — lossy for photographs, lossless for flat graphics.
3. Compress, and stop when the artefacts become visible at full size rather than in a thumbnail.
4. Declare width, height and, where the layout varies, srcset and sizes.
5. Lazy-load anything below the fold, and never lazy-load the one image above it.

That last exception catches people out. Marking every image as lazy feels thorough and delays the largest visible element until after layout, which makes the metric worse rather than better. The image the visitor sees first should load first.