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.

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:

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

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:

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.

 

[island]

Thanks! Starting to wrap my mind around this...

If you choose to rebuild all images with optimization on, wouldn't it make more sense to change the static .jpg to .webp if all those thumbnails are actually webp format now?

I guess this would break external sites that had hotlinked or indexed the thumbnail url with .jpg (not sure this is an issue though -- aren't they more likely to be indexing/linking the full size images? Or maybe you might need a mod_rewrite redirect to redirect .jpg to .webp (if you've rebuilt images with image optimization on))

What would actually break by changing the .jpg to .webp to reflect what the thumbnail format actually is?

 

[digitalpoint]

Thanks! Starting to wrap my mind around this...

If you choose to rebuild all images with optimization on, wouldn't it make more sense to change the static .jpg to .webp if all those thumbnails are actually webp format now?

I guess this would break external sites that had hotlinked or indexed the thumbnail url with .jpg (not sure this is an issue though -- aren't they more likely to be indexing/linking the full size images? Or maybe you might need a mod_rewrite redirect to redirect .jpg to .webp (if you've rebuilt images with image optimization on))

What would actually break by changing the .jpg to .webp to reflect what the thumbnail format actually is?

Hotlinks would break, you would also have issues with sites that didn't force all uploaded images to a certain format (or sites that disabled it in the future). I promise you, it would cause more problems than it solves (which really is none, other than OCDness).

 

[island]

Don't mean to harp on this, but I'm curious -- how would it create issues with sites that didn't force all uploaded images to a certain format, if the thumbnail extension is always jpg now no matter what the real image format? Wouldn't it be the same in that respect to make the thumbnail extension webp?

 

[island]

Related question: do most people rebuild images when they turn optimization on?

Pro: makes pages load slightly faster by reducing image size, and saves storage space
Con: might lose a little bit of quality by recompressing

Any other pros or cons, or dangers of rebuilding images after turning webp optimization on?

 

[digitalpoint]

Don't mean to harp on this, but I'm curious -- how would it create issues with sites that didn't force all uploaded images to a certain format, if the thumbnail extension is always jpg now no matter what the real image format? Wouldn't it be the same in that respect to make the thumbnail extension webp?

Well, all the existing files that have already been uploaded would still be .jpg, so now the new URLs point to missing images. You could build a process to convert them all, but that feels like a complete waste of time to me. You would be expecting very large sites (who may have hundreds of millions of existing images) to spend a not-insignificant amount of time migrating all their images to a different file extension that is still not necessarily the correct format (and in the process of doing so, breaking links that people may have done to those images). You are only changing the extension for sake of changing it, you aren't solving the "problem" (which I guess is you want the extension to match the format).

The solution causes more problems than it solves. You are wanting to spend time (something no one has enough of), to potentially make images not function properly in a browser (changing the URLs on them all so hotlinked images would break), for the upside of your own peace of mind about the file extension (which currently functions just fine in browsers). To me, that makes no sense.

Maybe think about letting go of the entire concept of file extensions. They are archaic and rooted in filesystems from 50 years ago. Modern file systems have meta data for files. For example on a Mac, you don't need a file extension... you can have one if it makes you feel better, but it's not needed.

File with no extension... system knows it's a JPEG.

...give it a .webp extension... system still knows it's a JPEG.

...my point is that today, the "extension" is really nothing more than part of the filename. It can be anything you want it to be. Make it .abcxyz and it's still a JPEG.

 

[island]

You would be expecting very large sites (who may have hundreds of millions of existing images) to spend a not-insignificant amount of time migrating all their images to a different file extension that is still not necessarily the correct format

I'm getting closer to accepting this. But it's hard for a windows user One hopefully final question on this:
When exactly would the thumnail images not be webp format after running Rebuild Now?

 

[digitalpoint]

They would... at that point in time. But moving forward, someone may not upload a webp, and automatic optimization of uploaded files is an option, not something that always happens on all sites. So your best case scenario is every XenForo site is using the option (but again, it's an option, it's not forced on other sites). In your best case scenario, you still broke all the existing URLs. Now Google image search is linking to broken images, hotlinked images are broken, etc.

...and you are just kicking the problem down the road again. What happens when avif is an option? Personally I wouldn't use WebP if AVIF was an option. So later you convert everything to AVIF and you break all your existing URLs once again because you want the extension to be .avif instead of .webp?

If the solution was simple and didn't cause problems, I'd 100% agree. Use the correct extension, but it's not that simple... I definitely wouldn't want to go breaking existing URLs just so an extension is better when literally no normal user sees it. You want to spend time/effort to change all the URLs, which breaks them. For what upside? Basically none.

 

[digitalpoint]

One last thing... if it makes you feel better, this is not a XenForo issue, this is a thing everywhere on the web. For example, the first image I could find on google.com... one of their marketing images. It has a .png extension:

https://www.gstatic.com/marketing-cms/assets/images/75/98/d7a4a1254760b96d76382879c575/products-homepage-card.png=n-w780-h438-fcrop64=1,0000003dffffffc3-rw

Look at the HTTP headers, and guess what? It's not even a PNG...

HTTP/2 200
cache-control: public, max-age=3000
age: 2416
last-modified: Thu, 21 Aug 2025 15:38:39 GMT
content-type: image/webp

 

[island]

For years, before CSS was reliable without overlap problems, I used tables to do the whole layout. So I can probably accept this too

 

[island]

They would... at that point in time. But moving forward, someone may not upload a webp, and automatic optimization of uploaded files is an option, not something that always happens on all sites.

Has anyone turned optimization OFF after turning it ON and Rebuilding?
Trying to decide today whether to Rebuild Now to optimize existing images.
Is there any reason not to do this, or to go back to turning optimization OFF in the future?

 

[digitalpoint]

Has anyone turned optimization OFF after turning it ON and Rebuilding?
Trying to decide today whether to Rebuild Now to optimize existing images.
Is there any reason not to do this, or to go back to turning optimization OFF in the future?

Beats me... all XenForo sites don't report to me (actually none do). But I'm sure it's happened... could just be someone moving to a different server or different version of PHP where WebP support wasn't compiled in.

Again... it's an OPTION, if it was meant to be applied to every site, it wouldn't be an option.

Personally, I have not optimized exiting images on my site. Every time you do an "optimization" you will loose a tiny bit of clarity since you are moving to/from lossy formats. I don't personally think WebP is worth the effort of rebuilding everything on large sites. When AVIF is an option, then I'll probably do it.

 

[island]

Thanks very much.

Maybe at some point in the future as more people use the Optimization feature, there could be an added OPTION to make the thumbnail extension .webp if the site has chosen to Rebuild all the images to webp.

Users were increasingly posting full color png images such as phone screenshots which were very bloated, so hopefully this will be a nice benefit to make those much more efficient as webp.

Now I just have to decide whether to rebuild all images optimized now.

It sounds like other than the extension for thumbnails being wrong for more than before (since most of my images were jpg and thus .jpg was mostly right before) the only drawback is a slight loss of quality though the re-compression.

Thanks again!