Resize before lowering quality
An image displayed at 800 pixels wide rarely needs a 4000-pixel source on the page. Reducing dimensions removes data cleanly and often saves more bytes than aggressive compression. Keep a larger master file outside the website for future layouts or print use.
For high-density screens, exporting near twice the CSS display width is a reasonable upper bound for important images. Responsive image markup can provide smaller alternatives to narrow screens instead of sending the largest file to every visitor.
Choose quality by visual evidence
For a typical WebP or JPG photograph, begin around quality 80 and compare the result with the source. Lower the setting in small steps until artifacts become noticeable, then move back one step. Screenshots, typography and illustrations may need a higher setting or a lossless format.
A quality value is not standardized between encoders. Quality 80 in one application can look different from quality 80 in another, so the preview and final byte size matter more than the number itself.
- Check skin tones and smooth skies for banding
- Check hair, foliage and fabric for smeared detail
- Check text and logos for ringing around edges
- Test the downloaded file, not only the browser preview
Set a page-level budget
Judge images as part of the whole page. A single 300 KB hero may be reasonable, while twenty 300 KB gallery thumbnails are not. Prioritize the first visible images and lazy-load media farther down the page.
Revisit the budget with real devices and slower networks. The useful target is a page that becomes readable and responsive quickly, not the smallest possible image at any visual cost.