Images are almost always the heaviest thing on a web page and almost always the easiest thing to fix. A page carrying 6MB of photographs will fail a Core Web Vitals assessment no matter how clean the code is.
Targets worth aiming for
Rough numbers that hold up in practice:
These are guidelines, not rules. A photography portfolio has different constraints from a documentation site. But if a single image on your page is over 500KB, that is worth a look regardless of what kind of site you run.
Resize before you compress
This is the step people skip, and it matters more than the compression setting.
If your image is displayed at 800 pixels wide but the file is 4000 pixels wide, you are sending five times the pixel data the browser will use. No compression setting fixes that — you are compressing four thousand pixels of width to deliver eight hundred.
Work out the largest size the image is actually displayed at, double it for high-DPI screens, and resize to that. An 800px-wide slot means a 1600px image. Then compress.
Doing it in this order routinely produces files a fraction of the size for no visible difference, because you removed data that was never going to be seen.
How far to compress
For JPEG, quality 75 to 85 is the useful band. Below 70 artefacts start showing on detailed images; above 85 you are adding file size for quality nobody perceives on a screen.
The right number depends on content:
Look at the result at 100% zoom before shipping it. Compression damage is easy to miss in a thumbnail and obvious on a large screen.
Format matters more than quality settings
Picking the right format often beats fine-tuning compression:
JPEG for photographs. Decades of universal support, good compression on continuous-tone images.
PNG for screenshots, images with text, and anything needing transparency. Lossless, so no artefacts, but much larger for photographic content.
WebP for both, if you can. Roughly 25-35% smaller than JPEG at equivalent quality, with transparency support. Supported in every current browser. Our [WebP converter](/webp-converter) handles conversion in both directions.
SVG for logos, icons and simple illustrations. Tiny, infinitely scalable, and often smaller than a PNG of the same graphic at a single size.
Where compression stops helping
Diminishing returns arrive quickly. Going from 2MB to 200KB transforms your page load. Going from 200KB to 180KB changes nothing a user will notice, and if you got there by dropping quality to 60, you made the page worse for no measurable gain.
Once the largest image on the page is comfortably under a couple of hundred kilobytes, your bottleneck has moved elsewhere — render-blocking scripts, web fonts, third-party embeds. Chasing further image savings at that point is effort spent on the wrong problem.
Do not forget lazy loading
Compression reduces how much each image weighs. Lazy loading reduces how many get downloaded at all. Adding a loading attribute of "lazy" to images below the fold is a one-word change that often does more for perceived speed than another round of compression.
Keep it off your hero image, though — lazy-loading the thing that defines your LCP makes the metric worse, not better.