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...
@Chris D

If we are storing our attachments in AWS S3, then rebuilding/optimizing the previous attachments will be possible? and the old files supposed to be removed from S3 right?
 
@Chris D is there any reason why PNG files are not converted to webp?
I see a mix of png/jpg/webp files:
1729127775277.webp


Some jpg files were not converted, I guess it's because the webp file size is bigger than jpg perhaps?
 
Chris D said:
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...
So the webp images appear as ,jpg if viewing the source code in the browser? If the user downloads it I assume it will be a webp?
 
@Chris D Is there any way to ignore specific directories during the image upload process so the jpg isn't converted to webp? Or do we need to FTP it up? We have a custom addon that looks for .jpg files and if it's a .webp, it errors out.
 
Jeremy P said:
Not yet, but we'd likely just take the approach I outlined where add-ons are free to swap in a build of the library with a bigger set. We don't have a built-in option to disable client-side processing, but it is a simple toggle on the attachment manager (data-resize-images="false").
Click to expand...
Am I correct (after taking a look at the JS) that even if the file is not resized that the EXIF data is still stripped out & replaced with the subset? 🤔
 
Sort of, since the resulting file is often smaller (or indeed even converted to WebP on the client when image optimization is enabled) and thus uploads quicker even if the file did not need resizing. However if it's disabled via the attribute I mentioned it shouldn't happen no matter what.
 
Jeremy P said:
Sort of, since the resulting file is often smaller (or indeed even converted to WebP on the client when image optimization is enabled) and thus uploads quicker even if the file did not need resizing. However if it's disabled via the attribute I mentioned it shouldn't happen no matter what.
Click to expand...
Thanks. For the attribute, I may be missing the obvious but adding it to helper_attach_upload seems to have no impact. Am I being dense and am totally off with where you meant to put the attribute?

Code: 
    <xf:button href="{{ link('attachments/upload', null, {'type': $type, 'context': $context, 'hash': $hash}) }}"
        target="_blank" class="button--link js-attachmentUpload" icon="attach"
        data-accept=".{$constraints.extensions|join(',.')}"
        data-video-size="{$constraints.video_size}" 
        data-resize-images="false" />
 
Kevin said:
Thanks. For the attribute, I may be missing the obvious but adding it to helper_attach_upload seems to have no impact. Am I being dense and am totally off with where you meant to put the attribute?
Click to expand...
It should be added to the same element as eg. data-xf-init="[...] attachment-manager [...]", like in the thread_view template for example.
 
Jeremy P said:
It should be added to the same element as eg. data-xf-init="[...] attachment-manager [...]", like in the thread_view template for example.
Click to expand...
Thanks, Jeremy. A quick sandbox test so far and that seems to do the trick, I'll try later tonight in the prod environment. 👍
 
BlueSquares said:
@Chris D Is there any way to ignore specific directories during the image upload process so the jpg isn't converted to webp? Or do we need to FTP it up? We have a custom addon that looks for .jpg files and if it's a .webp, it errors out.
Click to expand...
I also have this question, any way to exclude some addon or directory? Thanks
 
Back
Top Bottom