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]

That wasn’t meant as an example, rather that I just miss $.css()

I do miss $.css. Working with el.style and window.getComputedStyle separately is a bit of a pain, though on a practical level I have somewhat grown to dislike some of the helpers in jQuery which essentially conflate two separate things. The behaviour of $.data can be particularly annoying being that it deals with both dataset and essentially an arbitrary storage mechanism.

Lost count of how many times moving to JS style versus $.css tripped me up too being that, if I’m recalling correctly, jQuery didn’t require you to pass in units for things like width.

 

[Chris D]

{{ link ('direct-messages', $conversation) }}

Are conversations being rebranded?

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.

 

[Taylor J]

Me: I never want to see JavaScript ever again
Also me: * starts a new JS centric project for 3,0 *

This sounds like me when I say I am against JavaScript on the server but then my day job is working as a backend dev creating apis in express. I cry on the inside.

 

[Lee]

This is actually the update I have been waiting for. Anything to get our content on the screen of our end users faster is obviously worth the time spent.

Good job migrating away from jQuery. I bet that was a mammoth task in itself.

 

[Chris D]

I bet that was a mammoth task in itself.

I sometimes wonder how I persevered with it. I was working on it solidly for about 8 weeks and I only cried once.

It’s @Jeremy P who I feel sorry for. He had to code review and fix all my bugs

 

[digitalpoint]

I sometimes wonder how I persevered with it. I was working on it solidly for about 8 weeks and I only cried once.

It’s @Jeremy P who I feel sorry for. He had to code review and fix all my bugs

Is there any reason to not use addEventListener() rather than wait until we have XF.on() (for cases where I don’t need to remove event listeners)?

 

[mjda]

Eh, might as well just say yes.

Yes! Thank you! Trying to explain the meaning of conversations is so tiring. Send me a DM is much more well-known, and easier to type than start a private conversation with me.

 

[Chris D]

Is there any reason to not use addEventListener() rather than wait until we have XF.on() (for cases where I don’t need to remove event listeners)?

No reason at all. Unless you need namespaced events. There’s a new XF.trigger() method too as a wrapper around dispatchEvent which is also fine to use. The inability to remove event listeners without a reference to the original handler is the biggest pain that on/off helps with, but often not too difficult to just keep that reference anyway.

 

[digitalpoint]

View attachment 291644In 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:

View attachment 291640
​

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

View attachment 291641 View attachment 291642 View attachment 291643
​

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!

The part of this video where @Kier is talking about performance of CSS and we are just looking at Cloudflare’s cache header for the CSS requests being DYNAMIC because xenforo.com isn’t having Cloudflare edge cache them…

 

[Ozzy47]

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.

Hmm, this is not good news.

 

[Chris D]

Which part of it is news?

We never support more than one active version. The only exception to that is of course security releases and the exceptional case of supporting 1.5 for an extended period after 2.0 was released.

We have always recommended add-on developers do the same, branching new functionality off into a new version, while leaving the last stable version as-is for people who need legacy support.

Of course you can do what works best for you, but that’s our recommendation.

 

[Ozzy47]

I understand that you’ve not supported older versions, but now is seems according to your statement that worrying about backwards compatibility isn’t acceptable. So it leaves us remaining third party developers to make a choice.

 

[Suzanne O]

That sounds like an whole lot of coding work.

 

[Chris D]

I understand that you’ve not supported older versions, but now is seems according to your statement that worrying about backwards compatibility isn’t acceptable. So it leaves us remaining third party developers to make a choice.

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.

But the choice is still ultimately up to you. We’re just not necessarily going to be implementing additional checks and code to cater for it.

 

[JustinHawk]

@Chris D are their any plans on including html compression too ?

Basically something like this, that this add-on is performing: https://xenforo.com/community/resources/nobita-minify-html.4541/

 

[Chris D]

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

 

[AndrewSimm]

It's mentioned here and in several other threads: https://xenforo.com/community/threads/a-first-look-at-xenforo-2-3.216641/



XF 2 styles will not work in XF 3.

I was referring to styles. I was referring to the php code and database. Refactoring styles is easy stuff.

 

[mjda]

@Chris D are their any plans on including html compression too ?

Basically something like this, that this add-on is performing: https://xenforo.com/community/resources/nobita-minify-html.4541/

I'd agree with this. I wrote an add-on on a previous XF version that would remove all blank lines and turn multiple spaces/returns into a single space. I had it coded to do it on template build so it was saved in the actual template php files so that there was no performance hits on each page load to do it. It saved quite a few Kb per page.

Now that I think about it, it might've been @Chris D who talked me out of re-writing and/or using it.

 

[Suzanne O]

Really happy with what i've seen on here so far.

 

[Paul B]

I was referring to styles. I was referring to the php code and database. Refactoring styles is easy stuff.

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