How to reduce image file size for websites

Images are normally the heaviest thing on a web page, and the easiest thing to fix. The three causes are almost always the same: pictures served far larger than they are displayed, screenshots left as PNG, and export settings nobody has revisited since the site was built.

This guide is about the numbers — what to aim for and how to get there. For the performance side of the story, including what actually moves Core Web Vitals, see optimising images for faster website loading.

Size budgets worth aiming at

There is no official limit, but these targets are comfortably achievable without visible quality loss, and they make a real difference on a phone connection.

Treat the page total as the one that matters. A single 180 KB hero is fine; twelve 180 KB images on the same screen is a two-megabyte page, and on a slow connection that is the difference between a site that feels instant and one that does not.

The order that does the work

Each step below saves more than the one after it. Doing them in this order means the expensive work happens on the smallest possible image.

1. 1Cap the dimensionsNothing on a normal page needs to be wider than about 2400px. This single step often removes more bytes than everything else combined — see resizing without losing quality.
2. 2Convert to a modern formatWebP for essentially everything; AVIF for large heroes if your tooling handles it. Converting PNG screenshots is usually the biggest single win on a site.
3. 3Compress once, at quality 80Then check at 100% zoom on the most detailed part. Lower only if the image can take it; raise it for anything containing small text.
4. 4Strip the metadataCamera settings, GPS coordinates and embedded thumbnails add weight and leak information about where a photo was taken.
5. 5Re-measureCheck the page again afterwards. It is the only way to know whether the change landed where you expected.

Find the worst offenders first

You do not need to optimise every image on the site. A handful are usually responsible for most of the weight.

1. Open the page in your browser's developer tools and look at the Network tab, filtered to images, sorted by size.
2. Note anything over 300 KB, and anything whose natural width is more than double the width it renders at.
3. Fix those. Re-measure. In most cases that is the project finished.

Browsers also warn about oversized images in their own audits, which is a fast way to find the mismatches without checking each one by hand.

The format decision, briefly

• Photographs — WebP at quality 80. JPEG is a fine fallback if something in your pipeline cannot produce WebP.
• Screenshots and UI images — WebP at 85–90. These are the PNGs quietly costing a megabyte each.
• Logos and icons — SVG if you have it, since it is tiny and scales perfectly. PNG or lossless WebP otherwise.
• Anything with transparency — WebP or PNG. Never JPEG.

WebP vs JPG vs PNG goes into when each one earns its place, and when the conversion is not worth the trouble.

Platform notes

WordPress

WordPress generates several sizes of every upload and serves them through srcset, so the crucial thing is what you upload in the first place. Uploading a 6000px camera file means every generated size is derived from it and the original sits in the media library forever. Resize and convert before uploading, and the plugin stack has much less to do.

Shopify and other hosted stores

Product images are usually resized and served from a CDN automatically, but the source still sets the ceiling on quality and the floor on upload time. A consistent 2000px square, compressed once, is a good house standard for a catalogue.

Static sites and frameworks

Build-time image pipelines handle sizing and format conversion well. They cannot fix a source image that is a 4 MB PNG screenshot, so it is still worth optimising what goes into the repository — and it keeps the repository smaller too.

Mistakes that add weight back

• Compressing an image that is still 5000px wide. Resize first; dimensions save far more than the quality slider.
• Running four tools in sequence. Each one re-encodes the file. Use one batch pass instead.
• Uploading straight from the camera or phone. Those files are two to five megabytes each and carry full metadata.
• Serving a 1600px image inside a 400px card. The visitor downloads all of it and sees a quarter of it.
• Optimising once and forgetting. New images arrive weekly. Write the policy down so whoever uploads next follows it.