Images

How to Optimise Images for a Faster Website

Images are usually the heaviest thing on a web page. How to pick the right format and dimensions, how many sizes you actually need, and which loading attributes matter.

8 min read · Updated 2026-07-24

On a typical web page, images account for more transferred bytes than HTML, CSS, JavaScript and fonts combined. They are also the easiest thing to fix — unlike JavaScript, where cutting weight means removing features, image optimisation is mostly free. You end up with the same page, visually identical, at a fraction of the size.

The three levers, in order of impact

1. Serve the right dimensions. The single biggest win, and the most commonly missed.
2. Use a modern format. AVIF or WEBP instead of JPEG or PNG.
3. Compress sensibly. Quality 80 rather than 100.

Most sites skip straight to the third and wonder why the gains are modest. A 4000-pixel photograph compressed to quality 80 is still a 4000-pixel photograph — you saved 40% on something that was 20 times larger than it needed to be.

Dimensions: stop shipping 4000-pixel images

The most common performance problem on the web is an image displayed at 400 pixels wide that was uploaded at 4000. The browser downloads all 16 megapixels and then throws away 99% of them during rendering.

The rule: serve an image at roughly twice its maximum CSS display width, to look sharp on high-density screens, and no more.

Going beyond 2× is waste. The difference between 2× and 3× on a high-density display is not perceptible in normal viewing, and it costs you real bandwidth on exactly the mobile connections that can least afford it.

Format: AVIF, then WEBP, then JPEG

For the same visual quality, AVIF is typically around half the size of JPEG and WEBP around 70% of it. Both are supported by every current browser, so the only reason to still ship JPEG is as a fallback for old clients.

The `<picture>` element handles this cleanly — the browser takes the first source it understands and ignores the rest:

• A `<source>` with `type="image/avif"` first.
• A `<source>` with `type="image/webp"` second.
• An `<img>` with a JPEG `src` last, as the universal fallback.

Our Image Converter produces all three from a single original. On browsers that can display AVIF but not encode it, the converter falls back to WEBP rather than failing silently — worth knowing if your output does not match what you asked for.

One format exception: do not convert logos and icons to raster formats at all. If you have an SVG, ship the SVG. It is usually smaller than any raster equivalent and scales perfectly at every size.

Quality: 80 is the answer

For photographic content, JPEG or WEBP quality 80 is where the curve bends. Below it, artifacts start becoming visible on faces and gradients. Above it, file size climbs steeply for differences nobody can see.

Two adjustments to that default: images containing text or sharp graphics benefit from quality 85–90, because ringing artifacts around edges are more noticeable than softening in a photograph. And very small thumbnails can go down to 65 — at 150 pixels there is not enough area for artifacts to register.

Loading behaviour

Beyond the files themselves, a few HTML attributes make a measurable difference.

• `loading="lazy"` on images below the fold. The browser defers loading until the user scrolls near them. Do not put it on your hero image — that delays your Largest Contentful Paint, which is the opposite of what you want.
• `width` and `height` attributes on every image. These let the browser reserve the correct space before the image arrives, preventing the page from jumping as things load. This is the main cause of Cumulative Layout Shift and it is trivially fixable.
• `fetchpriority="high"` on the hero image, telling the browser to fetch it ahead of other resources.
• `decoding="async"` so image decoding does not block rendering.
• `alt` text on everything. Required for accessibility and screen readers, and it is what displays if the image fails to load. Decorative images take `alt=""` — empty, but present.

A workable process

1. Start from the highest-resolution original you have. Never optimise an already-optimised file.
2. Crop to the aspect ratio your layout actually uses, rather than relying on CSS to crop at render time — you are shipping the discarded pixels either way.
3. Resize to your chosen widths, typically 640 / 1280 / 1920.
4. Convert each to AVIF and WEBP, keeping a JPEG fallback.
5. Compress at quality 80 for photos, 85–90 for graphics with text.
6. Mark up with `<picture>`, `srcset`, explicit dimensions and appropriate loading attributes.
7. Measure. Run the page through a performance audit and check what actually changed.

Steps 2 through 5 are batch operations — our Image Resizer and Image Compressor both accept multiple files and return a ZIP, which makes processing a whole gallery reasonable rather than tedious.

Frequently asked questions

How much can I realistically save?

On a site that has not been optimised, 70–90% of image weight is typical. Most of that comes from serving correct dimensions rather than from compression. A page going from 6 MB to 800 KB is a normal result, not an exceptional one.

Should I use AVIF or WEBP?

AVIF where you can, WEBP as the fallback below it, JPEG below that. AVIF compresses better but encoding is slower and support outside browsers is still patchy. The `<picture>` element lets you ship all three and costs nothing.

Does image optimisation affect SEO?

Indirectly but meaningfully. Page speed is a ranking signal, and Core Web Vitals — particularly Largest Contentful Paint and Cumulative Layout Shift — are frequently dominated by images. Alt text also matters for image search.

What about a CDN with automatic optimisation?

Services that resize and reformat on the fly are excellent and remove most of this work. They cost money and add a dependency. Optimising your source images is still worthwhile — a CDN converting an oversized original is doing avoidable work on every cache miss.

Should I strip EXIF metadata?

Yes, for web delivery. It saves a few kilobytes per image and, more importantly, removes GPS coordinates and camera serial numbers you probably did not intend to publish. Most compressors strip it by default.

Can I do all this without uploading my images somewhere?

Yes — every step here runs in your browser on this site. That matters more than it sounds for unreleased product photography, client work under NDA, or anything else you would rather not hand to a third-party service.