Website images: format, size and compression

The short rule: photos go in JPEG or WebP, logos and icons in SVG, screenshots in PNG. Upload each image at the size it actually appears on screen, not the size it came off the camera, and compress it before it goes on the site. Do just that and you've fixed most of the speed problems that come from images.

Which format for which image

Pick the format based on what's in the picture, not out of habit.

MDN's image format guide says the same: lossless compression for screenshots, diagrams and logos, because blurry edges show right away there, and SVG for anything that has to be drawn accurately at several sizes.

The mistake we see a lot is the reverse: a patio photo saved as PNG. It looks the same, but the file is much bigger.

WebP and AVIF: what you can use right now

WebP is the format we recommend for photos in 2022. Google's documentation on web.dev says WebP files usually come out 25–35% smaller than the equivalent JPEG. Every major browser shows it. The one catch is on the Mac: Safari only displays it from version 14, on macOS Big Sur or newer. That's why we serve WebP with a JPEG fallback, and the browser picks the one it can show.

AVIF compresses even better. MDN puts it at roughly half the size of a JPEG. Chrome supports it from version 85 and Firefox from 93, but Safari doesn't yet. So AVIF only goes on a site with a fallback behind it, never on its own.

How big to upload

A phone shoots photos several thousand pixels wide. On the site, that same photo might sit in an 800-pixel box. Upload the original and the browser downloads all of it, then shrinks it. Your visitor pays in time and mobile data for pixels they never see.

The right fix is to prepare two or three widths for large images and tell the browser which is which, using the srcset and sizes attributes. The browser then picks the right one for the screen. In MDN's example, the 480 px version is 63 KB and the 800 px version is 128 KB; on a narrow phone only the first one downloads, saving about 65 KB on a single image. On a gallery page, that adds up fast.

Phone screens have more physical pixels than layout pixels. An image that takes up 320 pixels on screen only looks crisp on a good phone at 640 real pixels. srcset handles that too.

Compression you can't see

Every editing app has a quality setting on export. There's no magic number: lower it step by step and compare the result with the original at actual size, on screen. When you can't tell the difference anymore, stop. Photos with sky or smooth backgrounds show artifacts first, as banding in the color, so stop earlier on those.

Two more things on export:

• strip the EXIF data (camera, GPS location), which does nothing on a website and sometimes says more than you'd like;
• name the file with words, like restaurant-patio-evening.webp, not IMG_4532.jpg.

Loading: what shows first and what waits

The loading="lazy" attribute holds off downloading images further down the page until the visitor gets close to them. It works without any script. The web.dev guide is clear, though: don't put it on images that are visible right away, especially the big one at the top. That's the one you want on screen as fast as possible.

Always set width and height on images. That way the browser reserves the space before the image arrives, and the text doesn't jump when it loads. That jump is measured in Core Web Vitals as CLS, and a good score is 0.1 or less. We explained how to read these metrics in our post on Core Web Vitals in plain language.

If you want to see how your site does on images, we can look at it together. What we do is on our web services page.