Is JPEG XL too slow for the web?

Since browsers now seem to start adding support for JPEG XL again, I am in the process of implementing JPEG XL support for the next update of my website builder.

And once it worked, I was baffled: Opening websites with JPEG XL images took very long. So long, I needed to add code to show a "busy" indicator.
Was I doing something wrong?
I looked into it, and it turned out no: JPEG XL is kind of slow when decoding my images. On my a-bit-over-average machine, it feels like it takes about 1-2 seconds per large image to load it. So I looked into it:

Tested Loading the same file (4608x2080) with JXL, JPG, PNG and WebP.



Using C++ - x64 - /O2 optimization on a i5 2.5ghz, version 0.12 of libjxl.



By reducing the quality of the .jxl file a bit, I was able to load the image faster (413ms instead of 515ms, for a quality value of 90 instead of 94). But it's still too slow.

The problem is not only that JPEG XL is very slow, it's that it takes more time than you as human are ok with waiting. For me, it's just a bit above the limit you are used to wait for an image to load. It simply feels wrong.

Also, JPEG XL is the single largest image decoding/encoding library which I ever added to my app. And it has so many dependencies.
I've stripped it down to the minimum and reduced it a lot, and in total, it still adds 508 source code files to the project. That's 15(!) times more than for example libPNG needs. I will have much fun maintaining this in the future.

JPEG XL might be technically a nice accomplishment, but I personally think for the insignificant amount of file size and quality improvements - JPEG XL is not worth it for the web. It feels like a overengineered piece of unnecessary software - at least for that use case. But maybe I'm wrong.