Implemented Image compression rate?

[BikeGremlin]

It is nice that XF 2.3 has converts images to webp (apart from Avif which is still not widely supported, webp is probably the best option if you don't know in advance what types of images users will be uploading).

However, the compression rate is pretty low. I.e. you get some pretty big files after uploading.

I uploaded an image from my smartphone and it was cut to 600x800 (as configured by the max image setup in XenForo).
But the file size was almost 300 K.

When I saved that image from my forum (downloaded it) and gave it a go using squoosh.app, setting the export webp quality to 75 (out of 100) reduced the file size by 50% (to around 150 K), without destroying the quality.

It would be highly practical to have some better compression option built into XenForo - now that it has the webp conversion built in already.

Unless that already exists but I've missed it.

Relja

 

[Jeremy P]

Image quality is more nuanced than that. Recompressing existing images can cause them to deteriorate over time (as is already unfortunately common with JPEGs). Compressing an image at 80% twice leaves you at 64% quality, for example.

They should already be fairly reasonably sized by design, whether from XF conversion or external sources. It may not be the platonic ideal of image compression but it’s pretty pragmatic for the vast majority of cases when you consider implementation complexity vs. real-world performance gains.

 

[BikeGremlin]

Image quality is more nuanced than that. Recompressing existing WebPs would cause them to deteriorate over time (as is already unfortunately common with JPEGs). Compressing an image at 80% twice leaves you at 64% quality, for example.

They should already be fairly reasonably sized by design, even at the out of the box rate or from external sources. It may not be the platonic ideal of image compression but it’s pretty pragmatic for the vast majority of cases when you consider implementation complexity vs. real-world performance gains.

I understand you point, but still, an example (which I find confusing):

A 700x700 photo was resized to a 200+ KB webp.

Putting that same image in squoosh.app interface gives a 50% size reduction at 85% quality (minor quality change) and 35% reduction at 85 quality if using webp (counter-intuitive for most, but webp isn't always the optimal choice, it's often png or jpg, depending on the image type, but that's a separte topic that I would not expect an automated tool to tackle).

With png, setting the max quality to lower results in larger file past a certain point, apparently.

Strange implementation. I find it confusing and not working too well.

Edit:
Just tried it - same compression results in this very forum, so it's probably not down to my particular setup.

 

[Jeremy P]

Sure, I don't mean to imply it's always going to yield an optimal result for every possible image (it can even increase the size in some cases). Just that it's a simple mechanism to yield more optimal results for most images, and that's good enough for us. Further improvements (beyond maybe AVIF in the future) are unlikely to be worthwhile for the performance gain in aggregate.

Also note that the libwebp options exposed via GD/Imagick are limited. We can feed it a source image and a quality and ask for them to convert it, but there's not many knobs and levers available to us beyond that.

 

[BikeGremlin]

Sure, I don't mean to imply it's always going to yield an optimal result for every possible image (it can even increase the size in some cases). Just that it's a simple mechanism to yield more optimal results for most images, and that's good enough for us. Further improvements (beyond maybe AVIF in the future) are unlikely to be worthwhile for the performance gain in aggregate.

Also note that the libwebp options exposed via GD/Imagick are limited. We can feed it a source image and a quality and ask for them to convert it, but there's not many knobs and levers available to us beyond that.

Fair enough.

Apologies if my previous comment came off as ranty - based on what you explained, it sounds like there aren't any straightforward options for improving compression without manual tweaking. Which isn't really practical for a forum where different users upload all sorts of images.

Thinking aloud:
Would it be possible (and at least reasonably simple) to add a manual compression tool for forum admins? Something with options to choose compression level and image format?

Relja

 

[Jeremy P]

It should be possible for add-ons to integrate different optimization techniques/APIs. There were some which did this for earlier XF versions. It's mostly just reading the image in, optimizing it, writing the optimized image out, and updating some rows in the database. I think reverse-proxy techniques like Cloudflare Polish should also work fine.

 

[BikeGremlin]

It should be possible for add-ons to integrate different optimization techniques/APIs. There were some which did this for earlier XF versions. It's mostly just reading the image in, optimizing it, writing the optimized image out, and updating some rows in the database. I think reverse-proxy techniques like Cloudflare Polish should also work fine.

Regarding that last item: Cloudflare Polish just works at the CDN level - it doesn't compress or replace the files stored on the server. My concern was specifically about disk space usage on the origin, not just delivery optimization. So image optimization tools that overwrite the actual attachments (via add-on or CLI) are still needed in that context.

 

[Jeremy P]

Yes, that should still be possible.

This is only my personal experience and I understand exact needs vary between people/sites, but the built-in WebP optimization about halved our attachment file sizes on the whole, and R2 storage is pretty cheap with a generous free tier.

 

[BikeGremlin]

Yes, that should still be possible.

This is only my personal experience and I understand exact needs vary between people/sites, but the built-in WebP optimization about halved our attachment file sizes on the whole, and R2 storage is pretty cheap with a generous free tier.

Thanks, that makes sense - and agreed, WebP optimization combined with something like R2 offloading can be a practical solution in many cases. In some cases it can be an extra hurdle and bring more complication (my stuff for example is non-profit so any extra money or time/effort is not easy to justify).

Just to clarify:
Cloudflare Polish optimizes images at the CDN level (on-the-fly and cached), so it helps with bandwidth and delivery speed, but it doesn't reduce the size of the original files stored on the server.

For forums where disk space usage on the origin matters (e.g., limited hosting), some kind of local or server-side optimization - whether built-in or via add-on - is still worth considering, and if I understood correctly, you've had great results with the current XenForo built in optimization?

To avoid misunderstanding:

• XenForo is the best (or the least bad for us pessimists LOL ) forum software - well-built and helps a lot.
• The built in optimization is a lot better than nothing (or the state before it was introduced).
• It's just often not ideal - that's fair to note.

(I am using imagick and the "Imagemagick PECL extension" for XenForo image compresson)

Relja

 

[Jeremy P]

For forums where disk space usage on the origin matters (e.g., limited hosting), some kind of local or server-side optimization - whether built-in or via add-on - is still worth considering, and if I understood correctly, you've had great results with the current XenForo built in optimization?

Yes, though it's anecdotal of course. The built-in optimization resulted in roughly ~50% file size reduction in aggregate. This was using GD, I haven't tested if the results are comparable when using Imagick but I wouldn't expect them to be far off.

In some cases it can be an extra hurdle and bring more complication (my stuff for example is non-profit so any extra money or time/effort is not easy to justify).

Sure, I understand the desire to keep things simple. While we don't offer any tools to migrate existing attachments, the S3 API that Cloudflare R2 offers is supported out of the box in XF 2.3+, and there's a pretty cool add-on which simplifies things further. The R2 free tier offers 10GB and the pricing beyond that is pretty cheap (<$20/TB depending on usage patterns).