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!

 

[Dannymh]

How will 2.3 effect add-ons will there be significant changes beyond the JavaScript that need to be changed?

 

[Jeremy P]

Not really.

 

[Wildcat Media]

There may be minor template issues but it's not a huge, drastic change as it will be going between major versions (like 1.x to 2.x was). I had some 2.1 addons work perfectly fine with 2.2, and others just needed minor changes.

 

[Alpha1]

I think that it would be really nice if we could see the GTMetrix performance reports for xenforo.com on XF2.2 VS XF2.3
For pages like
Forum index: https://xenforo.com/community/
Forum view: https://xenforo.com/community/forums/have-you-seen/
Thread: https://xenforo.com/community/threads/boosting-performance-in-xenforo-2-3.216767/
Media index: https://xenforo.com/community/media/
Media entry: https://xenforo.com/community/media/8p.4806/
Resource index: https://xenforo.com/community/resources/
Resource Entry: https://xenforo.com/community/resources/post-friction.6693/

It would be very interesting to see what difference it will make here on xenforo.com

 

[digitalpoint]

You can get XF 2.2 to 100% performance and structure on GT without too much trouble, but 2.3 will be even faster, so great!

GTmetrix Performance Report

GTmetrix Grade: A (Performance: 100% / Structure: 100%)

gtmetrix.com

 

[Alpha1]

Yes, the performance enhancements are exciting.

 

[Paul B]

I had to double check you weren't one of those spammers for a second ...

 

[Ivancas]

You can get XF 2.2 to 100% performance and structure on GT without too much trouble

Even XF community can't do it 100%. How do you do it?

 

[Forsaken]

Even XF community can't do it 100%. How do you do it?

XF community is just standard XF without much adjustments (or any really).

 

[Kirby]

Improved CSS performance with HTTP/2+​

[...]

CSS specific to individual templates or pages will now be requested separately, rather than bundled together.

[...]

By making these requests individually and unbundling the CSS from others, this allows the individual templates to be cached and reused more effectively across different pages.

Admins often add (a large amount) custom CSS to extra.less which is loaded on every page and thus somewhat defeats the goal to debundle stylesheets and have them loaded / applied only when necessary.

Making it easier for admins to add custom CSS /LESS via extra.less while having it only loaded / applied when necessary would IMHO support these efforts nicely.

Better extra.less

When admins add custom CSS, they often do this via extra.less. This is easy and convenient (everything is in one place and not scattered over dozens of templates and there are no outdated templates / merge conflicts on upgrades) - but it is not efficient if a lot of CSS is added as all rules...

xenforo.com

 

[whynot]

You can get XF 2.2 to 100% performance and structure on GT without too much trouble, but 2.3 will be even faster, so great!

Wow!
(Maybe 101%)

 

[Ivancas]

In XenForo 2.3 we have developed a brand new way of subsetting Font Awesome icons so that only the icons which are actually used across your XenForo installation are ever served to your users and, even better, it's entirely automatic!

Will users be able to use font awesome icons across bbcode?

 

[James]

Will users be able to use font awesome icons across bbcode?

This is possible to create not sure if it's default though.

XF 2.2 - Using Font Awesome within editor and posts?

Is there a method to allow usage of font awesome icons within editor/posts? So that users can easily insert font awesome icons into their posts. There appears to be an addon @ https://xenforo.com/community/resources/foro-agency-fontawesome-bbcode.6135/ but I'm unable to reach the authors website

xenforo.com

 

[Alpha1]

XF2.3 performance ATM:

https://gtmetrix.com/reports/xenforo.com/eeyHqwSQ/

This is just one page. Other pages will differ.

 

[briansol]

https://www.webpagetest.org/result/231130_BiDc3W_G0C/?view=webvitals

results of the 2.3 feedback thread

:bronod:

 

[digitalpoint]

Any reason the FontAwesome SVG images aren't being compressed into SVGZ images? It's literally just gzipping the .SVG file and giving it .svgz extension.

Being that SVG is text, compressing them actually gives a fairly substantial savings in size (usually a 3:1 or 4:1 ratio).

 

[Jeremy P]

I'm personally of the opinion that's a job better suited to the web server, same as other text-based static content, which also better facilitates support for other compression algos. If you check here for example, they are compressed in transit (by nginx).

 

[thedude]

Since the SVG is essentially static and not expected to change, it would seem more efficient to have it be compressed once and be done with it vs leaving it up to the web server to handle the compression. My 2 cents

 

[digitalpoint]

I'm personally of the opinion that's a job better suited to the web server, same as other text-based static content, which also better facilitates support for other compression algos. If you check here for example, they are compressed in transit (by nginx).

Not sure I agree… although you end up with compression over the wire either way, compressing the same thing over and over (every request) just adds to server load. It’s unavoidable for dynamic pages like HTML, but for static files (especially an image format that supports it simply by using a different extension), it doesn’t make a whole lot of sense. Disk storage space is more, the CPU cycles to compress the same thing over and over for every page request is needlessly using server resources and also (slightly) slowing down the request since it first needs to compress it every request.

Say you had 200 SVG images that each got served 10,000,000 times in a year… the CPU cycles to compress the 200 images once vs doing the same 2,000,000,000 times on the fly just seems like a waste to me.

 

[Jeremy P]

The same could be said for the JS files I guess, but I'm not sure the overhead is big enough to justify the reduced flexibility (brotli support, etc). With proper expires headers they shouldn't be requested too frequently, and static content is increasingly served on the edge by providers like Cloudflare as well.

Ideally web servers could just be configured to cache compressed files to disk, but of course that's not typically the case. I guess it's something to consider.