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!

 

[Chris D]

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

To be clear, all of the tests in our video were performed with the mobile test only.

 

[grisha2217]

What about user avatars? Do you store it in .jpg format? Do you plan use .webp format?

 

[Xon]

What about user avatars? Do you store it in .jpg format? Do you plan use .webp format?

Reliably serving webp avatars without breaking backwards compatibility is sadly a little involved, it is definitely better than it was.

 

[Newsman]

Quite the juicy update!

The removal of jQuery is quite major but also something that isn't too shocking to me as JS itself has evolved quite a bit.

Thanks for all your hard work! Really excited for 2.3

 

[Jake B.]

Honestly? Just don’t try to write the same code for two different versions. We stop supporting 2.2 when 2.3 is released. We expect add-on developers to do the same.

We’re extremely unlikely to do anything that helps developers support unsupported software.

Even when there aren't breaking changes in an update, many people aren't going to blindly upgrade to XF 2.3 the moment it's released, they're going to have to wait for styles and add-ons to be updated. Wanting to support both 2.2 and 2.3 in an add-on especially is definitely not that absurd of a request, at least for a period of time when not everyone is going to be able to upgrade, especially when there are fairly significant non backwards compatible changes, such as the entire removal of jQuery. A small change, such as being able to get the current version (or at at least the first and second point) definitely seems reasonable

 

[Kier]

I think we can definitely provide a 2.2 / 2.3 / 3.0 lookup of some kind in JS.

 

[grisha2217]

I think we can definitely provide a 2.2 / 2.3 / 3.0 lookup of some kind in JS.

I think this is bad practice to support several major versions in JS file. Will be better to separate code on few JS files via XF template like this:

<xf:if is="{$xfOptions.versionId} >= 2300070">
    <xf:js src="myaddon/vendor/scripts/2.3/core.js"  />
<xen:else />
    <xf:js src="myaddon/vendor/scripts/2.2/core.js"  />
</xf:if>

 

[digitalpoint]

I think this is bad practice to support several major versions in JS file. Will be better to separate code on few JS files via XF template like this:

<xf:if is="{$xfOptions.versionId} >= 2300070">
    <xf:js src="myaddon/vendor/scripts/2.3/core.js"  />
<xen:else />
    <xf:js src="myaddon/vendor/scripts/2.2/core.js"  />
</xf:if>

It depends on how major it is between versions. If someone migrates everything they can to native JavaScript even for 2.2, and it's a matter of a single line of code, I'd go with maintaining the single JavaScript fie.

Something like:

... lots of JavaScript code ...

if (XF.ver && XF.ver >= 2300070)
{
    XF.on('#something', 'xf:reinit', e => {this.ReinitHandler});
}
else
{
    $('#something').on('xf:reinit', e => {this.ReinitHandler});
}

... lots of JavaScript code ...
[code]

 

[btmgreg]

I think we can definitely provide a 2.2 / 2.3 / 3.0 lookup of some kind in JS.

What about 3.1?

 

[Chris D]

Still not really seeing the point of adding a version ID into the code.

if (window.jQuery)
{
    $(el).on(...)
}
else
{
    XF.on(el, ...)
}

Many ways to do the same thing.

 

[Frode789]

This looks fantastic, thank you XF team for the focus on bringing performance improvements. It was more than I dared to hope for!

Also I hope we will get a image performance related HYS later.
With details on WebP, lazy loading images that are not in the main rendering by default, changing attachment full size images to responsive smaller copies for mobile devices etc.

 

[digitalpoint]

Still not really seeing the point of adding a version ID into the code.

if (window.jQuery)
{
    $(el).on(...)
}
else
{
    XF.on(el, ...)
}

Many ways to do the same thing.

While that would work in principle, I wouldn't count on other addon developers to NOT load jQuery... Although if they do that will probably work, but I can also see a situation where addon developers are loading stripped down versions of jQuery, so having the jQuery object exist doesn't necessarily mean all the jQuery functions are going to be there.

A better option would be to check if the function you want to use exists in the XF object (for example XF.on). That's easy enough, but there has also been times in the past where I wished we could know the XenForo version on the client-side for other JavaScript functions that are in newer versions of XenForo. It's just really ugly trying to discern the version of XenForo we are dealing with by checking if methods exist or not.

 

[cdub]

making/editing the video is a task in itself!

I edit television shows for network television. Editing takes a lot of time. Even one minute of content takes forever sometimes.

Me: I never want to see JavaScript ever again

As a non developer most of this thread is way way way over my head but I'm glad everything is faster!!

 

[Mendalla]

As a non developer most of this thread is way way way over my head but I'm glad everything is faster!!

I've done some JS programming for work but I'm really a "script kiddie" more than a serious developer. And I now have staff under me to do stuff like that which means I haven't done any in quite a while. So I appreciate the effort but, yeah, it's a bit over my head, too. If it leads to better performance, I'll just be happy with that and let the big boys deal with the details.

 

[Kier]

… so you can query this from JS or CSS, and if html[data-xf] does not exist, you’re looking at 2.2 or older.

 

[⭐ Alex ⭐]

View attachment 291692

View attachment 291693

… so you can query this from JS or CSS, and if html[data-xf] does not exist, you’re looking at 2.2 or older.

Hm... but....

Was keeping this secret providing some level of security by obscurity for forum owners when an exploit is discovered in XF? Now threat actors can quickly do a web scan looking for vulnerable XF's without authentication by just loading the index page. Sometimes the vulnerability might require registering an account and can't be detected in forums with functioning registration bot protection.

 

[RobParker]

That's awesome! Please don't take this the wrong way but what happens to your score when you add in some adsense code? It always seems it's the external libraries that kill our score.

 

[Forsaken]

Hm... but....

Was keeping this secret providing some level of security by obscurity for forum owners when an exploit is discovered in XF? Now threat actors can quickly do a web scan looking for vulnerable XF's without authentication by just loading the index page. Sometimes the vulnerability might require registering an account and can't be detected in forums with functioning registration bot protection.

Targeted attacks are actually very rare, and it is usually done with an automated system that just checks every known vulnerability for the software, server OS or any other possible attack vector.

Hiding version string is generally pointless .

 

[Kier]

Was keeping this secret providing some level of security by obscurity for forum owners when an exploit is discovered in XF?

Yes, but as @Forsaken said, only on a relatively superficial level. It would be fairly straightforward for any attacker to identify 2.1, 2.2 and 2.3 based on the available features, but concealing the third point version does prevent easy identification of versions prior to patch installation.

 

[Paul B]

That's awesome! Please don't take this the wrong way but what happens to your score when you add in some adsense code? It always seems it's the external libraries that kill our score.

Google is notorious for not following its own directives.

It's own pages score poorly on Lighthouse.

And it does cause scores to reduce when using adsense.

There's not a lot XF can do about that.