How to Optimise Images for Faster Websites Without Losing Quality

A friend of mine runs a small online store selling handmade ceramics. Last spring she called me in a panic — her homepage was taking almost twelve seconds to load on a phone, and customers were bouncing before her hero image had even appeared. She hadn't touched the site in months. Nothing had "broken." The culprit turned out to be something almost every website owner underestimates: her photos. Beautiful, detailed, 4000-pixel-wide JPEGs straight from her camera, uploaded exactly as they came off the SD card. Once we compressed and resized them, her homepage dropped from 11 MB to under 900 KB, and the load time fell to just over a second.

That story isn't unusual. Images are, by a wide margin, the heaviest thing most websites serve. According to the HTTP Archive, images account for around half of the total weight of an average web page — more than JavaScript, CSS, and fonts combined. And yet image optimisation is one of the few areas where you can make dramatic performance gains without touching a single line of code or hiring a developer. You just need to understand what's actually happening when a browser downloads a photo, and where the wasted bytes are hiding.

Why image weight matters more than you think

When someone visits a page, their browser has to fetch every image referenced in the HTML before it can finish rendering the layout. On a fast fibre connection that might feel invisible. On a phone with a patchy 4G signal in a train tunnel, every extra kilobyte pushes the visible content further down the road. Google's Core Web Vitals — the performance metrics that feed into search rankings — pay very close attention to the largest image on the page, because that's usually the thing users are waiting for.

There's also a business angle that gets overlooked. Cloudflare and Akamai have both published data showing that mobile bounce rates rise sharply after the three-second mark. Amazon famously estimated that every 100 ms of latency cost them roughly 1% in sales. Even if you're not selling anything, slow pages feel cheap. Fast pages feel professional. The perception forms in the first second.

The good news is that images are unusually forgiving to optimise. Unlike JavaScript, where a wrong compression setting can break your site, an image that's been resized or re-encoded still works — it just weighs less. The whole game is about finding the point where the file is as small as possible before your eye can tell the difference.

What actually makes an image "heavy"

Three things determine the size of an image file: its pixel dimensions, its format, and its compression settings. Everything else is a detail.

Pixel dimensions are the most obvious lever, and the most abused one. Modern phones shoot photos at 12 megapixels or more, which is around 4000 by 3000 pixels. A blog post on a laptop is typically 700 to 900 pixels wide. Uploading the raw camera photo means you're asking the browser to download roughly twenty times more image data than the visitor will ever see. The browser dutifully scales it down for display, but the bytes have already crossed the network.

Format matters almost as much. JPEG has been the default for photographs since the 1990s, and it's still fine, but newer formats have quietly overtaken it. WebP, developed by Google, typically produces files that are 25 to 35% smaller than an equivalent JPEG at the same visual quality. AVIF, the newest widely supported format, often halves the size of a JPEG. For flat graphics, logos, and screenshots with sharp edges, PNG remains sensible — but even PNG can usually be trimmed dramatically by a good optimiser.

Compression settings are the last piece. Every lossy format lets you trade quality for size. The trick is that the top of the quality scale is enormously expensive in bytes for a nearly invisible gain. Going from a quality setting of 100 down to 85 in JPEG often cuts the file size in half and produces an image that no human on Earth could distinguish from the original at normal viewing distance.

Understanding lossless versus lossy compression

Before you start crunching files, it helps to know which kind of compression you're applying. Lossless compression rearranges the data more efficiently but preserves every pixel exactly. It's what ZIP archives do. PNG uses lossless compression internally, which is why PNGs of photographs are enormous — there's nothing predictable to compress. Lossless is the right choice for diagrams, logos, screenshots of text, and anything where a single altered pixel would be noticeable.

Lossy compression, used by JPEG, WebP, and AVIF, throws away information that human eyes struggle to see. It exploits the fact that we notice changes in brightness far more than changes in colour, and that we're bad at seeing fine detail in busy areas. The result is a file that looks the same to us but contains a fraction of the data.

The confusion many people have is thinking that "lossy" means "low quality." It doesn't. A lossy image at 80% quality can be visually indistinguishable from the original while being five times smaller. What matters is whether you can perceive the difference, not whether every byte is preserved.

Choosing the right format for the job

There's no single best format. The right choice depends on what's in the image.

For photographs — anything with gradients, skin tones, natural textures, or bokeh — WebP is now the sensible default. Every modern browser supports it, and the savings over JPEG are substantial. AVIF is even better if your audience is mostly on recent browsers, though the encoding process is slower and older devices may struggle to decode very large AVIFs. For a working balance, many sites now serve AVIF where supported and WebP as a fallback.

For illustrations, icons, and graphics with limited colours and sharp edges, PNG or SVG is usually right. SVG is a vector format, which means it's described mathematically rather than as a grid of pixels, and it scales to any size without getting bigger in bytes. A well-made SVG logo can be a few hundred bytes and look crisp on an 8K display. For screenshots or UI mockups, PNG preserves the pixel-perfect edges that JPEG would blur.

Animated content sits in its own category. Animated GIFs are almost always the wrong choice today — they're huge, limited to 256 colours, and look worse than a short MP4 or WebM video. If you find yourself embedding a GIF larger than a couple of hundred kilobytes, convert it to a looping muted video instead. You'll cut the size by 90% and improve the quality at the same time.

Sizing images to match how they're actually displayed

The single biggest mistake people make is uploading images at their original resolution. If your blog's content column is 800 pixels wide, there is almost never a good reason to serve a 4000-pixel-wide image. Retina and high-density displays effectively double that, so a safe rule of thumb is to export images at roughly twice the maximum display width — 1600 pixels in the example above — and let the browser scale down from there.

For hero images and full-width banners on desktop, 1920 or 2400 pixels wide is a reasonable ceiling. Beyond that you're paying for pixels the screen can't show. For thumbnails, 400 to 600 pixels wide is usually plenty.

If you're technically inclined, the srcset attribute in HTML lets you provide multiple sizes of the same image and lets the browser pick the right one for the device. That's the gold standard, and it's what large publishers do. But even if you never touch HTML, simply resizing a single image before upload gets you 80% of the benefit.

One warning: resize down, never up. Enlarging a small image doesn't add detail, it just makes the existing pixels blurry. If you only have a low-resolution source, live with the small size or find a better original.

Practical compression settings that work

For photographs going onto the web, a JPEG quality setting between 75 and 85 is almost always the sweet spot. Below 70 you'll start seeing blocky artefacts in smooth areas like skies. Above 90 you're mostly adding bytes for no visible gain. WebP behaves similarly — a quality of around 75 to 82 tends to match or beat JPEG at 85 while producing a smaller file.

PNGs benefit from a slightly different kind of optimisation. Tools like pngquant reduce the colour palette intelligently and can shrink a typical UI screenshot by 60 to 70% with no visible change. If your PNG is a photograph, though, don't fight it — convert it to WebP instead.

A useful mental check: after optimising, look at the image at 100% zoom on the actual screen it will appear on. Not zoomed in. Not on a 4K monitor if your audience is on phones. If it looks fine, it is fine. Chasing pixel-perfect quality at zoom levels no visitor will ever use is a common way to waste hours and bandwidth.

Common mistakes worth avoiding

A few patterns come up again and again in slow websites, and they're easy to fix once you know to look for them.

Uploading straight from a phone or camera without any processing is the most frequent one. Even a "small" iPhone photo can be 3 to 5 MB, and a page with five of them is already 20 MB before a single word of text is loaded.

Using PNG for photographs is another. A photograph saved as PNG can easily be ten times larger than the same image saved as a well-compressed JPEG or WebP, with no visible quality advantage.

Relying on CSS to resize an oversized image, so it "looks" small on screen but is actually huge in bytes, is a hidden version of the same mistake. The browser still downloads the full file before it shrinks it.

Forgetting to add width and height attributes to <img> tags causes the layout to jump around as images load, which hurts your Cumulative Layout Shift score and generally feels janky to visitors.

Finally, ignoring lazy loading. Modern browsers support loading="lazy" on image tags, which defers downloading images until they're about to scroll into view. It's a one-attribute change that can cut initial page weight in half on long pages.

Beyond compression: how images are delivered

Once your images are the right size and format, the next lever is how they're delivered. A content delivery network — a CDN — stores copies of your files in data centres around the world so visitors download them from a server nearby rather than one halfway across the planet. Most modern hosting platforms include a CDN by default, but if yours doesn't, adding one in front of your images is often the single biggest speed win after compression.

Caching headers matter too. When you tell the browser that an image is safe to cache for a year, repeat visitors don't download it again on their next visit. That's another invisible but significant improvement to perceived speed.

And if you're feeling ambitious, image transformation services can generate the right size and format on the fly, based on what the visitor's device supports. That's overkill for a small blog, but for a busy e-commerce site it's genuinely transformative.

Pulling it all together

Image optimisation isn't glamorous, but it's the highest-leverage performance work most site owners can do. Resize your images to match how they're actually displayed. Choose WebP or AVIF for photographs, PNG or SVG for graphics. Compress at a quality setting in the mid-80s and stop chasing invisible gains. Add lazy loading. Let a CDN handle the last mile.

Do those five things and you'll typically cut page weight by 60 to 90% without any visible loss of quality. Your visitors will notice, even if they can't articulate why the site feels sharper. Your search rankings will notice. And, in the case of my friend with the ceramics shop, your sales will notice.

If you'd like to try some of this without installing software, IntuWebTools has a small collection of free, browser-based utilities that cover the essentials — an image compressor for trimming file size, an image resizer for getting dimensions right, and an image converter for moving between JPEG, PNG, and WebP. Everything runs locally in your browser, so your photos never leave your device. It's a decent place to start if you'd rather experiment than read another tutorial.