When it comes to WordPress sites, not all of them can be treated the same in terms of what works best for performance. A simple five-page WordPress site behaves completely different than say a large WooCommerce site (which can be very demanding). WordPress membership and community sites are another type that falls into what we sometimes call this “tricky” category. If not setup or configured correctly, you’ll soon find yourself in a nightmare of 500 errors, downtime, and slow page loads. But that doesn’t mean you don’t have options, you just need to follow some best practices.
Today we’ll explore some of the do’s and don’ts for WordPress membership sites and how to best optimize them to ensure optimal performance, scalability, and longevity. 🚀
Here are just a few examples of some common WordPress membership and community sites:
Before we jump into the do’s and don’ts, let’s dive into a few reasons why WordPress membership sites are different than your standard blog or small business website.
First of all, membership sites contain a lot of uncacheable content and pages that are continuously changing. Things such as the login page for community members (which could be getting hit constantly depending on the size of the site), checkout pages for digital goods or courses, and discussion boards are common culprits and pain points, as these cannot typically be cached.
However, it doesn’t end there. On standard WordPress sites, the WordPress dashboard is also not cached for “logged-in” users. This is fine when you have just a few authors and admins, but when you suddenly have thousands of members using the dashboard, this immediately causes performance issues as none of it can serve from the cache on the server. This means you need the power and architecture behind the scenes to back it up. Shared hosting providers will usually cripple under these circumstances.
In the MyKinsta analytics tool that we provide for hosting clients, you can see just how much cache is being bypassed. Below is an example of a site where a large majority of the requests aren’t serving from cache.
The second problem membership sites typically have is a large number of concurrent visitors and sessions. On an informational or corporate WordPress site, a visitor might stay for five or 10 minutes until they find what they need (and this is a high number, usually bounce rates are much higher). On membership sites, you have the opposite happening. Visitors typically come to the site to engage with something or someone. If they’re going through an online course it’s not unusual for them to stay for hours. You can see where this is going. The concurrent visitors connected to your WordPress host adds up fast.
To make it worse, you then have a large number of concurrent visitors on top of the “uncacheable content” problem.
Third, membership sites usually generate more complex queries, which in turn adds additional latency in retrieving the information from the MySQL database. A lot of this is simply due to all the additional moving parts and large amounts of data sites like these have. This might also be caused by sites that heavily rely on search queries for navigation or use
Not to mention, you also have large amounts of concurrent users continuously querying the database.
It’s not really surprising, but membership sites store a lot of data and if not managed properly (which we’ll go into further below), your disk space can quickly run away from you. This also compounds over the lifetime of the site. Videos, courses, membership and profile information, discussions, digital downloads, etc. These are all just a few of the many different types of content which add up fast.
We host a lot of membership sites at Kinsta and our engineers are constantly interacting with these site owners on a daily basis. While we always encourage users to implement best web performance practices, these typically aren’t enough when it comes to these types of sites. So today we’ll show you a few ways to go the extra mile to ensure your membership site and its visitors have the best experience as possible.
Advice to choose a better WordPress host might seem like a broken record at this point, but the truth of it is, a lot of performance issues with membership sites can be traced back to this as the root cause. We’ve seen time and time again clients migrate to Kinsta from other providers and immediately see drastic improvements. Our entire company, from the infrastructure we place behind your sites, to the engineers we hire, are performance-focused. This has and will not ever change.
— Neuralab (@Neuralab) July 22, 2017
Kinsta was the first managed WordPress host to exclusively utilize Google Cloud Platform. We offer 17 different data centers around the globe, which means you can choose one closest to your visitors to decrease latency and TTFB. While other hosts might use Google’s standard tier network (cheaper and slower), we utilize Google’s premium tier network. This is designed to minimize distance and hops, resulting in faster more secure global transport of your data.
Our hosting platform doesn’t fall into any of the traditional hosting categories, and is very different from traditional shared, VPS, or dedicated infrastructure. Kinsta utilizes LXD managed hosts and orchestrated LXC software containers for each site. What this means is that every WordPress membership site is housed in its own isolated container, which has all of the software resources required to run it (Linux, Nginx, PHP, MySQL). The resources are 100% private and are not shared with anyone else or even your own sites.
Every membership site can also take advantage of auto-scaling to better handle sudden surges in traffic and load. Hardware resources (CPU/RAM) are allocated to each site container automatically by our virtual machines on an as-needed basis. This allows you to grow your WordPress membership site without having to worry about the common restraints and hard limits that other hosting providers enforce.
Read more about how Kinsta is different.
We can’t stress enough just how important it is to use one of the latest versions of PHP, preferably PHP 7.2. For many sites, this doesn’t require any work and is a free and instant boost to performance!
PHP 5.6 is no longer actively supported and is quickly approaching its official end of life (EOL) come December 2018, at which point it will stop receiving any future security updates. We recently published our PHP performance benchmarks in which we tested PHP 5.6, 7.0, 7.1, 7.2, and HHVM. As you can see below, on a WooCommerce site, PHP 7.2 takes the cake for the fastest performance! 🍰
We also tested Easy Digital Downloads and again PHP 7.2 outperformed everything else. If you compare PHP 7.2 to PHP 5.6, it can handle 3x as many requests (transactions) per second.
If your current WordPress host doesn’t support PHP 7 or higher, perhaps it’s time to look for a new host. Kinsta has offered PHP 7.2 since December 2017, as well as all the other major versions. You can easily toggle between them in the MyKinsta dashboard with a single-click.
If your membership site has compatibility issues with the latest version of PHP, then it’s probably time to ask the plugin or theme developer why they’re lagging behind or hire your own WordPress developer to fix the issue. You don’t want to pass up on the performance improvements from PHP 7 and higher.
Caching makes websites faster and reduces the load on the web server. Whether you’re using a caching plugin or a managed host like Kinsta that has server-level (page) caching implemented, this is something you should already be doing. However, when it comes to WordPress membership sites, your common caching setups are usually not enough as they don’t always take full advantage of it. This is where object caching comes into play.
Object cache stores the results of database queries so that the next time that particular bit of data is needed it can be delivered from cache without querying the database. This speeds up PHP execution times and reduces the load on your database. This becomes extremely important with membership sites! With WordPress, you can implement object caching in a couple of different ways:
We offer Redis as an add-on at Kinsta so you can take full advantage of persistent object caching for your membership sites. The great news is, once it’s configured you can still use the Clear Cache option added to your website admin area by the Kinsta Cache plugin. This button will clear both our page cache and any object caching active on the site.
In some cases, we can also cache a specific page or URL for logged-in users. However, you will need to first chat with our support team about this as it’s important you understand all of the ramifications of enabling this.
As a membership site grows, you’ll probably discover the standard WordPress search functionality isn’t going to be enough. Sites that heavily make use of WP_Query, use search as their primary means of navigation, or even a site with a large number of posts might run into performance issues, as search query times start to pile up. This is where a search engine such as Elasticsearch can help.
Elasticsearch can be used to speed up querying of the WordPress database. This is done by building an index of the content of your site’s database and then using Elasticsearch to search this index much more quickly than a MySQL query is capable of performing the same search.
We offer Elasticsearch as an add-on at Kinsta. Our engineers install it on the same server as your PHP environment and MySQL database which helps to decreases latency as opposed to hosting it in a separate instance or using hosted Elasticsearch.
We’ve seen first-hand that membership sites typically generate a lot of 404 errors. Your site is probably generating more than you think! Our MyKinsta analytics tool can help you determine the exact amount (as seen below).
You can also check 404 errors in Google Search Console or install a third-party plugin such as Redirection which logs 404 errors. However, remember that plugins like these also have an impact on performance. It’s much better to rely on a server-level tool.
The reason these errors are bad is that many 404 pages are very resource intensive. For a membership site, you’ll want to avoid a heavy 404 page. Create a simple 404 template that avoids querying the database any further if possible. And of course, spend some time and fix the 404 errors as this is not only resource intensive, it’s simply bad for the user experience.
PHP workers might be a term you’ve never heard of, but they are how many hosts, including Kinsta, handle limiting requests (rather than limiting you by CPU or RAM, which is typically what shared hosting providers do).
PHP workers determine how many simultaneous requests your site can handle at a given time. To put it simply, each uncached request for your website is handled by a PHP Worker. For example, if you have 4 requests that come to your site at the exact same time and your site has 2 PHP workers, two of those requests will get processed while the other two will have to wait in the queue until the first two have finished processing.
Remember we discussed earlier that one of the biggest problems with WordPress membership sites is all of those uncached requests. This is why PHP workers become very important as they have to do work for each request. Therefore, these sites will typically require additional PHP workers to ensure every request is processed without delays and completed successfully.
What happens if you continuously max out your PHP workers? Basically, the queue starts to push out older requests which could result in 500 errors on your site. Each of Kinsta’s hosting plans includes a predefined number of PHP workers. If you have trouble estimating what your site might need, you can always chat with our sales or support team.
Regular database maintenance isn’t just recommended for WordPress membership sites, it’s required! If you don’t do this, one day you’ll probably be wondering why your site has come to a crawl. Here are some recommendations:
Autoloaded data is data that is loaded on every page of your WordPress site. This data is stored in your in your
wp_options table. On large sites, this table can quickly grow out of control. Check out our in-depth tutorial on how to clean up autoloaded data.
Just like with autoloaded data, you should also regularly clean up transients. When working properly transients are supposed to expire and remove themselves, but this isn’t always the case. If something is misconfigured or even corrupt these can begin to really stack up.
For example, we had a client where something went wrong with transients expiring and it brought the entire site to a crawl. After digging into it, we discovered the site had 695,846 transient records (rows) in the database. Upon deleting the rows (which contained transients which should have already expired), the site immediately recovered (as seen below).
You can use the free Transients Manager plugin to view, search, edit, and delete transients on your WordPress site.
CRON jobs (WP-Cron), used to schedule repetitive tasks for your WordPress site, can also have similar issues. You can use the free WP Control plugin to check and make sure your CRON jobs aren’t getting out of control.
Last but not least, you should move your database engine to InnoDB if you haven’t already. A lot of older sites are still using the MyISAM storage engine in their database. Over the recent years, InnoDB has shown to perform better and be more reliable. A big reason to use InnoDB over MyISAM, is that you won’t run into issues with full table-level locking. This allows your queries to process faster.
Check out our tutorial on how to convert your database (tables) from MyISAM to InnoDB. If you migrate to Kinsta and have our engineering team assist you, we automatically move your database engine to InnoDB.
As we mentioned earlier, membership sites simply have a ton of data! Videos, PDFs, full-resolution photographs, documents, and audio files tend to be the biggest culprits. Therefore, you might need to figure out a way to offload this to a cheaper storage solution. This can save you money by simply having to upgrade your hosting plan. Check out the following articles:
Here are a few things you shouldn’t do on your WordPress membership sites.
Never add view/post counters to your site if you don’t have to. For example, avoid things like “792 posts” next to a user’s avatar in forum posts or “5,243 views” when listing forum posts. When you have a long discussion these counters will take a huge toll on your database. In general, minimize the use of counters and only use them if necessary.
This also goes for social counters. Notice that we do use these on the Kinsta blog, but nowhere else on our site. But our plugin also has caching built-in, this ensures they aren’t generating queries on each page load.
Page builders are great for a lot of folks, in fact, we even have an entire list of ones you can use on your site. However, most (not all) of these have performance implications as they generate additional unnecessary code to make the page render in the way that user can still build it without knowing how to code. If you can, code your page templates by hand and always make them as light as possible.
For example, our Kinsta website (as seen below) is in WordPress, but the entire theme is actually coded by our in-house developer. This helps us reduce some of the bloat that large WordPress themes typically have but allows us to still take advantage of all the amazing functionality. Again, there are thousands of talented WordPress developers and designers out there at your disposal if you need help.
We know you’ve heard this before. The truth is, the quality of a plugin’s code is more important than the total number of plugins you have installed. However, with that being said, each one is still going to have a “performance cost.” 🐢 If you’re no longer using features from plugins, deactivate and remove them from your site. Not only does this make troubleshooting things easier, but it will most likely decrease the number of queries on your site (both on the backend and frontend).
There are a lot of third-party CRM and automation platforms out there that you might want to integrate with your WordPress membership site. However, be careful with these as some may introduce additional latency and delays while communicating with their APIs, services, etc. You might want to look at solutions built inside of WordPress, such as these CRM solutions.
Not to make it more difficult, but the opposite could also be true. If a third-party CRM or automation platform is handling a lot of its own tasks, it could in fact help take the load off of your WordPress host. The best way to know for sure is to test different solutions.
And of course, we can’t let you leave without mentioning some of the more common speed optimizations you should already be doing:
WordPress membership and community sites are definitely in their own category when it comes to optimization. They usually require going the extra mile if you want to see excellent performance. But the great news is, many of the solutions out there can do wonders. PHP 7, Elasticsearch, and Redis Object Caching are all easy and effective ways to see instant results. And of course, having a performance-focused host should always be at the top of your list. 😉
Do you run a WordPress membership site? We would love to hear your thoughts or struggles you’ve encountered along the way.
Send this to a friend