XF 2.3 Image optimization, enhanced image resizing, and more!

Image optimization with WebP support​

Arguably, we could have talked about this in our bumper Boosting performance entry but it wasn't quite ready to be shown at that point. (I started working on it this week and I haven't yet mastered the art of time travel).

Initially the scope of our WebP support in XenForo 2.3 was to merely allow users to upload WebP files and have them correctly displayed inline. This would have been a positive change on its own as the format becomes more prevalent across the web, but it doesn't really do much on its own to solve the issue of disk usage which, of course, then also has a positive effect on performance.

But, this wasn't enough.

hys_4_option.png


If you wish to optimize, automatically, all future image uploads you simply need to enable this option.

On upload, all currently supported image types (except GIFs) will be saved to WebP format.
Side note: As is the case now, thumbnails, profile banners and avatars (and anything else that has a programmatically set file name) will be served with a .jpg extension, regardless of the underlying file format.

If you have custom content types which already use the attachment system, such as we do with Media Gallery and Resource Manager, images uploaded to those will be automatically optimized too.

In fact, if your add-on handles uploads via the default approach, namely the XF\Http\Upload class, all new image uploads will be optimized automatically. This extends out into pretty much every system we have, including the admin asset upload system.

As a developer, if you wish to opt-out of this behaviour for any reason, you can do so with the following one-liner:

PHP:
$upload->setImageOptimize(false);

That deals with future uploads, but, many of you will be wondering how to optimize existing files. So you'll be pleased to hear that you are able to rebuild all of your existing attachments, avatars and profile banners automatically.

hys_4_rebuilds.png


These are somewhat typical rebuilds that you can kick off from within your admin control panel on the "Rebuild caches" page.

With this being a rather intensive and lengthy process, if you'd prefer to run this without the risk of browser timeouts and supervision, you can also use one of the built in commands:

Code:
xf-rebuild:attachment-optimization
xf-rebuild:avatar-optimization
xf-rebuild:profile-banner-optimization

As a developer, adding support for your own content types is trivial by extending the AbstractImageOptimizationJob class.

We have run this already on a development copy of the XenForo Community forum. In doing so, the file size reported via the xf_attachment_data table before the conversion was around 40GB. The file size reported after the conversion is around 19GB.

These are significant savings and will also have a positive impact on performance.

The "not so good" news​

WebP is now supported by every single major browser. Anyone using an up to date browser will not experience any issues with viewing images. However, certain Apple devices and browsers prior to September 2020 do not support WebP.

Specifically, if you are using iOS 14 or above, there is no issue at all. Safari 14 and above is great, too but you must be running at least macOS 11 Big Sur for WebP images to display.

In earlier browsers, these users will simply not see WebP images at all. They will appear as broken images.

As time progresses, this is naturally an ever decreasing issue as people update their software and hardware. But it is something you should be aware of and think about before blanket converting all images to WebP.
 
Yeah, client-size image resizing will remove the EXIF data, so it's extracted on the client first and sent with the upload.
Does the entire extracted set of values get sent or only specific values?

(Hoping the answer is the full entire extracted values and not just a subset. 🤞)
 
Only a subset, as the full set bloats the JS from 18kb to 70kb and we only use 9 values in XFMG. We can consider unbundling the library to make it easier for add-ons to swap in a build with a bigger set if it's an important use case, but we're unlikely to ship more ourselves.
 
What would be the field name for the emoji column?

My "Content Rating" add-on adds emoji support for reactions, but it should be easy to migrate the value into the XF2.3 feature.

But more feature(s) I can get rid of from my own add-ons. I've already got a hack-job to support webp for attachments I can get rid of, and one for avatars can finally be slimmed down.
 
Last edited:
What would be the field name for the emoji column?

My "Content Rating" add-on adds emoji support for reactions, but it should be easy to migrate the value into the XF2.3 feature.

But more feature(s) I can get rid of from my own add-ons. I've already got a hack-job to support webp for attachments I can get rid of, and one for avatars can finally be slimmed down.
Was just thinking that it would make the emoji support in
redundant.

And we use Cloudflare to convert images to webp.
But these are all great advances and much better to have the core Xenforo do the work. Excellent update, thank you.
 
But seriously, I like the way WebP has been implemented, especially being able to convert currently attached pictures to it which I was wondering about.

Lack of WebP support has been a sore point for me for ages now, so this is very welcome.
 
I'm happy that there's no weird double file extension (eg: file-name.png.webp) like what other plugins do.

Glad there are CLI options to convert old attachments too.
 
Another excellent upgrade and speed improvement. Looking forward to seeing what else you guys have while I plan out my jQuery conversion...
 
I'm happy that there's no weird double file extension (eg: file-name.png.webp) like what other plugins do.

Glad there are CLI options to convert old attachments too.
No, there’s just .webp.(IDNumber) which can sometimes confuse aggregators into thinking it’s an unknown file extension. I hope the team have thought about considering changing it so the image ID is before the file extension.
 
The column for reactions is emoji_shortname, and contains values like :thumbsup:.
I'm using raw unicode for emoji support (technically arbitrary non-html text) in that field. I guess I'll just end up renaming it a bit and leaving it as-is.
 
Ah. For a second I thought the emoji post was about having ability to use any new emoji in post content. It's not. Webp updates are nice. Hopefully avif can become an option in a year or two. 🙏
 
Ah. For a second I thought the emoji post was about having ability to use any new emoji in post content. It's not. Webp updates are nice. Hopefully avif can become an option in a year or two. 🙏
Not sure I understand, surely there are no restrictions on any emoji with XF as is?
 
The new features are already exciting. And I can see many developers already thinking about how to make their add-ons compatible with 2.3.

As a regular admin, will Image Optimization be a global setting or will there be a separate setting specifically for XFMG? Even one step further, it would be very nice if we could set it on a category basis in XFMG.
 
Will there be an option to turn off client-side image resizing?

Reasoning
On some of our (photographic) forums we keep a copy of the original image so users can download this, if the image does get resized on the client this wouldn't work any longer (which at least I would classify as some kind of regression).

Furthermore some users really want to keep all EXIF data intact which also wouldn't work with client side image resizing.
 
Last edited:
There’s not really any justification I can see that it would need to be granular. So it is global.

Reason
In my forum there are high resolution occupational posters that I have uploaded to some categories of XFMG. I would prefer not to reduce the quality of these. As you know, we spend a lot of time to ensure high quality. I am sure many people may prefer a similar function for various reasons.
 
Back
Top Bottom