Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

Performance

How do you compress images for a website without losing quality?

How to make website images smaller without visible quality loss: resizing, formats, quality settings, responsive images and lazy loading, in order.

To compress images for a website, first resize them to the largest size they are displayed at, then save them in WebP or AVIF at a quality setting around 75 to 85, and serve different sizes to different screens with srcset. Lazy-load images below the fold. Resizing usually saves more than any compression setting.

Published · Last updated

By Michal Měřínský. Audit methodology.

Why images matter most

Images are usually the heaviest part of a web page, and the hero image is often the element that decides Largest Contentful Paint. Making them smaller is one of the few speed improvements that is almost always safe and visible.

Step 1: resize

A photo straight from a camera or design tool can be 4000 pixels wide. Displayed in an 800 pixel column, three quarters of its pixels are thrown away by the browser after being downloaded. Export at the largest displayed size, or twice that for sharp high-density screens, and no more.

Step 2: choose the format

  • Photos: AVIF or WebP. Both are much smaller than JPEG at similar quality.
  • Graphics with transparency: WebP or AVIF instead of PNG.
  • Logos, icons and illustrations made of shapes: SVG.
  • Animations: video formats or animated WebP instead of GIF.

Step 3: set the quality

For lossy formats, a quality setting around 75 to 85 is usually indistinguishable from the original at normal viewing size. Below that, look closely at text, faces and gradients. Tools such as Squoosh let you compare side by side before choosing.

Step 4: serve the right size to each screen

<img src="/photo-800.webp"
     srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
     sizes="(max-width: 600px) 100vw, 800px"
     width="800" height="533" alt="..." loading="lazy">

The browser picks the smallest file that looks sharp on the visitor's screen. Width and height prevent layout shift while the image loads.

Check what you actually serve

Open the browser's developer tools, go to the Network panel, filter by images and sort by size. The largest files are where to start. Compare each file's pixel dimensions with the size it is displayed at on the page: anything more than twice the displayed width is a resizing job, not a compression job.

Step 5: load only what is needed

Add loading="lazy" to images below the fold. Do not lazy-load the main image at the top of the page, which delays Largest Contentful Paint.

Automate this. Most frameworks, hosts and CDNs can resize and convert images on the fly. Manual compression is forgotten on the next upload.

Where AI builders and CMSs go wrong

Uploaded images are often served as uploaded: full resolution, original format, no srcset. AI app builders frequently reference large stock or generated images directly. Check the actual file size of your biggest images in the browser's network panel.

What a scan can and cannot tell you

WebAuditOS inspects image-URL format hints in served HTML, checks responsive markup when at least three eligible images are present, how large each HTML document is and how long Largest Contentful Paint takes.

It does not calculate the possible savings per image or judge visual quality after compression.

A page can pass the format check with a WebP file that is still five times larger than needed. Check dimensions as well as format.

Short answers

What is the best image format for websites? AVIF or WebP for photos, SVG for logos and icons.

What quality setting should I use? Around 75 to 85 for lossy formats, then check by eye.

Does compression hurt SEO? No. Faster pages help. Keep descriptive alt text and file names.

Should I lazy-load all images? All except those visible when the page first loads.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.