Compress a photo for the web

Images are usually most of the page

On a typical page, images account for the majority of transferred bytes — far more than scripts or stylesheets. That makes them the highest-leverage thing to optimise, and the one most often left untouched.

They also tend to be the Largest Contentful Paint element, the metric Google uses to judge loading performance. A slow hero image does not just make the page feel sluggish; it is literally what the score measures.

Serve the size you display

The most common waste on the web is a 3000-pixel image displayed in a 600-pixel slot. The browser downloads all of it and throws most away.

Export at the size it will actually be shown at, allowing for high-density screens — roughly twice the CSS pixel width is a sensible ceiling, beyond which the difference is imperceptible. For images whose display size varies with viewport, serve several sizes and let the browser choose with srcset.

Format and quality for the web

WebP is the sensible default: universally supported in browsers and 25–35% smaller than JPEG at matched quality. AVIF is smaller again and worth the slower encode for large hero images.

Quality 80–85 is right for almost everything. Above 90 is wasted bytes on an image nobody will inspect at full size, and the difference is invisible once the image is scaled into its slot.

Beyond the file itself

A few things matter as much as size:

• Set explicit width and height so the browser reserves space — otherwise content jumps as images load, which is what Cumulative Layout Shift measures.
• Lazy-load images below the fold, but never the hero image, which needs to load as early as possible.
• Strip metadata from web images: it is a few kilobytes per file with no benefit to a visitor, and it may contain location data.
• Keep the colour profile, though — removing it can make a wide-gamut image render flat and washed out.