Lighter webp is a lot slower than png

[LasterAlex]

I've tried to use webp format to make loading big images faster, but it seems that webp is a lot slower than the same file in png when accessed from the _ipx path (or if accessed with NuxtImg):

http://localhost:3000/_ipx/_/fractal.png produces a ~60ms wait:

http://localhost:3000/_ipx/_/fractal.webp produces a ~400ms wait:

format="webp" also doesn't do better... http://localhost:3000/_ipx/f_webp/fractal.png produces a ~400ms wait:

It is even cached, and most of the time it's just connecting.

If i request a raw file from http://localhost:3000/fractal.webp it gives the cached file in no time:

Dev or production mode, nightly or stable, firefox or chrome doesn't matter, it's still a lot slower.

Repo to reproduce (it's really just a few files in the public directory): https://github.com/LasterAlex/nuxt_bad_webp

Am i doing something stupid? Is this expected? A lot of sources encourage the use of webp for optimization, so it's kind of confusing to see that the nuxt-image path is both slower than the raw public file AND slower than the less compressed file format.

Thank you for your time in advance.

[alexbidenko]

@LasterAlex Locally, there is almost no delay in data transfer, but image optimization introduces its own latency. That's why you're seeing these results.

It’s more important to check the outcome under simulated network throttling (using the network tab in DevTools) or to test it on a real server.

However, keep in mind that on the server side there will also be time costs for processing and optimizing images, although they will most likely be less than transferring a large original image. If you want to achieve ideal performance on the server side as well, it can be a good idea to add browser caching headers (such as Cache-Control) and to configure web-server caching, for example using proxy_cache if you’re running Nginx.

[LasterAlex]

Thanks for the response!

It’s more important to check the outcome under simulated network throttling (using the network tab in DevTools) or to test it on a real server.

I already did, that's why i saw it in the first place.
I spun up a test server to show to others, and for some reason every time i opened a tab in incognito mode with no cache, it would take an awful amount of time to load.
I just tested my example repo with a real server, and it's even worse. /_ipx/_/fractal.webp takes around 1 second now, with browser cache, while /fractal.webp takes just 50ms.
And the initial images are already from the Network tab in firefox DevTools.
I understand that image optimization introduces some latency, but if the latency is actually longer than the time to get the image with a regular endpoint, there is something wrong, and i don't yet know what.

If you want to achieve ideal performance on the server side as well, it can be a good idea to add browser caching headers (such as Cache-Control) and to configure web-server caching, for example using proxy_cache if you’re running Nginx.

So... The method to fix slow _ipx routes is to... Not serve them, instead using nginx cache?
This sounds wrong, and makes me question even more, why NuxtImg doesn't do that itself, instead just idling for a second?

I run my server by just pnpm run build && pnpm run preview --host, this looks pretty simple, but is there something wrong?

All the settings in the repo are default, created by npx nuxi@latest init my-app, and i can't see what could be wrong with it. Did i forget to set something?

[alexbidenko]

@LasterAlex I’d like to clarify that I’m not a nuxt/image developer; I’m just sharing the solutions I used for the same issue, until the official developers respond😁

From my perspective, using caching to reduce server load is a perfectly valid approach. If that’s not convenient for you, or if you find the image optimization speed unsatisfactory, there are build-time solutions like vite-imagetools. Also, nuxt/image can pre-generate images.

Regarding optimization speed: I agree with you that there can be performance problems. Personally, I’ve noticed more issues when creating avif images, while webp was generated at a decent speed in my case. There could be environmental differences at play.

By default, nuxt/image uses the ipx provider (https://github.com/unjs/ipx) under the hood, which, if I’m not mistaken, relies on the sharp library (https://github.com/lovell/sharp). If you’re certain the issue lies in the optimization process itself, it might make sense to open an issue in the relevant repositories.

But once again — I’m not a nuxt/image developer; I’m just trying to help because I’ve run into similar challenges myself😊

[xixixi163]

I have also encountered a similar problem. Do you have a solution? Can it only be used in conjunction with CDN?

[LasterAlex]

I just stopped using nuxt/image, the problem was a lot deeper than this library, its some image processing library that nuxt/image uses iirc

[Theiaz]

I've observed the same problem but with .avif and .webp. The latter has a lot more response time than .avif. Using <img> instead of solved the issue. So its definitley a bug.