Website Image Optimisation | Fix Slow Loading Images

Ask most small business owners why their website is slow and they'll blame their hosting. Nine times out of ten, the real culprit is sitting in plain sight: a handful of photos taken on a modern phone, uploaded straight to the site at full size, quietly weighing several megabytes each. Here's how to fix that without needing to learn any code.

Why a phone photo is so much bigger than it needs to be

A modern smartphone camera captures images at a resolution designed for printing or zooming in, not for displaying on a webpage. A single photo can easily be 12 megapixels and 3-5MB in size. Your website almost never needs anywhere close to that.

If that same image is displayed at, say, 800 pixels wide in a content column, everything beyond that resolution is completely wasted data that a visitor's browser still has to download before it can show anything. Multiply that across five or six images on a single page and you've got a page that's transferring tens of megabytes before anyone has read a word.

Getting the dimensions right

The rule of thumb is simple: an image should never be uploaded wider than the largest size it will actually be displayed at. A full-width hero banner might genuinely need to be 1600-1920 pixels wide. A photo inside a two-column blog layout rarely needs to be more than 800 pixels wide. A thumbnail or team photo might only need 400.

If you're not sure what size a slot on your page actually displays at, right-click the image in a browser, choose "Inspect", and the rendered dimensions will be shown in the element panel. Resize the source image to match, rather than uploading the original and letting the page squash it down with CSS — that just means visitors download the full file for nothing.

Format matters more than most people think

JPEG has been the default photo format for decades, but WebP is now the sensible default for the web. It typically produces files 25-35% smaller than an equivalent JPEG at the same visual quality, and it's supported by every browser in meaningful use today. AVIF compresses even harder in many cases, but takes longer to encode and isn't quite universally supported yet, so serving WebP with a JPEG fallback is a safe, practical approach for most small business sites.

PNG should be reserved for images that genuinely need transparency or crisp flat colour, such as logos — it's a poor choice for photography, where it produces far larger files than JPEG or WebP for no visible benefit.

Compression: the part everyone skips

Even at the correct dimensions and in the correct format, an image can usually be compressed further with barely any visible loss of quality. Most images can tolerate 60-80% JPEG or WebP quality settings without a visitor noticing any difference, and that alone can halve the file size again.

As a target, aim for:

Under 200KB for a full-width hero image
Under 100KB for images inside the content, below the fold
Under 30KB for small thumbnails, icons or team photos

There are plenty of free tools — Squoosh, TinyPNG and similar — that will compress and convert an image in a browser tab with no software to install, which is a perfectly good manual option for a small site with occasional updates.

Lazy loading — and the one image that must never be lazy loaded

Lazy loading tells the browser to skip downloading an image until the visitor is about to scroll to it, which saves bandwidth on long pages with lots of images below the fold. It's a genuinely useful technique and easy to add with a single HTML attribute.

The one image that must never be lazy loaded is the hero image at the top of the page — the largest visible element visitors see first. Lazy loading it delays the exact moment measured by Largest Contentful Paint, which is one of the three Core Web Vitals Google uses to judge page experience. Get this the wrong way round — lazy-loading the hero and eagerly loading everything below it — and you'll actively make your loading speed worse while thinking you've improved it.

Setting width and height to stop layout jumping

Every image on a page should have its width and height specified in the HTML (or an aspect-ratio set in CSS), even though the browser could technically work this out once the file has downloaded. Without it, the browser doesn't know how much space to reserve, so the page jumps around as each image arrives — pushing text and buttons downward mid-read.

That jumping is measured directly by Cumulative Layout Shift, and it's one of the most common — and most easily fixed — issues we find on small business sites. It costs nothing to fix beyond adding two attributes to each image tag, but it's routinely skipped. Our guide to PageSpeed Insights covers how this shows up in a speed test report.

WordPress vs a hand-coded build

On WordPress, image optimisation usually relies on a plugin — something like ShortPixel, Imagify or Smush — to automatically resize, compress and convert uploads to WebP. That works, but it adds another plugin to keep updated, another subscription in some cases, and another piece of the stack that can conflict with something else on the site.

On a hand-coded static site, this is typically handled once at build time: images are resized, compressed and converted to modern formats automatically as part of shipping the site, with no plugin, no ongoing subscription and nothing for a client to configure. It's one of the quieter advantages of a hand-coded website over a plugin-based one, though if a client specifically needs WordPress — for example, for a content team that publishes daily — we set up the same discipline through our WordPress builds instead.

Common questions

What size should website images be?

As a rule of thumb, no wider than the space they occupy on screen — usually 1600px for a full-width hero and 800px or less for anything inside a content column. Aim for under 200KB per image, and well under 100KB for anything below the fold.

Should I use WebP or AVIF?

WebP is the safe default in 2026 — universally supported and typically 25-35% smaller than an equivalent JPEG. AVIF compresses even harder but takes longer to encode. Serving WebP with a JPEG fallback covers essentially every visitor.

Does lazy loading help or hurt SEO?

It helps, as long as you never lazy load the main image at the top of the page. Lazy loading the hero image delays your Largest Contentful Paint, which is exactly the metric you're trying to improve.

Do I need a plugin to optimise images?

On WordPress, usually yes. On a hand-coded site the compression and format conversion happen at build time, so there's nothing to install, configure or keep updated.

Want a website that does this automatically?

Every site we build is hand-coded for performance, SEO and security from day one. Free, no-pressure chat — usually within a day.

Start a project →See how we work

Why Your Website Images Are Probably Slowing You Down