Ordered roughly by how much file size each one recovers.
1. Resize to the display size
The single biggest lever, and the one most often skipped. An image displayed at 600 CSS pixels wide does not need to be 2400 device pixels wide unless you are targeting 2x displays — and even then, 1200 is usually the right number.
Halving each dimension removes 75% of the pixels and roughly 75% of the bytes.
2. Choose the right format
A PNG screenshot exported as WebP is typically 90% smaller with no visible difference. Run the format converter before anything else.
3. Turn the quality down — then stop
Below about 80 the returns collapse: you go from 200 KB to 130 KB and lose visible detail. Above 95 you are wasting bytes. Find the knee and stop.
4. Reduce the colour count where it is legitimate
Logos, diagrams, screenshots of flat UI: quantising to 256 colours before encoding can halve a PNG. It wrecks photographs and gradients, so use judgement.
5. Strip metadata
EXIF can carry a full-resolution thumbnail, GPS coordinates, camera serial numbers and editing history — sometimes a fifth of the file. Canvas-based conversion drops all of it automatically, which is a privacy win as well as a size win.
6. Encode progressively for JPG
A progressive JPEG renders a blurry preview immediately and sharpens as it loads. File size is effectively unchanged, perceived load time is better.
7. Serve responsive sizes
Do not send a phone a 2000 px image. Generating a small variant and using srcset lets the browser pick. This is a delivery change, not a file change, but it is the one with the biggest real-world effect.
What does not work
- Compressing an already-compressed file repeatedly. Every generation loses
more information for a smaller file. Re-encode from the master instead.
- Lossy compression on line art. Text edges get ringing artefacts that get
worse each pass.
- Optimising images nobody scrolls to. Below-the-fold images can be lazy
loaded instead, which is free.