Properly Size Images for Web Performance
The most common image mistake on the web, what it costs your visitors, and the fix that takes one batch.
Measure the widest the image ever renders, double it for high density screens, and resize your library to that number. Serving a 4000 pixel photograph into an 800 pixel slot means the browser downloads roughly 25 times more pixel data than it can display, then discards the rest.
On a phone connection the visitor pays for all of it, in time and in data. Properly sizing images is usually the single largest page weight reduction available to a site, and it takes one batch rather than a redesign.
Why oversized images cost so much
File size scales with pixel count, so halving the width and height removes about 75 percent of the data. The relationship is quadratic rather than linear, which is why the waste grows quickly.
| Uploaded size | Displayed at | Wasted pixel data | Typical file |
|---|---|---|---|
| 4000 x 3000 | 800 x 600 | 96 percent | 4.2 MB against 180 KB |
| 2400 x 1600 | 1200 x 800 | 75 percent | 1.1 MB against 290 KB |
| 1600 x 1200 | 800 x 600 | 75 percent | 520 KB against 140 KB |
| 1200 x 900 | 1200 x 900 | 0 percent | 310 KB, correctly sized |
The first row is the common case on sites where editors upload straight from a camera. The browser downloads 4.2 MB, scales it down, and displays the equivalent of a 180 KB file.
How to measure the real display size
Right click the image on your live page, choose Inspect, and read the displayed dimensions rather than the intrinsic ones. Browsers report both figures, and the gap between them is the waste.
Check the widest case rather than the typical one. An image inside an article column may render at 700 pixels on desktop and 380 on a phone, so 700 is the number that matters. Test at the widest browser window your visitors realistically use, since a full width banner grows with the viewport and needs a different calculation.
The doubling rule for high density screens
Multiply the display width by 2 and stop there, because screens beyond that density show no further improvement that anyone notices. An image displayed at 700 pixels should be exported at 1400.
Tripling is occasionally suggested and rarely justified. The difference between 2 and 3 times density is undetectable at normal viewing distance, while the file grows by more than half. Compressing harder at 2 times density produces a better result than compressing lightly at 3 times, because the extra pixels hide the compression.
Common display widths to resize for
- Article body image: displays around 700 px, export at 1400 px.
- Full width hero: displays up to 1920 px, export at 1920 px and compress harder.
- Half width feature: displays around 600 px, export at 1200 px.
- Product grid thumbnail: displays around 300 px, export at 600 px.
- Author or profile photo: displays around 80 px, export at 160 px.
- Logo in a header: displays around 180 px, export at 360 px or use vector graphics.
Why full width images are the exception
A full width banner has no fixed display size, so cap it at 1920 pixels and compress it harder rather than doubling. Doubling a full width image to 3840 pixels produces a file no page can justify.
Banners are usually viewed at a distance and carry less fine detail than a product photograph, which means aggressive compression is less noticeable on them. A 1920 pixel banner at quality 70 in WebP typically lands under 200 KB and looks correct on every screen, while the 3840 pixel version delivers no visible benefit at 4 times the weight.
How to fix a whole library
To resize an existing site correctly, follow these 6 steps.
- List the image slots in your design, which is usually 4 to 6 distinct sizes rather than dozens.
- Measure the display width of each slot using the browser inspector on a live page.
- Double each width to get your export size.
- Sort the library into folders by slot, since a batch applies one size to every file in it.
- Resize each folder to its target width, then compress and convert in the same pass.
- Replace the files keeping the same names so existing pages continue to work.
Sorting into folders is the step that turns this into a batch job. Most sites use far fewer distinct image sizes than they assume, and grouping by slot removes the need to handle files individually.
Responsive images and the srcset attribute
Use srcset to offer several sizes and let the browser pick the right one for each device. A phone then downloads a 400 pixel file while a desktop downloads a 1400 pixel file from the same markup.
Generate 3 widths per image, commonly 400, 800 and 1600 pixels, and list them with their pixel widths so the browser can choose. Most content systems produce this automatically on upload, so check what your platform already does. Where it does, uploading a correctly sized original still improves every generated variant.
Resize before compressing, always
Resizing first means compression has less work to do, so quality can stay high while the file stays small. Compressing first and resizing afterwards discards detail you then throw away again.
The order also affects how the result looks. An image compressed at full size carries artefacts that become more visible when the image is scaled down, since the artefacts scale with it. Resizing first produces a cleaner source for the encoder and a noticeably better result at the same file size.
What this does to page speed
Properly sizing images typically removes 60 to 90 percent of image weight on a site that has never done it. The improvement is larger than any format change and usually larger than every other optimisation combined.
The effect concentrates on mobile visitors, where connections are slower and data costs money. Largest Contentful Paint improves directly, since that measurement is normally decided by one large image. Clearing the Properly size images audit in Lighthouse frequently clears 2 or 3 related warnings at the same time.
Never enlarge an image to fit
Enlarging adds pixels the camera never captured, so the result is soft and the file grows for no benefit. Resizing down is always safe, while resizing up is the one operation that reliably looks worse.
Where a source image is smaller than the slot it must fill, the honest options are to use it at its natural size, crop the layout around it, or replace the image. Enlarging a 600 pixel photograph to 1600 pixels produces a blurry file 4 times the weight of the original, which fails on both quality and speed at the same time.
Checking a page for oversized images
Open developer tools, switch to the Network tab, filter by images and reload the page. The list shows every image with its transferred size, sorted largest first.
Any single image over 500 KB is worth investigating, and any page where images total more than 2 MB has a problem. Hover over an image in the Elements panel to see its intrinsic and displayed sizes side by side. A large gap between the 2 numbers is the definition of an improperly sized image, and it is visible in seconds.
Resizing a library in one batch
Set the target width once and apply it to every file in a folder, rather than resizing images individually. A library of several hundred images resizes in minutes when the work is batched.
Drop up to 500 files in at once, or drag a ZIP archive straight in, and set the width, format and compression target for the whole set. Everything runs inside your browser on your own processor, so client sites, staging assets and unpublished galleries never reach a server. Nothing is uploaded, which means a full library resize happens without a single file crossing the network.