XF 2.3 Boosting performance in XenForo 2.3

In today's 'Have you seen...?' entry for XenForo 2.3 we're going to look at how we've zeroed in on enhancing performance, ensuring your community has a swift and seamless experience. We're going to take a deep dive into the advancements we've made and how they stack up against various performance metrics.

But, before we get into the individual changes, let's take a quick look at the baseline - this is our current Performance score as calculated by Lighthouse for the XenForo Community forum list:

​

Here's the performance scores for some other forum software:

​

It's crucial to note that while this score provides a performance benchmark, it isn't the only indicator of success. Indeed, results can fluctuate slightly with multiple test runs. A site can still enjoy popularity with a lower score, but a higher rating undeniably enhances both search engine rankings and overall user experience.

Stay tuned! We'll reveal XenForo 2.3's updated score shortly. But before that, let's dive into the changes that have brought us here, shall we?

If you would like to jump to a particular section, use the links below.

• Font Awesome improvements
• JavaScript performance
• Bye bye jQuery
• Improved CSS performance with HTTP/2+
• Conclusion

Alternatively, if you want to skip a whole lot of reading, check out the TL;DR below:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

Oh and if you're concerned that all we've got to show you in XenForo 2.3 is performance improvements - fear not.

We will be showcasing a brand new feature next week!

 

[AndrewSimm]

The underlying code between 2.3 and 3.0 will be the same.

Oh so it's sexy time from the get go. Great news!

 

[Paul B]

Oh so it's sexy time from the get go. Great news!

You sound like my wife ...

 

[AndrewSimm]

You sound like my wife ...

She must be a fine lady

 

[JustinHawk]

At this point this is mostly a micro optimisation so unlikely.

Every small change matters. As you might be aware that Google Pagespeed Mobile testing is done on Moto G which is from the year between 2010-2015(Unsure), aka a low end device. This becomes important when you are having members using old mobile or a not so good one that offers better performance. We cannot use compression at the same time because it use the devices itself to uncompress it, which can again lead to performance issues.

Anyhow anybody doing testing on Pagespeed should be aware of CPU etc while doing testing, otherwise page speed for high and low end device is going to affect you badly.

In the below case scenario by Pagespeed (pagespeed.web.dev), it only using a power of 393 which is very low. so the score will be mostly less than or around 50.

But if we again retest, google can assign a power of upto 1400 or as less as 150. which will drastically improve/decrease your performance score to around of 80 or decrease to 30.

In your test I would like to dig deep and see how much power does your Mac assigned for testing. Here is my screenshot below for HYS forum with power of around 2.5k. So wanna know how 2.3 perform on a low end device?

 

[Jeremy P]

Even on old, low-end devices, I would not expect compression to introduce a noticeable performance penalty. Compression also greatly reduces the payload on slow networks and can prevent cache eviction on storage-constrained devices, so it would be a performance trade-off at best. When taking compression into account, the benefits of HTML minification tend to be pretty negligible. This page is currently ~167kb but compression brings it down to ~37kb. Minifying the HTML only yields an additional savings of a few kilobytes.

So wanna know how 2.3 perform on a low end device?

The exact scores can vary based on the device and other factors, but the changes made should yield relative improvements across the board. So, better than 2.2.

 

[Xon]

We stop supporting 2.2 when 2.3 is released. We expect add-on developers to do the same.

This just isn't viable for larger and more complex add-on sets

My position hasn’t changed. I do not believe that developers should spend time supporting two different code bases for what should be a dininishingly small number of users. It’s not worth your time that could be better spent writing new code for a supported version.

It took well over a year after XF2.2's release before I stopped receiving XF2.1 related support requests.

I really want to not have to split a large number of my add-ons into separate branches when often the changes are fairly minor.

 

[Empty]

Cool to see optimization! Sad to see it'll make a lot of work for the addon devs. I hope it all works out in the end Maybe some collaboration between XF team and the most active and trusted addon devs could be done to bridge the gap. Particularly, Ozzy and Xons work has been invaluable to us and I don't see us moving to 2.3 until they and a few others are ready.

 

[Xon]

Eh, might as well just say yes. But that’s all it is. “Conversations” has always been a somewhat confusing moniker. It was chosen, admittedly before the popularity of “direct messages” being used on other services/platforms. I think the original idea was they wanted to avoid “private messages” as it’s a bit of a misnomer given they aren’t necessarily private - you can invite others, you can have an admin who reads them via an add-on, they can be seen by moderators (partially) if messages are reported and so on.

Direct message takes less explaining.

Nothing in the code has changed at this point apart from phrases and routes.

Will you post the exact route changes somewhere so developers can start prepping for this change? (So many $xf.versionId checks to be added)

 

[Jeremy P]

The conversations route becomes direct-messages and the conversations/messages route becomes direct-messages/replies. The existing routes are still present and unchanged. We should have a thread focused on developer-related changes in due course, but the changes should be fairly minimal outside of the removal of jQuery.

 

[gib]

Some great work on the performance side of things, well done.

Image/Photo load times with JPG files can be a bit of a drain, are native WEBP images going to be part of 2.3 or is that more of a 3.0 thing ?

 

[CedricV]

Well done. Beats having to cache everything. Or is that still recommended?

 

[Karelke]

Finally getting rid of the dinosaur called jQyery

For everyone who wants to migrate, also check out You might not need jQuery

 

[Xon]

For everyone who wants to migrate, also check out You might not need jQuery

That website really reads like why jQuery is just superior developer experience wise than plain javascript.

I'm probably just going to ship jquery-3.7.1.slim.min.js with my StandardLib add-on for a while to reduce porting time (might do a custom build of jquery to slim it down as much as possible).

 

[Mr Lucky]

Thanks Chris for the very thorough explanation and for all the work. I can't begin to imagine how time consuming and frustrating it must have been working on the jQuery. It's not as if you could just pay someone on Fiverr to do it

I have one question as a non-tech form admin:

But, if you get completely stuck, you could always re-add jQuery if you wish but, we'd recommend avoiding that if you can. And removing jQuery as a dependency can start now if you're planning on making changes to existing code before XenForo 2.3 is released. We strongly advise against writing new code that directly uses jQuery functionality at this point.

Does this mean any existing addon which relies on jQuery will

1. stop working on 2.3
2. will work as is but just cause extra page load?

While writing this, regarding (1) I just see Xon's post may have answered that:

I'm probably just going to ship jquery-3.7.1.slim.min.js with my StandardLib add-on for a while

So an addon dev can include it themselves in order to continue temporarily until they can rewrite all addons?

So is it the case that up until now, devs have always relied on the built in library but that (with 2.3 compatibility) they can add it themselves.

But if they do that then will we the end user be able to know that we are using something that potentially negates all the good work you have done with the correct performance, perhaps devs should be obliged to mention in the addon overview?

It's good that Xon has already mentioned adding it (as a temporary measure) because otherwise those of us that want to upgrade to 2.3 may be hanging around waiting on compatibility.

 

[topkurs2]

Good, but pretty big changes, after which some addons will stop working. Is this really version 2.3 and not 3.0?

 

[Miri]

This is only loaded on the pages that actually use those icons but, what is even better, is that whereas previously we'd load a full 137 KB font file, this spritesheet weighs in at a mere 726 bytes.

Overall, the total file size we were loading for icons by default on the forum home page was around 400 KB now it will be less than 40 KB.

This all seems more "awesome" than Font Awesome itself.

If I may interject in support of the developers instead.

I agree that you should make all decisions regarding changes to your software, even if they are radical and drastic. However, these developers should be informed well in advance of the "HYS," perhaps by having them sign a contract not to disclose information about software updates. It's a shame they are excluded from the development roadmap, especially those with many components and/or complexity. We can't expect them to quickly update their addons; some have more than 100 addons, and many communities rely on their addons.

So, in this regard, I think XF can do better.

 

[Alpha1]

This is great. I love speed enhancements, so this is really nice.

It would be nice to see GTMetrix.com analysis as well.

Kier not being able to show the network waterfall for XenForo 2.3 seems just a tad suspect.

The Lighthouse tests above are all run on pages that have almost no images. No Article forums like this HYS forum with lots of images in it. No Gallery. But image optimization has a massive impact on performance. Webp should be coming in 2.3

WebP is nice, although I’m kind of waiting for XF to support WebP natively

Coming in 2.3

So I guess there could be another HYS about More XenForo performance enhancements that includes image optimization and webp.

** Smileys are acting really quirky in this post.

 

[Slavik]

So, in this regard, I think XF can do better.

This is why it is one of the first HYS out. We still have many new HYS to come, as well as the pre releases before the stable 2.3 is released. Even devs with loads of addons will have plenty of time to update before then.

 

[Stuart Wright]

We had a site speed audit for AVForums and it suggested we improve all the elements mentioned here.
We were resigned to the barrier that we couldn't change core Xenforo to speed up JS and CSS without much expense and later upgrade pain.
We were about to create a system for making FontAwesome subset. I'm glad I don't have to pay for that, now.
I think we should run Lighthouse in mobile mode more than desktop because for many sites like ours, mobile users (including tablets) account for around 50%.
Feeling great about this update and looking forward to getting it with annoying impatience.

 

[Mr Lucky]

I think we should run Lighthouse in mobile mode more than desktop because for many sites like ours, mobile users (including tablets) account for around 50%.

I thought Lighthouse automatically runs in mobile mode