Optimising the Performance of your BuddyPress Social Network
Why is Performance Important
The load time for your page will ultimately determine how many people visit and more importantly return to your site. If people find your site to be slow then they will look for alternatives.
How can you tell how your site performs
There are a number of websites that will test the performance of your site. One I prefer is GTMetrix, this site provides you with a range of different performance reports and provides recommendations as to what to do to increase the performance of your site.
What slows down your site?
One of that main factors that affects the performance of a BuddyPress Social Network is the amount of plugins that are loaded onto the site. Often each plugin generates a database lookup during page load and this inevitably takes time and processing effort from your host. The pluguns that seem to have the most overall impact include BuddyPress, bbPress and any Media Plugins you may have, these greatly add to the complexity of the site and therefore page load times.
Another factor is the overall load on your host – how many users are simultaneously logged in and active, this has greater bearing depending on what type of host you have, be it on a shared platform or a dedicated system. It is incredibly difficult to estimate reasonably useful usage limits on differing types of hosts because this is dependent on average load per user and that in turn depends to a large part on the nature of the site and there interaction with the site.
As a rule of thumb I suggest you think of a shared platform as being good for maybe up to 50 simultaneous users and most entry level dedicated servers should be good for 150+.
If there are a lot of images in the page then fetching all of these will take time.
Traditional methods of Improving Website Performance
Improving performance on most websites comes down to two things; efficiency of code – only fetching data that is actually required, and Optimising host functions and Offloading – Caching and CDN’s.
In the world of WordPress we have to rely on a bevy of independent, often unpaid developers by way of the plugins that are used together with a pit of self coding. Also, the types of data involved have some bearing on the situation – Images can be rightsized and compressed.
Typically websites use Page Caching to reduce database look-ups, speeding up page load times for static pages, this concept of serving a copy of the database look up can also be extended onto the Net using Content Distribution Networks. With CDN’s the concept it to move your data as close as possible to the user thus minimising network latency as well as load on the host server.
Improving BuddyPress Performance
Unfortunately the nature of BuddyPress means that many of the traditional methods of improving performance are less effective; BuddyPress uses dynamic pages that serve different content to different users, this rules out Page Caching as an option and means caching in general is problematic with BuddyPress.
There is some hope in the form of object caching, however my understanding is that while this will improve the WordPress side of things for BuddyPress it is less effective. One solution that has been requested is for Fragment Caching to be enabled in BuddyPress Core but so far this has not happened. Fragment caching would cache the static fragments of a page such as the header image etc.
How well caching will improve your site performance is also dependent on the mix of static pages that are being served to those that are dynamic BuddyPress pages. If your site has a lot of static blog pages then Caching and Content Distribution will certainly benefit these pages.
In a BuddyPress network ensuring efficiency of code comes down to using the minimum number of well written plugins and seeking where possible to make minor site modification without using plugins but instead using code snippets etc. The larger you site the more you will think about authoring your own efficient code specific for your site but clearly this is a large overhead. You can also get code efficiency plugins called Minifyers.
Performance Improvements List
Are you using well written plugins?
That’s a difficult one since often there is no choice and how do you know? One way is to check out your GTMetrix stats in order to see what calls are being made to your database and elsewhere and to match these to individual plugins, this is easier for some than for others but another option would be to perform a plugin by plugin analysis of impact on page load times on a test server.
If you must use some plugins that are making excessive calls, here is some information on what you might do.
Can you offload some functions externally?
A good example of this is chat, some chat plugins use your own server, others use a separate dedicated server and therefore have less load on your host system
Are you running the minimum possible number of plugins?
This is difficult for most BP sites as often a range of plugins are deployed on many aspects of the site in order to create the optimum social networking site however deep thought should be given to each and every one to see if your network really needs it.
Compressing images – GZip Ninja Speed Compression
For Apache servers only, will compress images inline to reduce image transfer times.
Minifying Code – Better WordPress Minfy
Better WordPress combines, minifies and caches inline Javascript files and CSS files on demand to speed up page loads.
Object Caching – XCache
XCache is one solution for Object Caching on your WordPress/BuddyPress system.
Database Optimisation – WP Sweep
WP Sweep will clean out redundant data in your database, it will also optimise the database tables. WP Sweep creates a Dashboard>>Tools>>Sweep page, from here you can choose to sweep individual database elements or all. Don’t forget to back up your database before you perform a sweep.
It is also worth going into your database and deleting unused items, these can really slow down DB lookup time, there’s a helpful guide on WPMU DEV.
Disabling unnecessary plugins on specific pages
Plugins typically load on every page for your site, even if they are not needed. One way to strop this behaviour is to use Plugin Organizer to set up rules on specific pages as to which plugins should be loaded. This is pretty cumbersome though and you might decide to do this on select pages such as your home page.
Conclusion
This article has covered the basics of trying to get to grips with the performance of your BuddyPress Social Network, I already think I need to revisit it in order to expand on some of the points, maybe later.
Note: W3 Total Cache is not recommended for BuddyPress sites at present, apart from the issues with page caching, there is a bug that seemingly can’t be fixed whereby users trying to change their passwords get locked out of the site. It is possible to use W3 Cache, but you can only enable the Object Cache as both Page Caching and Minify have been shown to throw errors with BuddyPress sites.
3 Comments
Collins · April 4, 2017 at 10:34 am
Thanks so much for this… I feel so discouraged.. Been trying to make my buddypress site better at speed but some users complain of lag.. Don’t know what to do 🙁 tried this already. Can you help check to see?
Venutius · April 5, 2017 at 5:21 pm
There’s a lot of things that can affect performance, one is your hosting supplier, many standard hosting solutions do not perform very well once you have BuddyPress loaded. Another aspect I’ve found is the structure of your database. Many people develop their site offline or on a dummy host then migrate that site to the production site. This sometimes results in bloated databases, with entries for plugins that never worked, you may have deleted the plugin but did it remove all of it’s database entries?
James · April 7, 2017 at 9:28 am
Hi,
Great article, thank you. I had been using wp super cache and had no idea it would cause a load of buddypress issues i found a couple of days ago.
I have already reduced the number of plugins, minify with Autoptomize, and use Plugin organiser for the homepages on my multisite.
I will look into object caching and cleaning up my database because i still need to ‘reduce server response time’ according to Google.