Image Optimization for a Website: A Speed Guide (WebP, Lazy Load)

Image optimization for a website comes down to four moves.

Pick a lightweight format such as WebP or AVIF, compress and resize your files, serve the right size per screen, and let everything below the fold lazy load.

The verdict: images are usually the heaviest thing a browser downloads, so they’re the fastest speed win. Just never lazy load the image at the top.

Below we walk through the four layers in order of impact, plus the pitfalls that can ruin your load time.

Want the bigger picture first? Read our guide to having a B2B website built.

Speed here, findability elsewhere

This piece is about speed and technique. For file names, alt text and an image sitemap, read our article on image SEO.

Why do images weigh so heavily on your load time?

Because they’re literally the heaviest files a browser pulls in.

On most pages, images make up the largest share of total page weight.

Every megabyte turns into waiting time for your visitor.

The image Google measures

A slow hero image at the top is often the element Google measures as Largest Contentful Paint.

That’s one of the Core Web Vitals that score your loading experience.

Here’s what that looks like in PageSpeed Insights for our own site:

PageSpeed Insights field data for customerimpact.be on mobile, October 2026. LCP passes at 1.9 s; CLS at 0.13 still needs work.

LCP passes there. The layout shift score is the one images can still push into the red, as you’ll see further down.

Our guide to largest contentful paint explains how to read the full breakdown.

Why it matters for B2B

The stakes are subtler than for a webshop, but just as real.

No shopping cart walks away. But a slow or sloppy first impression subconsciously says “amateurish”.

A prospect who drops off before your page has loaded fills in no contact form.

Our piece on page speed, SEO and conversion shows that link.

Rule of thumb: steer on the visitor, not on the number. A light page is the difference between someone who stays and someone who clicks away.

Here are the four layers, from the biggest to the smallest gain:

Which image format should you choose: WebP, AVIF, JPEG or PNG?

The lightest one without visible quality loss. For most website images, that’s WebP today, with AVIF as an even lighter option.

The five formats compared

Each format has its own job:

How much lighter is WebP?

Google’s web.dev puts it at “usually on the magnitude of a 25 to 35% reduction in filesize” compared with JPEG and PNG.

Every screenshot in this article is a WebP file, for exactly that reason.

Is AVIF safe to use?

Yes, with a fallback. Browser support is broad by now: Can I use lists 96.35% global support for AVIF, checked 4 November 2026.

That leaves a small share of browsers that need WebP or JPEG instead.

Serve the lightest format first

In practice you serve AVIF first, with WebP and then JPEG as fallbacks.

A picture element does that: each browser picks the lightest format it can handle.

Everyone benefits, and older browsers aren’t left out.

How do you compress and resize images without losing quality?

Resize to the displayed size, then compress. You need both, and this is the step most people skip.

Resizing

Don’t upload a photo 5,000 pixels wide if your site shows it at 800 pixels.

Your visitor downloads those extra pixels for nothing.

For most website images, a maximum of around 2,500 pixels is plenty. Thumbnails and backgrounds can be much smaller.

Compressing

Lossy compression (as with JPEG and standard WebP) throws away data the eye doesn’t see anyway.

It makes your file considerably lighter.

Lossless keeps all the data. Use it only where every detail counts.

For a blog image, no visitor notices the difference between an untouched photo and a well-compressed version.

How light is light enough?

Go as light as possible per image, often well under half a megabyte.

With hero images, check whether they really need to be that heavy.

Free tools such as image compressors do the heavy lifting in a few clicks.

Modern platforms and headless setups can often do it automatically on upload.

Check what your site does now

Run your site through Google Lighthouse. It tells you page by page which images are too heavy.

Watch out: on WordPress, plugins often add their own images and scripts. Our guide on how to speed up a WordPress site covers that case.

What are responsive images and why do you need them?

Responsive images deliver the right size to every screen instead of one large file everywhere.

A phone gets a small version, a wide desktop screen a large one.

That matters, because much B2B traffic comes in on mobile, where a desktop-sized file is pure waste.

How srcset and sizes work

You set this up with the srcset and sizes attributes on your images.

They list several sizes and tell the browser how big the image appears on screen.

The browser then picks the best version for the device and screen resolution itself.

Good CMSes and frameworks generate these variants automatically, so you don’t export five sizes by hand.

Fixed dimensions stop layout shift

A second gain is stability. Give every image a fixed width and height (or an aspect ratio) in your code.

Google’s web.dev recommends “adding width and height attributes to all img tags”.

The browser then reserves the space and your layout no longer jumps while images load.

That prevents a poor score on Cumulative Layout Shift, the Core Web Vital that penalises shifting content.

Our own Search Console shows how much that one metric weighs:

Our own Search Console, Core Web Vitals on mobile, October 2026. Layout shift, not load speed, keeps 349 mobile URLs out of the green.

Speed alone doesn’t get you green. Stable layouts do the rest.

How does lazy loading work and what is the pitfall?

Lazy loading only loads an image when the visitor nearly reaches it, instead of everything at once.

Images at the bottom of a long services page don’t have to come along right away.

That shortens the initial load time considerably. In modern browsers you switch it on with the loading="lazy" attribute on your image.

Never lazy load your hero

The big pitfall: never lazy load your hero or the most important image at the top.

Google’s web.dev is explicit: “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.”

That image is usually exactly the element Google measures. Delaying it slows down the very score you’re trying to improve.

Give the hero priority instead

The reverse move does help. Give your hero image a high loading priority with the fetchpriority="high" attribute, and it loads in faster.

In a Google Flights test, that one attribute moved LCP from 2.6 s to 1.9 s.

Not every LCP element is an image, though.

On our own article below, the H1 heading is the LCP element:

PageSpeed Insights for our own largest contentful paint article, October 2026. The H1 in the first screen is the LCP element.

So check which element is your LCP before you add priority to an image.

Rule of thumb: priority for the one image at the top, lazy loading for everything below it.

CDN and caching

A CDN (a network of servers that delivers images closer to your visitor) speeds things up further.

So does browser caching, where a returning visitor doesn’t download the images again.

Both belong more to your hosting and architecture than to the images themselves.

But they count towards the overall picture.

In what order do you tackle this?

Not everything at once. This checklist runs from most to least impact:

1. Resize your source files to a sensible maximum width.
2. Compress every image and convert to WebP, with AVIF where your tooling can handle it.
3. Set up responsive images with srcset and sizes, so mobile gets a lighter version.
4. Specify width and height to prevent shifting layout.
5. Switch on lazy loading for everything below the fold, but never for your hero.
6. Give your hero high priority with fetchpriority="high".
7. Check on mobile and in Lighthouse, because that’s where the experience weighs heaviest.

For example, say your services page has a 3 MB hero photo and twelve case logos below it.

Steps 1, 2 and 6 fix the hero; step 5 handles the logos.

Frequently asked questions about image optimization

Is AVIF better than WebP?

AVIF usually compresses harder at comparable quality. WebP is the safer default.

Serve AVIF first with WebP and JPEG as fallbacks, and you get both.

Should I lazy load every image?

No. Lazy load everything below the fold, but never the hero or main image at the top.

That image usually is your LCP element, so give it fetchpriority="high" instead.

What size should website images be?

The size they’re displayed at, not the size your camera made.

Around 2,500 pixels wide is plenty for most website images.

Thumbnails and backgrounds can be much smaller, and most files should stay well under half a megabyte.

Does image optimization help SEO?

Indirectly. Lighter images improve load time and Core Web Vitals, which shape the page experience.

For findability itself (file names, alt text, sitemaps), see our image SEO guide.

The short summary

Optimising images isn’t rocket science. But it’s the detail work that wins you the most load time.

Work in layers: light format, smart compression, responsive images and lazy loading.

Your hero is always the exception that gets priority.

Do that well and your site loads fast, your layout stays stable, and prospects stay long enough to get in touch.

How we build it

At Customer Impact we’re a small, senior team that advises honestly and steers on what counts: leads and revenue, not vanity technical numbers.

We build platform-agnostically (Webflow, WordPress or headless) and choose the approach that fits your case.

Want a site that loads fast and converts? See how we handle website development.

Contact us