I already have optimized JPGs — is moving to WEBP still worth it?

It usually delivers an additional gain, but the difference you get moving from a well-optimized JPG to WEBP is smaller than the difference you get moving from a JPG that was never optimized. That is because you have already collected part of the gain through optimization. Since how much extra you get depends on the image's content, the most accurate method is to try it on a few representative files and measure the result.

Is resizing images or changing format more effective?

On most sites, resizing is far more effective and it is usually the step that gets skipped. If you are serving an image at 4000 pixels wide that is displayed at 600 pixels on screen, you are sending unnecessary data no matter what you do with the format. First bring images down to the size they will actually be used at, then worry about format and quality settings. Reversing that order pays off far less.

Does it make sense to serve both a WEBP and a JPG version?

It makes sense if you want to guarantee backward compatibility, and it is easy to do with HTML's picture element; the browser picks the format it supports on its own. The cost is producing and storing two versions of every image. Because all modern browsers support WEBP, many sites now prefer to serve a single format; the decision depends on the variety of browsers your audience uses.

Is lowering the quality setting simpler than moving to WEBP?

It is definitely simpler and it is often surprisingly effective. On many sites, images have been saved at an unnecessarily high quality setting, and pulling that setting down to a reasonable level delivers a serious size gain with no visible degradation. A format change, by contrast, adds a new step to your workflow. The most effective path is usually to do both together: the right dimensions, a reasonable quality setting, and an efficient format.

For Page Speed: WEBP or a Well-Optimized JPG?

A badly framed dilemma

"My site is slow, let me convert the images to WEBP" is a sentence you hear very often. But page speed problems rarely stem from format choice alone, and moving to WEBP is not always the step that delivers the biggest gain.

In this article we compare two approaches: properly optimizing your existing JPGs, and moving the format to WEBP. We cover what each one delivers, where each one hits its limit, and in what order they should be done.

The three factors that determine image weight

Three things determine how many bytes an image occupies, and format is only one of them.

Pixel dimensions. The image's width and height. Halving an image's dimensions reduces the pixel count to a quarter. This is the most powerful lever on file size.

Quality setting. How much information gets discarded in lossy compression. An unnecessarily high setting spends a great many bytes on detail nobody can see.

Format efficiency. How many bytes it takes to represent the same picture. This is where WEBP's superiority over JPG lies.

On most sites, the biggest waste is in the first two factors. Serving images at enormous resolutions when they are displayed small on screen, and blindly cranking the quality setting to maximum, are both extremely common. With those two problems in place, changing the format is like trying to fill a leaking bucket faster.

How good can an optimized JPG be?

A well-optimized JPG should not be underestimated. A JPG that has been resized correctly, saved at a reasonable quality setting and stripped of unnecessary metadata is far smaller than its unoptimized version.

JPG's advantage at this point is frictionlessness: every tool produces it, every browser opens it, it fits into every workflow, and it raises no compatibility questions. It is an improvement you can apply without changing anything in your existing system.

Its limit, though, is the format itself. JPG's fixed block structure and its inability to predict from neighboring blocks cap efficiency past a certain point. There is a ceiling on how far optimization alone can take you.

What does WEBP add?

WEBP raises that ceiling, which is a consequence of JPG's design. Because it can predict from neighboring blocks, vary block size according to content and use a more efficient final coding stage, it uses fewer bytes at the same visual quality.

On top of that it adds two more capabilities: transparency support and a lossless mode. That means you can use a single format for both your transparent logos and your photographs.

The cost is the step added to your workflow. A conversion stage enters your process for producing, storing and publishing images. If that step is not automated, it gets neglected over time and the system becomes inconsistent.

In what order should you do this?

The most effective order in practice is the following, and it is very often attempted in reverse:

Dimensions first. Bring images down to the size they will actually be used at on the page. Preparing double resolution for high-density displays is reasonable, but five times is unnecessary. On most sites, this step alone delivers the biggest gain.

Quality setting next. Save a few representative images at different settings and compare them at actual size. Adopt the most aggressive setting where you cannot see a difference. This is usually a more aggressive point than people assume.

Format after that. Once you have done the two steps above, moving to WEBP collects the remaining share. You can use the JPG to WEBP converter to convert your archive.

Delivery last. Techniques like loading images only when they become visible and serving the right dimensions for different screens improve perceived speed independently of format.

A decision table

If your images have never been optimized: Deal with dimensions and quality settings first. You will get a large gain even without a format change.

If your images are optimized but the page is still heavy: Moving to WEBP delivers a meaningful additional gain. At this point the format difference genuinely becomes noticeable.

If your transparent images are sitting as PNGs: Moving those to lossless WEBP usually delivers a good gain and preserves transparency.

If your workflow is manual and disorganized: Sort out the process before the format change. A conversion step that has not been automated will not be applied in the long run.

If you have very few images and the page is already fast: Do none of it. Optimizing when there is no measurable problem means trying to solve a problem that has not presented itself.

In summary

This is not an either-or choice; it is a question of sequence. Bringing images down to the right dimensions and pulling the quality setting to a reasonable level delivers the biggest gain on most sites and requires no format change. WEBP then collects the remaining share once that groundwork is done, and adds transparency flexibility on top. The best result comes from applying both, in order and together.