I Planned to Resize Every Image. Seven WebP Conversions Saved 91.5%

The blog on one of my sites was loading slowly, and the cause looked obvious: the image folder was about 19.2 MiB.

My first idea was equally obvious. Resize most of the images by up to 50 percent.

That would have worked, in the broad sense that smaller pictures usually mean smaller downloads. It also would have changed far more than necessary.

Once I measured the files properly, the problem turned out to be seven PNGs. Converting those seven to WebP reduced them from roughly 14.5 MiB to 1.23 MiB. That is about a 91.5 percent saving, without changing their dimensions.

Start with an inventory

The folder contained 18 PNG files. Nine belonged to a detailed how-to guide and needed to remain untouched because their size and clarity were already appropriate for the instructions.

That left nine candidates.

Two of those were 1200 by 630 pixels, which sounds large until you look at the actual file size. They were only about 38 KiB each. Resizing them would have saved almost nothing and might even have produced larger replacements with the wrong settings.

The other seven accounted for nearly all the weight.

This changed the task from "process an entire image directory" to "fix seven specific files."

That is a much safer job.

Dimensions and file size are different problems

Image optimisation conversations often start with dimensions:

• Should this be 1200 pixels wide?
• Can we cut it to 800?
• What happens on a phone?

Those are useful questions, but dimensions are only part of the answer. Format and encoding can matter more.

A large PNG is excellent when you need lossless detail, transparency, or crisp interface pixels. It can be wasteful for artwork or photographic content. WebP usually stores that kind of image far more efficiently.

In this case, keeping the original dimensions preserved the layout and sharpness. Changing the encoding did the heavy lifting.

The seven files went from about 14.5 MiB to 1.23 MiB at WebP quality 82.

If I had simply halved the dimensions, I would have thrown away pixels before finding out whether that was necessary.

Change the smallest possible surface

The site stored article metadata in a JSON file. Each article entry pointed to its image:

{
  "slug": "example-post",
  "image": "images/example-post.png"
}

The conversion required three controlled changes:

1. Create seven WebP files.
2. Update seven image paths from .png to .webp.
3. Remove the seven superseded PNGs after verification.

The nine protected guide images stayed exactly as they were. The two tiny PNGs stayed too.

This matters because bulk optimisation tools are very good at doing exactly what they are told to every file. If the instruction is too broad, the mistake is broad as well.

Verify references, not just files

Creating smaller images is not the finish line. A website can have perfectly optimised files and still show broken thumbnails because one path is wrong.

After the conversion I checked:

• every image path in the JSON index existed
• every protected guide image was unchanged
• the site built successfully
• generated pages referenced the new WebP filenames
• the deployed blog page loaded
• a WebP asset returned successfully with the correct image content type

That last check is easy to skip. A local build proves the source is internally consistent. It does not prove the published server is delivering the new asset.

What I would do next

The image folder fell from about 19.2 MiB to 5.9 MiB, so the urgent problem was solved.

There were still possible improvements:

• native lazy loading for images below the fold
• responsive srcset variants for smaller screens
• separate thumbnail sizes for article lists
• automated checks for unusually large new uploads

Those changes affect markup or the publishing process, so I left them for another pass. Once the major waste was removed, they were no longer emergency work.

The lesson

The useful question was not "How do I make all these images smaller?"

It was:

Which files are responsible for most of the cost, and what is the least destructive way to fix them?

Measure first. Protect the exceptions. Change only the expensive files. Then verify the paths and the deployed result.

Seven conversions solved the problem better than resizing everything.