Serve the size you actually display
This is where most of the waste is. An image displayed in a 600-pixel-wide column does not benefit from being 4000 pixels wide — the browser downloads all of it, then throws away 97% of the data to draw it.
The rule: export at roughly twice the display width, capped at something sensible. Twice, because high-density screens draw two physical pixels per CSS pixel and will otherwise look soft. So a 600-pixel column wants a 1200-pixel image, not a 4000-pixel one.
For a full-width hero on a large screen, 1600–2000 pixels wide is usually plenty. Beyond that you are paying real download time for a difference nobody can see.
Pick the format by what the image is
- Photographs → WebP. Roughly 25–35% smaller than JPEG at the same visual quality, and every current browser reads it. JPG to WebP
- Logos, icons, anything with transparency → WebP too. It supports an alpha channel, so it replaces PNG here as well and is substantially smaller. PNG to WebP
- Screenshots with text → PNG, or WebP in lossless mode. Lossy compression attacks exactly the hard edges that make text readable.
- Simple icons and logos → SVG, if you have the vector original. It scales to any size and is usually a fraction of the size of any raster format.
AVIF compresses better still, but desktop and tooling support lags, so use it only if you
can serve a fallback with a <picture> element.
Quality: stop at 75–85%
Export defaults often sit at 95–100%, which costs a large share of the file for detail almost nobody can perceive. For web photographs, 75–85% is indistinguishable in normal viewing and commonly halves the file. Below 60% you start to see it in skies and skin.
If you have a specific page-weight budget in mind, the compress-to-a-size tool works backwards from the byte target rather than the quality number — set 150 KB and it finds the best quality that fits.
The two attributes that matter more than compression
These cost nothing and fix problems compression cannot:
Always set width and height on the tag. Without
them the browser does not know how much space to reserve, so the page reflows when each image
arrives — text jumps down the screen while someone is reading it. That is Cumulative Layout
Shift, it is a ranking signal, and it is the most irritating thing a slow page does. The
numbers do not have to match the display size; they establish the aspect ratio.
Use loading="lazy" on images below the fold — and only those.
Deferring off-screen images is a clear win. Putting it on your hero image is a clear loss: it
delays the one image the visitor is waiting for. A useful rule is that anything visible
without scrolling should load eagerly.
A realistic before-and-after
A page with eight photographs straight from a camera:
- Before: 8 × 4000 px JPEGs at 95% quality ≈ 8 × 4 MB = 32 MB. On a mid-range mobile connection, well over a minute.
- After: resized to 1200 px, converted to WebP at 80% ≈ 8 × 90 KB = 720 KB. Around two seconds.
That is a 97% reduction, and on a screen the two pages look identical. Almost all of it came from resizing and the format change rather than from the quality setting.
Things that quietly cost you
- Uploading straight from a phone or camera into a CMS. Many will not resize for you, and the original goes out to every visitor.
- PNG photographs. Common, and usually five to ten times larger than necessary. PNG to JPG
- Decorative images that carry no information. The cheapest image is the one you do not ship. A CSS gradient or background colour often does the same job for nothing.
- Missing
alttext. Not a performance issue, but it is an accessibility requirement and search engines read it.