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.
 
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.

If you're going to bulk process files stored in S3 you're 100% better off starting up a temporary EC2 instance within the same region as your S3 bucket and running the process from that EC2 instance as you pay no data transfer costs for data within the same AWS region. Could process hundreds of terabytes of data with the only additional cost being for whatever tier of EC2 instance you're running it on
 
And the next one’s?
Back to normal. Actually I just checked and it was an Amazon Cloudfront bill of $480.03, not AWS.

Edit: Unbelievably enough they wrote it off when I contacted them.

ANYWAY to stay on topic - it could be something to bear in mind if someone were to be considering converting a lot of image files.
 
on demand media conversion would have been nicer (images converted on the fly as they are first called from old posts). would have worked better on low end hosting accounts as well. but i guess addon developers have a lot of potential to offer customized addons for webp functionality! one feature definitely would be to have different compression options for gallery and forum. should be interesting once this is out in the wild!
 
Back to normal. Actually I just checked and it was an Amazon Cloudfront bill of $480.03, not AWS.

Edit: Unbelievably enough they wrote it off when I contacted them.

ANYWAY to stay on topic - it could be something to bear in mind if someone were to be considering converting a lot of image files.
I expected that next S3 bills gone down after the conversion.
 
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
Can these commands take advatange of multiple CPU cores, eg. support --processes like for imports?
 
We will now track these sizes within the embed_metadata field of the content and to a certain extent, can rebuild that information when the "Post embed metadata" rebuild is run against existing content (if the dimensions have been stored by the image proxy).
Do we need to keep the image proxy enabled to do this or can we turn it OFF when the rebuild is done to have the dimensions added?
 
On upload, all currently supported image types (except GIFs) will be saved to WebP format.
Is there some reason not to convert GIFs also to webp (which as far as I know supports animations)? 🤔

Or alternatively, converting them into some video format that takes a lot less space? :)
 
Converting to an alternate format, like video, requires FFmpeg which is probably a step too far in the general case.

Turns out GIF to WebP is possible, I was just experiencing issues with it while I was developing this. I think @Jeremy P is/has sorted that though.
Converting animated images (or compressing them) will often massively degrade the quality; if animated conversion support is added, please make it optional.

I have personally had to make 600+ animated gif for one site, and having their quality degraded would mean almost a thousand hours of work would have to be re-done, or completely done away with.
 
Converting animated images (or compressing them) will often massively degrade the quality; if animated conversion support is added, please make it optional.

I have personally had to make 600+ animated gif for one site, and having their quality degraded would mean almost a thousand hours of work would have to be re-done, or completely done away with.
Here's an example of a GIF uploaded to our forum:
Original GIF @ 2.1MB:

example.gif



Webp (lossy) @ 1 MB: https://ampxf.com/media/user-uploads/example-lossy.webp
(It seems Xenforo doesn't allow attaching webp images yet...)



MP4 @ 269 kB (This is for example what Imgur / Giphy does to serve "gifs"):

MP4 can be made to behave like GIFs with autoplay, loop, and mute on the <video> element. (example can be seen by inspecting source at Giphy link)

I don't really see any markable difference between the GIF/WEBP/MP4, but there is a significant decrease in size...
 
Here's an example of a GIF uploaded to our forum:
Original GIF @ 2.1MB:

View attachment 292681


Webp (lossy) @ 1 MB: https://ampxf.com/media/user-uploads/example-lossy.webp
(It seems Xenforo doesn't allow attaching webp images yet...)



MP4 @ 269 kB (This is for example what Imgur / Giphy does to serve "gifs"):
View attachment 292682
MP4 can be made to behave like GIFs with autoplay, loop, and mute on the <video> element. (example can be seen by inspecting source at Giphy link)

I don't really see any markable difference between the GIF/WEBP/MP4, but there is a significant decrease in size...
The images in question can run from 13 to 25 frames (long animations), and are about 5-10mb each.

Converting to webp causes noticeable grain, and optimizing to webp adds more grain; that said it is better than gifsicle so I will have to see if I can make things work.
 
The images in question can run from 13 to 25 frames (long animations), and are about 5-10mb each.

Converting to webp causes noticeable grain, and optimizing to webp adds more grain; that said it is better than gifsicle so I will have to see if I can make things work.
Maybe a semi-automatic conversion can be a solution? For example: lists in the backend all the gifs (sorted from bigger in size), select like 20 of them and "preview convert", pick the previews you like to confirm the conversion.

In this way you don't have to convert all if some of them as too grain and you can free up a lot of disk space.

For new uploads maintain gifs and do this semi-auto conversion like once a month.
 
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.
Does the rebuild process change xf_attachment_data.file_hash?

Although users shouldn't do that, I am sure there could be a dozen posts when users embedded thumbnails via [IMG].

So if xf_attachment_data.file_hash ist changed, this would also change the URL of attachment thumbnails and break those embedded images.

If it is not changed but the files are modified, this could cause issues with deduplication.
 
Does the rebuild process change xf_attachment_data.file_hash?

Although users shouldn't do that, I am sure there could be a dozen posts when users embedded thumbnails via [IMG].

So if xf_attachment_data.file_hash ist changed, this would also change the URL of attachment thumbnails and break those embedded images.

If it is not changed but the files are modified, this could cause issues with deduplication.

Good question.
Also, the addresses of mp4 files...
 
Last edited:
Back
Top Bottom