Big images are not compressed

[PhirosWolf]

In the first place, thank you SO MUCH for this library.

But now I have an issue: I'm using large image files that are larger than the "recommended size limit (244KiB)", and this is why I was looking for server-side compression in the first place.

But it seems that "big" files (in my case they are in the assets folder) are not compressed (but small files (smaller than 244KiB) are).
Do you have any clue about why this happens and how to fix it?

Thank you in advance for your answer.

[maddocnc]

I think it’s not about size, but about minRatio https://github.com/webpack-contrib/compression-webpack-plugin#minratio

Image gzip and brotli work good for text-like files. Images even unoptimized jpeg won’t give you compression because it is already compressed with jpeg compared to bmp. You can try to put your images into zip on your computer to see it.

Compressing images with brotli/gzip useless compared to image optimization algorithms and modern formats(webp and others), because they changes image itself removing information your eye can’t see.

[PhirosWolf]

I've set minRatio to 1.0 (meaning "compress everything unless compression would make the file larger") to see if it would compress the large files but it doesn't.

I know I can compress the images themselves and I already did it. Unfortunately very large images can sometimes not be compressed under the "recommended size limit". So that's why I'm searching for compressing them with gzip/brotli at least to improve bandwidth usage.

Or maybe compressed images cannot be compressed using gzip/brotli because they are already compressed by another algorithm? I don't know.

[maddocnc]

Basic compression is like using dictionary, if algo sees that file contains many "FOO" and "BAR", it puts into dictionary:
1=FOO
2=BAR
and replaces all occurrences to 1 and 2 etc. This works with many files. But image files has another level of entropy. Uncompressed image like bmp/tiff could be compressed with this algo, but some clever guys decided that they can do more, and they invented jpg and gif - which instead of using dictionary changes the way image stores, jpeg for example replaces pixels with gradient zones. Then other guys invented even more clever algorithms for streaming video, and then they was ported into webp and avif(extremely slow but may beat svg on save image!!). Those algos are so clever that using after them classic gzip is just useless.

So first of all recommended size is just recommendation, you can even increase what you think is recommended.
If your images really big and loads slow, then best option for now is to compress them with webp and avif. And serve them based on Accept header, or in picture tag. I'm going to add this option in module, but was waiting for Nuxt 3, because it may need total rewrite then

[PhirosWolf]

I understand the fact that using a compression algorithm directly on images is far better than using gzip and brotli. But I want to understand why small images below the recommended file size of Nuxt.js are compressed using gzip and brotli, but large images aren't.

And how do you know they will ever release a third version of Nuxt 3? Did they announce it somewhere? Maybe they will only continue making small corrections here and there (which means staying on 2.x.x).

[maddocnc]

Could you please make repro-repo so I will investigate deeper.

About Nuxt 3, yes they announced and even provided some videos of working on VueJS Amsterdam (more info on their twitter), but for now still no time estimates.