Optimising images for a faster website

On a typical content site, images account for more downloaded bytes than HTML, CSS, JavaScript and fonts combined. They are also the easiest part of the stack to fix: no build tooling, no framework migration, no arguing about dependencies. Four decisions, applied consistently, will usually cut your image payload by 70–80%.

In order of how much they matter: dimensions, format, quality, metadata. Most people start with quality, which is the one that matters least.

1. Dimensions: the saving everyone skips

The single most common problem on the web is a 4000px photo displayed in a 600px-wide column. The browser dutifully downloads all 16 million pixels and throws 97% of them away. No quality setting can recover from that; you are simply sending 20× more data than the page can use.

Work out the widest the image is ever actually rendered, then double it for high-density screens. A 600px column on a 2× display needs a 1200px image. Round up to something tidy and cap everything there.

Use Max box mode in the Image Resizer rather than an exact size. It caps anything larger and leaves already-small images alone, which is exactly the policy you want applied across a whole content folder.

2. Format: convert the screenshots first

WebP is typically 25–35% smaller than JPEG at matched quality, and routinely half the size of a PNG screenshot. Every current browser supports it. If your site is still serving PNG screenshots and JPEG photos, converting them is the largest single win available, and it is visually free.

AVIF goes further — often 40–50% below JPEG — and is worth it for the handful of large photographs that dominate a page's weight. It encodes slowly, so it is a poor fit for bulk conversion but an excellent one for your hero image.

There is more detail in JPG vs PNG vs WebP vs AVIF, including what happens to transparency when you convert.

3. Quality: stop at 80

Quality 80 is where the curve flattens. Above it you pay a lot of bytes for detail nobody perceives; below it you start to see softening in textured areas. For thumbnails, where the image is displayed small anyway, 70 is comfortable.

Check rather than assume. The Image Compressor shows the original and the result side by side at full resolution with a draggable divider. Test on your most detailed image, not your simplest one — if the setting holds up there, it holds up everywhere.

4. Metadata: small, but free

A phone photo carries EXIF data: camera model, lens, exposure, timestamps, an embedded thumbnail, sometimes a colour profile, and often GPS coordinates. It is usually tens of kilobytes per image, and none of it does anything on a web page.

Stripping it saves a little bandwidth and removes a genuine privacy problem at the same time — publishing the GPS coordinates of where a photo was taken is rarely intentional. See How to remove EXIF data from photos for what is in there and how to check.

A workflow for a whole site

1. 1Audit what you haveRun your heaviest images through Image Analyzer. It reports dimensions, weight, transparency and colour, and flags the obvious problems — oversized, wrong format, transparency that is never used.
2. 2Set one policyFor example: max 1600px wide, WebP, quality 82, metadata stripped. Write it down. Consistency matters more than the exact numbers.
3. 3Run the folder through Batch Image ToolsBatch applies resize, compression, conversion and watermarking across the whole queue in one decode per image, and returns a ZIP.
4. 4Spot-check the worst casesLook at the most detailed photo and the screenshot with the smallest text. If those two survive, the rest will.
5. 5Keep the originalsCompression is one-way. Keep a folder of untouched masters so you can re-export when your policy changes.

The HTML matters too

Optimised files still load badly if the markup is wrong. Three things are worth getting right:

• Always set `width` and `height` on <img>. Without them the browser cannot reserve space, the page jumps as images arrive, and your Cumulative Layout Shift score suffers. The dimensions are shown on every result in ImageDoctor.
• Lazy-load everything below the fold with loading="lazy" — but never the hero image, which should load immediately and can take fetchpriority="high".
• Serve the right size per screen with srcset and sizes. Export 2–3 widths of each important image rather than sending a desktop-sized file to a phone.

Realistic expectations

A page with 12 unoptimised phone photos might weigh 30 MB. Capping at 1600px takes it to roughly 6 MB. Converting to WebP at quality 82 takes it to around 1.5 MB. Stripping metadata shaves a little more. That is a 95% reduction, and nobody looking at the page can tell the difference.

You do not need a build pipeline or a CDN to get that. You need one policy and one pass through a batch tool.