When we take over an existing client site, one thing is nearly always the same. The images are far too big. When we talk about optimising images with WebP and AVIF, we are not talking about some nerdy detail. We are talking about the difference between a homepage that appears on a phone in one second and one that takes three seconds to load while the visitor has already moved on. Phone snaps taken by the owner, uploaded straight from the camera, 4,000 pixels wide, four megabytes each. That drags everything down.
Why are large images such a problem for load time?
A four-megabyte image has to download in full over the mobile connection before the visitor can see it. On a typical small-business homepage you quickly end up with five or six images like that. Add them up and the phone has to grind through nine or ten megabytes. On Wi-Fi you barely notice. On the edge of Maisach with two bars of signal, it turns into a test of patience.
Here is the galling part. The images do not look any better on a phone just because they are 4,000 pixels wide. The screen might show 400 pixels. The rest is dead weight that loads but is never seen. This is exactly where we step in, and the effect is bigger every time than clients expect.
What is the difference between JPEG, WebP and AVIF?
Everyone knows JPEG. The format is more than 30 years old. It works, but it does not pack images very economically. WebP is the more modern successor from Google and, at the same picture quality, often produces files 25 to 35 percent smaller. AVIF goes a step further and shrinks the data again noticeably. With subtle colour gradients and photos, its lead is greatest.
The clever bit. Nobody sees the difference. We compare the images side by side on a large monitor, and even at 80 percent less file size you cannot spot anything with the naked eye. That is not a marketing promise, it is something you can check for yourself. A photo of the shop counter stays sharp, the colours are right, only the file is a fraction of the size.
And if a browser cannot handle AVIF?
That is why we never serve just a single format. We build the images with the HTML picture element and several sources. The browser picks the best format it understands on its own. New phones get AVIF, older devices get WebP, and very old browsers fall back to JPEG. Nobody sees a broken image, everyone gets the smallest one they can display.
What is srcset all about?
The second tool is called srcset. With it we store several sizes of every image. A small version for the phone, a medium one for the tablet, a large one for the desktop monitor. The browser works out which size it currently needs and loads only that one. So the phone pulls the 400-pixel variant, not the huge desktop file.
Combine the two, modern format plus the right size, and the effect is enormous. A bakery site from the district that we took over last year really brought this home to me again. The homepage weighed nine megabytes before. Almost all of that was four un-shrunk photos of loaves and the shopfront. After the switch. Under one megabyte.
Load time on the phone roughly halved. The baker did not measure it, he noticed it, because his site suddenly felt like a real site and not a slideshow in slow motion. Moments like that are the reason we do this on every project.
Why does Google care about image size?
Google has been measuring how fast pages load for years and rolls it into what are called the Core Web Vitals. Large, slow-loading images drag exactly those numbers down. Especially the LCP value, which measures when the largest element becomes visible, and on most homepages the largest element is one thing. A photo. There is more on this in our post on slow websites and Core Web Vitals mistakes.
So two things happen at once when we shrink images. Google rates the page better, which helps with ranking. And the real visitor stays longer, because they do not have to stare at a loading page. The second point especially counts. Studies from Google (older figures, to be read with caution) have long suggested that every extra second of load time costs you drop-offs. Exactly how much depends on industry and device, but the direction is clear.
How does the switch actually work with us?
We take the existing images and run them through our build pipeline. That is a script that automatically converts every photo to WebP and AVIF, spits it out in several sizes and writes the matching picture and srcset markup into the code. Doing this by hand would be madness. Automated, it takes minutes.
- Format: AVIF and WebP as the main formats, JPEG only as a fallback
- Sizes: several variants per image, served via srcset
- Loading behaviour: images outside the visible area only load as you scroll (lazy loading)
- Dimensions: fixed width and height values so nothing jumps while loading
The last point is often forgotten. If an image loads without size information, the layout judders the moment it pops in. That is annoying, and Google penalises it. We set the dimensions in stone so the space is reserved from the start. For us, these steps are part of every web design project, not as an extra charge but as a matter of course.
By the way, image size is only half the battle. Just as important is that the photos are any good in the first place. Blurry, dark phone shots put customers off no matter how fast they load, something we covered in more detail in our post on bad website photos.
Frequently asked questions
Do I lose image quality if I switch to WebP or AVIF?
Not visibly, in practice. We set the compression so the eye sees no difference while the file still shrinks by 60 to 80 percent. For tricky subjects we check every image by hand afterwards.
Does it work on all phones and browsers?
Yes. Practically every browser understands WebP today, and most current ones handle AVIF. For the rest we automatically serve a JPEG as a fallback. No visitor ever sees a blank image.
Can I convert my images myself?
For individual images there are free online converters. But it only really pays off with the right sizes and the correct code around them. Swap the format alone and you leave half the benefit on the table.
If you suspect your site is being held back by images that are too heavy, we are happy to take a look. We offer a free website check, a 30-minute look at load time, images and the worst bottlenecks. No sales pressure, just so you know where you stand. Get in touch at bytebrise.com/kontakt. We are based in Fuerstenfeldbruck and know the area west of Munich.