How to Make Your Website Load Faster with Optimised Images

18 August 2026 · 9 min read

On a typical website, images account for more downloaded bytes than the HTML, CSS and JavaScript combined. They are also, conveniently, the easiest part of a page to fix — you don't need to refactor any code to make an image smaller.

The catch is that most advice on this topic is a shapeless list of tips. Order matters enormously here: doing step one properly often makes steps three and four almost irrelevant. Here's the sequence that actually works.

First, understand which metric you're fixing

Google measures page experience through Core Web Vitals. Two of the three are directly affected by images:

Largest Contentful Paint (LCP) — how long until the biggest visible element finishes rendering. On most pages that element is an image. Target: under 2.5 seconds.
Cumulative Layout Shift (CLS) — how much the page jumps around while loading. Images without declared dimensions are the classic cause. Target: under 0.1.

Everything below is aimed at one of those two. If a change doesn't affect either, it's probably not worth your time.

Step 1: Resize before you do anything else

This is the step people skip, and it is by far the biggest win.

A photo straight from a modern phone is often around 4000 pixels wide. If it's displayed in a column that is 800 pixels wide, roughly 96% of those pixels are downloaded, decoded, and then thrown away by the browser. No amount of clever compression fixes that — you're compressing data that shouldn't be there in the first place.

Work out the largest size the image will ever actually be displayed at, double it for high-density (retina) screens, and resize to that. For an 800-pixel content column, export at 1600 pixels wide. That single change routinely cuts file size by 80–90% before any compression is applied.

You can do this in your image editor, or with our image resizer.

Step 2: Pick the right format

Once the dimensions are sane, format choice is the next biggest lever:

Photographs → WEBP (typically 25–35% smaller than JPG at the same quality)
Logos, icons, screenshots, anything with transparency → PNG, or lossless WEBP
Simple icons and logos → SVG where possible. Vectors scale infinitely and are often only a couple of kilobytes.

If you want to go further, AVIF compresses better again, though encoding is slower and tooling support is thinner. A sensible modern setup serves AVIF with a WEBP fallback and a JPG fallback beneath that — but honestly, if you're currently serving 4MB JPGs, just getting to properly-sized WEBP will capture most of the available gain.

Our JPG to WEBP and PNG to WEBP converters handle this in the browser.

Step 3: Compress sensibly

Now compress — and resist the urge to crank quality to maximum. For web photographs, somewhere around 75–85% quality is the sweet spot: the file gets substantially smaller and the difference is invisible at normal viewing size.

A practical target for a content image is under 200KB. Hero images can be a little larger, but if you're over about 500KB for a single image, something upstream is wrong — go back to step one.

Our compress for website tool targets roughly 200KB automatically.

Step 4: Always set width and height

This one costs nothing and directly fixes CLS. When you write:

the browser can reserve exactly the right space before the image arrives, so nothing below it jumps down when it loads. Without those attributes, the page reflows mid-load — which is both a measurable Core Web Vitals penalty and genuinely annoying for readers who are trying to read.

Step 5: Lazy-load — but not your hero image

Adding loading="lazy" tells the browser not to download an image until the reader scrolls near it. For a long page with a dozen images, that's a large saving on initial load.

The mistake to avoid: lazy-loading the image at the top of the page. That image is almost certainly your LCP element, and deferring it makes your headline metric worse. For that one image, do the opposite:

Lazy-load everything below the fold; prioritise the one thing above it.

Step 6: Serve different sizes to different screens

A phone doesn't need the same image as a desktop monitor. Responsive images let the browser choose:

This is more work than the earlier steps, so it's worth doing once the basics are in place — but on a mobile-heavy audience the saving is real. Most modern site builders and frameworks generate this markup for you.

Step 7: Cache and deliver

Finally, make sure images are cached aggressively — they rarely change, so long cache lifetimes are safe. If you have an international audience, a CDN puts the files physically closer to your readers, which cuts latency more than any amount of extra compression.

How to check your work

Run your page through PageSpeed Insights. Look past the overall score — it's a rough composite — and read two things:

The LCP element it identifies, and how long it took. If it's an image, that image is your priority.
The "Properly size images" and "Serve images in next-gen formats" opportunities, which tell you the estimated saving in kilobytes.

Field data (from real visitors) is more meaningful than lab data (a single simulated load), so if the report shows both, trust the field numbers.

The short checklist

Resize to the actual display size × 2
Convert photos to WEBP, keep PNG for graphics, use SVG for icons
Compress to roughly 75–85% quality, aim under 200KB per content image
Set width and height on every image tag
Lazy-load below the fold; use fetchpriority="high" on the hero
Add srcset for responsive delivery
Cache long, and use a CDN if your audience is spread out

Steps 1 to 3 usually deliver 80% of the improvement in about ten minutes of work. Start there.

← Back to all articles