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.
 
Not sure I understand, surely there are no restrictions on any emoji with XF as is?
This is a bit confusing for me tbh. I remember having this discussion few years ago.


This is regarding newer emojis released by Unicode and as your device gets support for them. They appear as boxes even on devices which support them. This makes sense if you use non-native option as mentioned in the thread as they would need to be updated. At that time if your board is set to use native emojis, newest emojis did not appear in some parts of the forum even though they were supported by the device being used. Things might have changed since then. A few emojis launched in 2023 seems to appear fine here on this board but here, joypixel would be up to date. It is hard to test support for latest emojis on W10 (or Androids) which is stuck on a really old emoji set even with all updates. Would do some testing if I can get access to an Apple device. Thanks!

tldr. native emojis did not use to work in post content if the emoji was not supported by the toolkit used by joypixels.
 
Last edited:
Another addition that could help save space and even optimize loading times is to have the image uploader check to see if the image has already been uploaded before. Then it could use the existing data instead of saving it as a duplicate image. I recently calculated that something like this would save 7 GB of space on my forum.
post this as a suggestion
 
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.
Having the ability to override the behavior so we can retain the full EXIF would be important for our photography site. [EDIT: Our members would rather have the extra 60~KB in the upload than lose the EXIF.)

Currently our add-on uses exif_read_data to grab the EXIF data after the attachment is on the server but before it gets resized; the resulting array is then stored in a side-table (after we remove some key-value pairs such as GPS info) associated to the attachment so we can format & display elements with the attachment in the post.

Speaking of photography sites... with the image resizing now being client side, is there any mechanisms exposed where we can tweak the settings? I know of several XF admins who have used various means of changing the filter that is used during the resize and also to comment out the stripImage function.
 
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.
This is indispensable!
 
Tell me, if we use s3, will there be any problems? using this plugin?

It shouldn’t matter because XenForo uses an abstracted filesystem. I do t see them going backwards not no longer using abstracted filesystem in 2.3.
 
When the image is resized, is there any compression also added? Is it possible to enable/disable between the forum components and the gallery? This is awesome for forum upload attachments, but in the scenario where we have a category in the gallery where we want users to upload essentially raw images, resize and compression would not be wanted.

Really excited about 2.3; it's looking awesome! Still holding out for chunking though :)
best friends love GIF
 
Just watched that video and liked what I saw. I'm so gonna renew when 2.3 drops. :)

@Kier @Chris D when converting from jpeg to WebP at the same resolution, is there any quality loss?
 
Very nice job! Does this help with videos in any way?
I don't think any changes / features mentioned in this HYS would affect videos in any way.

IMHO it is a bit disappointing to see that effort has been put into improving client side loading performance for embedded content (images), but Lazy Loading for IFrames has not been addressed :(

On pages with many embedded non-image content this could have a positive effect.

@Kier @Chris D when converting from jpeg to WebP at the same resolution, is there any quality loss?
In most cases you would be converting a lossy format (JPEG) to another lossy format (WebP).

This does require recompressing the image which will have a negative effect on image quality (most likely measurable, but not necessarily perceivable for the average human eye)
 
Last edited:
The first step is to use the AssetVariantTrait in your Entity which has one required method to implement:

PHP:
public function getAssetVariantSizeMap(): array
{
   return [
      'image_url' => [
         's' => 128,
         'm' => [512, 456]
      ]
  ];
}
What if I want a variant with a width of 512 pixels but I don't care its height (it should be proportional).
Would this work as well (by specifying a height of null / 0)?
 
In most cases you would be converting a lossy format (JPEG) to another lossy format (WebP).

This does require recompressing the image which will have a negative effect on image quality (most likely measurable, but not necessarily perceivable for the average human eye)
Thanks, I thought so as I knew they're both lossy, hence asked the question. For a forum image, the very slight quality loss likely won't matter since those pictures are for illustration rather than as a high quality resource. Now, the media gallery might be a different proposition.
 
Tell me, if we use s3, will there be any problems? using this plugin?

A few years back I ran a WP bulk image optimisation plugin which proceeded to read/write several thousand files to/from S3 overnight. Got a nice big AWS bill that month.
 
Back
Top Bottom