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.
 
Click to expand...
100% compression means to minimize compression as much as possible but is a distinct concept from lossless compression. GD did not introduce support for lossless WebP until PHP 8.1 so it's not something we've supported there in XF 2.3. ImageMagick automatically enables lossless compression if the value is 100%. It can dramatically reduce the file size savings though.

beerForo said:
So "Optimize attachments" in Tools >> Rebuild caches would not rebuild them?
Click to expand...
No, otherwise the contents of already optimized files would degrade every time you run the tool. Even if you didn't change the setting, 80% twice is 64% of the original quality.
 
Yeah, most of the value proposition of WebP is that its lossy compression is quite good on average (though individual results can vary, of course).

beerForo said:
Of course, I was asking based on lossless to lossy. Thanks for the clarifications!
Click to expand...
Whether a WebP is lossy or not is stored in the file but it's not exposed to us via GD or Imagick so we have no way of knowing currently (beyond introducing manual byte inspection). The lossy compression level is only used during encoding and not stored in the file at all.
 
beerForo said:
So we can add this as value 100 for a lossless webp, still saving space but having the lossless file correct? Then if later we want to reduce quality we would run it again with the lower value? Or can we not rebuild webps based on this value later?
Click to expand...

It's not lossless btw. I don't know how to explain but it's not lossless.
 
Any reason why thumbnails are still .jpg? Why can't they be optimized too? yes, sure, they are small files even as jpg, but every KB counts.
 
Thumbnails of images are the same format as the full image even though the extension is always jpg.
This has always been the case and is done for simplicity reasons and to avoid breaking existing links.
 
Kirby said:
Thumbnails of images are the same format as the full image even though the extension is always jpg.
This has always been the case and is done for simplicity reasons and to avoid breaking existing links.
Click to expand...
I believe that's how avatar work, but not attachment thumbnails.

This was uploaded as a PNG for example...

It was converted to WebP (as expected):

headress.webp


Code: 
content-length: 85224
content-type: image/webp

The thumbnail is a jpg (even when looking at content-type header):


Code: 
content-type: image/jpeg
content-length: 17290
 
This is excellent! Thank you!!!

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.
Click to expand...


I'm slightly confused by the thumbnails and other programatically set file names being jpg when the file is actually a webp format. What would it take to change the jpg extension for thumbnails to webp extension for example?

Very happy to see both the optimization and the client side resize features.
 
island said:
I'm slightly confused by the thumbnails and other programatically set file names being jpg when the file is actually a webp format. What would it take to change the jpg extension for thumbnails to webp extension for example?

Very happy to see both the optimization and the client side resize features.
Click to expand...
It has to do with the full image path being able to be known without extra queries to the database (or even just storing image type data for every image) in the database. You know what the avatar path is just by knowing the user id, or the attachment thumbnail just be knowing the attachment id.

Would it be nice to have the correct extension? Sure, but it's also an OCD thing where normal users aren't going to know the difference... not sure the overhead of extra data/queries would be worth it.
 
Thanks -- this may be my OCD as a windows user wanting the extension to be accurate, but the OCD is real :D

(Over the last 20 years, especially in the early days, a user will say this JPG won't work, and I'll ask them to send the photo, and what I get is a word file or a pdf that had been renamed to .jpg, and of course windows programs choke if you try and open or import a file where the extension is wrong.)

As far as database queries, I don't quite follow and that's bothering my OCD even more ;)

If you rebuild images after turning optimization on, doesn't that convert all jpg and png images to webp for example?

If you have posts now where you now have attached webp thumbnails linked to webp image attachments, I don't understand having the thumbnail777.jpg linked to image777.webp. How does keeping the thumbnail extension jpg (which is now wrong since it's actually a webp format thumbnail) save a database query here?
 
island said:
Thanks -- this may be my OCD as a windows user wanting the extension to be accurate, but the OCD is real :D

(Over the last 20 years, especially in the early days, a user will say this JPG won't work, and I'll ask them to send the photo, and what I get is a word file or a pdf that had been renamed to .jpg, and of course windows programs choke if you try and open or import a file where the extension is wrong.)

As far as database queries, I don't quite follow and that's bothering my OCD even more ;)

If you rebuild images after turning optimization on, doesn't that convert all jpg and png images to webp for example?

If you have posts now where you now have attached webp thumbnails linked to webp image attachments, I don't understand having the thumbnail777.jpg linked to image777.webp. How does keeping the thumbnail extension jpg (which is now wrong since it's actually a webp format thumbnail) save a database query here?
Click to expand...
The short version is it saves database queries because you don't need to query for what the image format is. Without querying the database, how would you generate the URL? You can do all of it (based on the user ID in the case of avatars). But if the extension isn't a static value (regardless of the format), you would need to query for it. You have to remember that not all sites convert all images to a specific format (although some do). You could of course force .webp on everything instead of .jpg, but you still have the same issue (webp isn't necessarily correct... additionally, you just broke all the images that are already there). What happens when avif is the default instead of webp?

Thankfully browsers analyze the image contents rather than rely on the extension, so it will display the image regardless of the extension.
 
Back
Top Bottom