Images are usually the heaviest thing on a web page. A typical "optimised" hero image is still 800 KB; the same photograph as AVIF is 240 KB; and a sensible thumbnail of it is 24 KB. Getting from the first number to the last is worth more than most of the other front-end work you will ever do.
Start with the number, not the tool
Do not begin by opening a compressor. Begin by deciding what the image has to achieve:
- Hero / above the fold — this is the Largest Contentful Paint element.
Budget 150–300 KB for a full-width photo.
- In-article image — 80–200 KB is plenty at a content column width.
- Thumbnail or card — anything under 60 KB. Nobody can tell.
- Open Graph preview — 1200 × 630 and under 300 KB.
Once you have a number, the tool choice becomes obvious.
Pick the right format
| Format | Use it for | Why |
| AVIF | Photography, anything modern | Best compression available | | WebP | Everything on the web | Near-AVIF sizes, encodes fast | | PNG | Screenshots, flat art, transparency | Lossless, no artefacts | | JPG | Email, print, legacy software | Universal support | | SVG | Icons and logos | Vector, infinitely scalable |
WebP is the safe default. AVIF is roughly 30% smaller again and every current browser can decode it, but encoding is slow enough that some build pipelines avoid it.
Quality is not linear
This is the part most guides get wrong. Going from quality 100 to 90 on a photograph typically saves 55% of the file and nobody can see the difference. Going from 90 to 70 saves another 20% and starts to show around the edges of high-contrast areas. Going below 50 usually halves the file again at the cost of obvious JPEG artefacts around text and edges.
For a photographic hero: 80–85 in WebP is the sweet spot. For a screenshot: 90 or above, or use lossless WebP.
Hit an exact file size
Hand-tuning a slider per image does not scale. If you need "no more than 200 KB", let a tool search for you: encode at a quality, measure, adjust, repeat. The PixelForge converter does this in about seven iterations, and only falls back to reducing dimensions when no quality level can meet the target.
Do not upscale
Enlarging a 800 px image to 1600 px multiplies the byte count by roughly four and adds no detail. If a design calls for a larger image, either use a larger source photograph or accept the softness and keep the smaller file.
Write the width and height attributes
Resizing at build time is the cheapest possible performance win: the browser knows the layout before the bytes arrive, so nothing shifts. Every modern converter can bake the dimensions in.
Verify, do not assume
Open the network panel, load the page on a throttled connection, and look at what actually transferred. The number you optimised is not always the number the browser downloads — a cache miss on an un-cached image is.