Dimensions versus file size: which one is actually slowing your site

Two numbers describe every image and they are routinely confused. Dimensions are how many pixels it contains — 4000 × 3000. File size is how many bytes it takes to store — 4.2 MB. They are related, but not proportionally, and the distinction determines which lever to pull.

Pixel count grows quadratically

Doubling the width of an image quadruples its pixel count, because both dimensions grow. A 4000-pixel-wide photo has four times the data of a 2000-pixel one, and sixteen times a 1000-pixel one.

This is why resizing is such a blunt and effective instrument. Halving the dimensions of an oversized image typically removes 70 to 75 percent of its file size before you touch a quality setting.

The most common web mistake

A photograph is displayed in an article at 800 pixels wide. The file uploaded is 4000 pixels wide, straight from the camera. The browser dutifully downloads twenty-five times the necessary pixel data, decodes it, and scales it down for display.

No compression setting fixes this. Quality 50 on a 4000-pixel image is still a much bigger download than quality 85 on an 800-pixel one — and it looks worse.

The rule of thumb: cap dimensions at roughly twice the largest display size, which covers high-density screens. For an 800-pixel column, 1600 pixels is generous.

Then compress

Once dimensions are right, compression is the second lever. Quality 80 to 85 in a modern format is where most photographs stop showing visible artefacts, and going below 70 starts to matter in skies and skin tones.

Format choice is part of this: WebP at equivalent visual quality is usually a quarter smaller than JPEG, applied across every image on a page.

Why file size cannot be predicted

Two images with identical dimensions and identical settings can differ in size by a factor of five. A flat studio background compresses to almost nothing; a forest canopy full of fine detail does not. Compression works by finding redundancy, and some images have far more of it than others.

This is why any tool that shows you an estimated output size before encoding is guessing. Real numbers require real encoding.

What to measure

Total page weight matters more than any single file. A page with twenty images at 200 KB is heavier than one with three at 800 KB, even though the individual files are smaller.

Largest Contentful Paint is usually an image, and usually the hero. That one file is worth optimising carefully even if the rest of the page is already reasonable.

A working order of operations

Resize to the display size, times two. Convert to WebP unless you need something else. Compress at 80 to 85. Measure the result rather than trusting an estimate. Then, if the page is still heavy, look at how many images it is loading at all — the cheapest image is the one you did not include.

A worked example

Take a 24-megapixel photograph straight from a camera: 6000 × 4000 pixels, saved at quality 90, around 8 MB. It is destined for a blog post where it will display at 800 pixels wide.

Step	Result	Size
Original	6000 × 4000	~8 MB
Resize to 1600 wide	1600 × 1067	~850 KB
Quality 85 instead of 90	1600 × 1067	~600 KB
Convert to WebP	1600 × 1067	~400 KB

The resize alone removed roughly 89% of the weight. Everything after it removed a further 6% of the original. Both matter, but the order of magnitude difference between them is the point: an afternoon spent tuning quality settings on oversized images is an afternoon spent on the small lever.

Megapixels and memory

Two numbers describe an image's cost and only one appears in your file listing.

The file size is what transfers over the network. The decoded size — roughly width × height × 4 bytes — is what the browser holds in memory. That 6000 × 4000 photograph is an 8 MB download and about 96 MB of RAM once decoded.

This distinction is why a gallery page can pass a performance audit on total transfer size and still crash a phone. Twenty full-resolution images is under 200 MB of downloads and close to 2 GB of decoded pixels, which no mobile browser will tolerate.

Where the bytes actually go

Two images with identical dimensions and settings can differ in size by a factor of five, because lossy compression works by finding redundancy and some images have far more of it.

Flat studio backgrounds, clear skies and shallow depth-of-field portraits compress extremely well. Foliage, gravel, textiles, crowds, film grain and sensor noise compress badly, because every pixel genuinely differs from its neighbour.

This is worth knowing for two reasons. It explains why estimated file sizes are unreliable — the estimate cannot know your content — and it explains why noise reduction applied before export can reduce file size more than a quality adjustment would.

A budget worth holding

Rather than optimising per image, set a page budget and check against it. A reasonable target for a content page is under 1 MB of images in total, with the largest single image under 200 KB.

Hitting that is usually a matter of three decisions: cap dimensions at twice the display width, use a modern format, and question whether every image on the page needs to be there. The third is the one people skip, and the cheapest image is always the one you did not include.