Scalable WordPress hosting for a learning management system website on your mind?
Discover what makes WordPress LMS hosting work at scale for when your LMS website gets lots of traffic and concurrent users.
We are thrilled to bring you this long-format, educational piece supplied by one of our industry peers at Memberhost.
Vic Dorfman consolidates the elements of site performance and hosting into one power-packed piece… an “all in one” to get you on the right path to scaling your Learning Management Website.
Table of contents
- Introduction to Scalable WordPress Hosting
- What got you here won’t get you there
- What makes LifterLMS unique?
- WordPress or Scalable WordPress Hosting Server?
- Infrastructure (or, types of hosting)
- Scalable WordPress Hosting Support
- Optimizing your Scalable WordPress Hosting Environment + Application
- Conclusion
- About the Author
Introduction to Scalable WordPress Hosting
Back when you first started your eLearning site you probably didn’t give too much thought to things like performance and load times.
Sure, you may have agonized a bit over which hosting provider to use or tried to keep your site on a plugin diet.
But on the whole, you probably had bigger fish to fry—like servicing your founding members, getting your revenue up, hiring help, and all the usual entrepreneurial growing pains.
Fast forward to today.
Your site has grown into a solid business and some of the considerations that were sitting on the backburner are now starting to become more pressing.
Performance—especially performance as you scale—is one of those considerations.
And it tends not to be a massive problem, until it is.
So let’s talk about how you can keep your website performance at a high level as you scale your business.
Vic Dorfman, MemberHost.io Cofounder
While this won’t be an exhaustive treatment of scalable WordPress hosting, you’re going to learn some insider gold nuggets that you probably haven’t heard before. 🙂
But first, let’s zoom out and look at the big picture for a second.
What got you here won’t get you there
It’s important to understand how the hosting and performance landscape changes once your site gets ‘big’ enough.
“Big” meaning:
- You’re growing the number of members/learners significantly (in the thousands+)
- You have a high level of engagement on your site (course activity, community interaction, gamification, etc.)
- You have an influx of large quantities of traffic and/or big traffic spikes
- You’ve accumulated a large codebase (i.e. lots of heavy plugins and/or custom code)
Once you’re at this level you’re probably already paying hundreds, or thousands of dollars per month for hosting, yet your site performance is still subpar.
You may have even switched hosting providers once or twice, or hired help to optimize site speed, with ultimately underwhelming results.
The reason you can’t seem to move the needle is that what got you here won’t get you there.
Cliche performance optimizations like, “optimize your images” from a random freelancer just won’t cut it for a heavy WordPress site with dynamic content and hundreds, thousands, or tens of thousands of members logging in and interacting with the site concurrently.
And while they’d gargle paint thinner before ever admitting it, most of the popular hosting providers have neither the hardware nor the deep WordPress-level expertise to handle a site like yours.
What makes LifterLMS unique?
There are a few things that make a plugin like LifterLMS a unique member of your tech stack.
1 – It’s a “transactionally heavy” plugin; a large piece of code with:
- Lots of PHP files
- Action hooks and filters
- Database read/writes
…(which happens for almost every single page view you generate).
2 – Page caching is impossible or of limited benefit
Most pages are going to contain dynamic content that we simply cannot cache (via a static page cache) across users.
Thus every page visited by every user is generated from scratch.
This is not unique to LifterLMS per se; this impacts any membership or dynamic content-type plugin.
(Nor is it a bad thing; it’s just what’s generally required to deliver this kind of content / experience at a high level.)
These considerations are compounded by the fact that:
3 – LifterLMS rarely exists on a site by itself.
There are almost always some other, fairly heavy plugins active, such as:
- Shopping cart (WooCommerce, SureCart, StudioCart, etc.)
- Gamification (GamiPress, MyCred, BadgeOS, etc.)
- Membership plugin (Paid Memberships Pro, MemberPress, Memberium, WPFusion, etc.)
- Community / forum (BuddyPress, bbpress, BuddyBoss, etc.)
…and most of those are heavy workloads in-and-of themselves.
So a reasonable expectation to have is that optimizing for performance at this stage of growth is going to be more complex and more expensive.
WordPress or Scalable WordPress Hosting Server?
There are two basic “places” where you perform optimizations: in WordPress and on the server.
However, they both depend on each other, and if not configured properly they can represent bottlenecks to each other.
A great example of this is implementing OPCache, which is one of my favorite and most powerful optimizations.
Assuming it’s available on your server, you can’t just turn it on and call it a day.
You have to optimize it for WordPress by investigating utilization statistics via a OPCache plugin (or other server-side method for inspecting memory usage).
Not only that, you have to know how to configure it so that it actually gets you a noticeable result.
In short, you have to know how to optimize a WordPress application holistically in concert with the server.
CPU speeds
Remember that time you asked your hosting provider about the CPU speed of your server?
No, neither does anybody else (except maybe me).
And heck, even if you did, there’s a pretty good chance they either wouldn’t know or wouldn’t tell you.
CPU speed, however, is one of the main determining factors for how well your site performs.
In fact, if your server’s CPU speed is subpar, there’s really not a whole lot you’re going to be able to do past a certain point to speed things up.
Even scaling the number of cores on your server isn’t going to make any difference if CPU speed itself is your bottleneck.
However, note that CPU speed alone doesn’t ALWAYS indicate that a CPU will be more performant.
For example, 3.2 GHz processors from Intel outperform their older generation 3.7GHz processors in the same product line.
But all things being equal you want the fastest CPUs available because they produce:
- Faster dynamic frontend page load times
- Faster wp-admin
Faster CPU not only improves the experience for each individual page request, but since the requests finish faster it can also improve concurrency (performance under load from multiple visitors) and allow you to get more mileage out of your infrastructure before needing to scale to more processors.
PHP Workers for Scalable WordPress Hosting
Another critical aspect of WordPress performance is the number of PHP workers available to you.
PHP workers are the processes within your web server that handle all of the functionality that gets offloaded to PHP (i.e. the programming language that WordPress is built on).
For instance:
Loading an image or CSS file? It goes through your web server.
Loading wp-admin? Web server sends request through the PHP worker and then delivers the result.
Most hosting providers place strict limits on these, which limits your processing capability.
A greater number of cores + more PHP workers gives you more processing channels to handle each request.
The analogy we like to use is checkout lanes in a supermarket.
CPU speed = how fast the teller checks you out.
PHP workers = number of checkout lanes available.
For performance at scale you really need both.
In fact, this is the most important factor for optimizing what we call “concurrency”, which in layman’s terms is the ability to handle a large number of users all interacting with your application at the same time.
This is exactly what happens on an eLearning / membership site, and thus why page load times aren’t the ‘end all be all’ of performance.
It’s important to note that you can’t increase PHP workers or the number of CPU cores in isolation; they have to be configured together and sometimes optimized specifically for a particular workload.
(You may have had the experience of upgrading your hosting to a higher tier with more CPU cores without getting much of a performance boost, despite paying double or more. Low CPU speeds and PHP worker limits explain this frustrating phenomenon to a large degree).
However, CPU metrics can be the trickiest info to get from a hosting provider.
Most providers are intentionally vague about these numbers.
That’s generally because they’re not proud of them.
Anyone knowing enough to ask is often going to be disappointed by the answer.
How can we find out that info?
Start by checking pricing pages and asking support (and insist on a non-fluffy answer if you have to).
You’ll want a CPU speed of at least 3 GHz for a dynamic workload like LifterLMS.
Codebase Hygiene
While we usually think of our site as “a WordPress” site, I prefer to use the term “application”.
That’s because what we’re building with LifterLMS is often more than just a website.
It is, in a way, a custom web application / platform.
The less code (plugins & scripts) we run, the less processor time we’ll eat up (in general).
Likewise, the more efficient the code, the less processor time we’ll eat up.
External API calls, especially in cases where rate-limiting exists, can cause performance failures.
(For example, WP Fusion ➝ Hubspot has a 100 requests per 10 seconds limit).
But I get it, if your site is a serious business you’ll need the plugins that you’ll need.
And while you definitely want to watch out for unnecessary plugins or ones that gobble huge amounts of resources, you can only get so lean.
Tools like Code Profiler Pro and Query Monitor are invaluable in assessing whether or not certain plugins are performance hogs, and might need to be replaced.
Server Distance
If possible, choose a physical server location near your audience’s predominant geographic location, if one exists to maximize scalable WordPress hosting.
e.g. if your customers are in Australia, you’ll definitely want your server to be in Australia (and this applies especially to Australia).
Sometimes, however, a highly performant scalable WordPress hosting server that’s not located in your target geography will outperform a local option with less horsepower.
Caching
Caching is a big topic but we’ll try to keep it simple.
For eLearning and membership sites, caching needs to be done somewhat surgically.
Page caching, for instance, doesn’t offer much benefit except for static marketing pages.
It’s not a bad idea to have it activated for those key pages, but will not help with LifterLMS itself.
Also, most of the popular page caching plugins are more or less useless, unless your host doesn’t support page caching.
These include:
- WP Rocket
- Breeze
- Cache Enabler
Installing and activating these plugins will not make up for a fundamental performance deficiency on the hosting level.
And for sites with protected content like LifterLMS-based sites, they’re largely unnecessary.
Infrastructure (or, types of hosting)
I want to briefly touch on some of the major types of hosting.
Keep in mind that the lines are VERY blurred these days; most providers offer more than one type of hosting, but we’re going to represent the major buckets providers tend to fall into.
Shared Hosting
In a shared hosting scenario, multiple websites share a single server and its resources, e.g. CPU, RAM, and disk space.
All of the sites also run on the same web and database server.
Shared hosting is usually the cheapest option.
But it’s also the most restrictive type when working with dynamic applications like LifterLMS.
Issues include:
- can’t configure server customizations
- may not be optimized fully for WP
- artificial limits are placed on many resources such as PHP workers or inodes
- usually a very large, very slow CPU
- tends to be oversold, similar to overselling an airplane (too many customers stuffed into too few seats)
The main takeaway here is that shared hosting is only suitable for proof-of-concept; anything serious will struggle to run well.
Examples of popular shared hosting providers include Bluehost, GoDaddy, HostGator, SiteGround, and anything running CPanel or Plesk.
VPS
The way a Virtual Private Server, or VPS works is that the hosting provider partitions a single physical server into multiple virtual servers, each with its own dedicated resources.
This type of hosting is more expensive than shared hosting but offers more control and flexibility.
It also isolates the environment a little more than shared hosting, which is good for security and mitigating “noisy neighbors” (i.e. other sites on the same server that consume a disproportionate amount of resources).
Resource utilization is more fairly distributed in a VPS so there are less problems with overselling.
A VPS usually needs to be paired with a control panel (GridPane, Runcloud, SpinupWP).
Popular VPS providers include Cloudways, Digital Ocean, Linode, and Vultr.
VPSs are a good mix of price and performance but not a good solution if you don’t know what you’re doing, as you’ll need tech chops to provision and maintain your server.
Dedicated server
A dedicated server means you get an entire physical server to yourself, with all its resources dedicated solely to your website(s).
It’s a more expensive option than shared and VPS hosting, but offers the highest level of control and performance.
Like a VPS, a dedicated server will also require a control panel.
Examples of dedicated servers include OVH and LiquidWeb.
Key Takeaway: Great performance, but requires server admin experience.
Cloud hosting
Cloud hosting powers your website on a network of physical servers, virtual machines, or containers that work together to provide a scalable and reliable hosting environment.
This type of hosting is suitable for high-traffic websites or websites that require high availability and uptime.
Scalability depends on the scalable WordPress hosting provider’s configuration but most have strict limitations on provisioned resources.
What separates these from VPSs?
Mainly, it’s the ability of the provider to balance and migrate nodes, network multiple nodes together, etc.
Examples include WP Engine/Kinsta (higher tiers), Pantheon, Pagely, and MemberHost.
“Conclusion: For serious LifterLMS sites that do a good bit of traffic, you’ll probably want to look at a cloud hosting provider.”
Scalable WordPress Hosting Support
Performance is dependent on the infrastructure provider, but the full hosting experience depends a lot on the level of support as well.
If you’re running a serious eLearning site and you’re not a systems administrator, you’ll definitely want to consider the level of support your hosting provider offers.
There are a few main ways hosting companies do their support.
Infrastructure Only Support
Some hosting providers only provide the server and then you’re on your own.
You’ll get a basic hosting account with support for basic WP requirements.
It may not even include self-management tools or a control panel for WP.
You’ll also get no help customizing environments or troubleshooting issues.
Examples:
AWS, Google Cloud, Digital Ocean, Linode, Vultr
This is only really a suitable option if you have a dedicated systems admin on your team, and even then it can be more trouble than it’s worth.
For instance, we’ve had several people come to us with huge memberships where they’re paying $5k/mo+ for their AWS infrastructure, and another few grand for the AWS technician who administers it.
We get them down to about half of that, with no need for an overpriced sys admin, and measurably improved performance.
Many people assume that bigger company = better servers but that is absolutely not the case.
If anything, bigger company = lots of legacy baggage that’s too expensive to replace.
If you feel stuck with an expensive hosting provider, know that there are better-value options out there that are equally reliable.
Managed WordPress Support
“Managed” WordPress hosting is a bit of a fluffy term but it basically means that:
A) The server is better configured for WordPress from the start.
B) There’s some kind of baseline configuration that is dumbed down for all sites
C) Support is more well-versed in supporting WP-specific issues (this is a big plus)
D) Support will often offer basic assistance with WP troubleshooting (identifying issues in error logs, problems with firewall, helping make a configuration change)
E) They may not have the expertise for higher-levels of application-level support (e.g. support that really understands LifterLMS, WooCommerce, WPFusion, etc.)
F) They are focused on other areas of hosting with better economies of scale
Examples:
Kinsta, WP Engine, Rocket.net, Pantheon, MightyBox
Premium Managed Scalable WordPress Hosting Support
These scalable WordPress hosting providers tend to deliver deep application-level support and troubleshooting, e.g.:
A) Higher-tier support
B) Access to professionals who know WP inside and out
C) Domain-specific knowledge (like eLearning plugins, membership plugins, community, etc).
D) Done-for-you fixes for almost any issue you encounter
E) Proactive support (uptime monitoring, security/virus scanning and resolution, etc).
F) Ability to configure and manage horizontally-scaled deployments, clustered environments, etc.
Examples: Pagely, Pressidium, MemberHost
Optimizing your Scalable WordPress Hosting Environment + Application
OK so hopefully we’ve laid the foundation with solid hosting.
Now let’s talk about optimizing your hosting environment and the application itself.
Benchmarking
The first step in optimizing anything is measuring where we’re currently at.
In the performance world we call this process benchmarking.
Server benchmarking
First we start with server benchmarking.
Maybe you’ve chosen your host and want to make sure it stacks up.
Or you’re comparing a few hosts and want to understand the performance differences.
Whatever the case, there are a couple of tools we can use to evaluate performance issues.
1 – WP Benchmark
It’s easy to use and gives you a score for several important areas of server performance in a digestible format.
Reference the screenshot above.
We can see that CPU and database performance make a major impact on the overall performance of LifterLMS.
You don’t have to worry about the absolute numbers or what they mean, but you can easily compare relative performance of hosts.
With the high performance cloud setup we’re going to see better performance on single requests AND as we scale.
This plugin gives us a nice analysis of DB performance.
We ran the test pictured above a few times and were bumping all around that number.
We like to see the queries per second metric at 1500-2000 for maximum performance.
Again, you can see that there’s a huge difference in performance between Managed WordPress and High Performance Cloud.
Application benchmarking
Next let’s look at a few tools for measuring performance on the WordPress side.
My favorite tool for benchmarking performance on the WordPress side is Code Profiler Pro.
Code Profiler is a relatively unknown but excellent plugin that provides a quick analysis of your site.
It also works on any host.
CPC gives us a nice visual representation of each plugin’s load on a particular page request.
This can vary from page to page so you may need to run tests on several areas of your site, logged in vs logged out, etc.
But what it allows us to do is identify performance bottlenecks that are due to resource-hungry plugins.
Sometimes something like an innocent looking social sharing plugin can hijack your server resources because of the way it’s coded.
The pro version of Code Profile version also shows you performance metrics on:
- individual PHP scripts
- database queries
- file read/write operations
- remote API calls
In other words, this is a very useful and relatively inexpensive tool!
2 – Query Monitor
Query monitor will show us which functions from core, themes, plugins are hitting the database, e.g.:
- duplicate DB calls
- slow DB queries
Like Code Profiler Pro, this allows us to identify bottlenecks.
Load Testing
Load testing is where you simulate real user traffic to a site.
In the case of LifterLMS, we want to log users in and ideally proceed through a few lessons in a course and take a quiz.
At the end of the test we can see how long page loads took, how many requests failed, etc.
The way I like to do this is to send anticipated traffic loads through the site and see how our application performs.
Then we also send through ridiculous amounts of traffic until our application completely locks up.
We’re then able to adjust our infrastructure deployments to develop a “factor of safety” where we know we’ll be able to support 2, 3, 4x our anticipated traffic loads.
This gives us confidence that we can absorb unexpected traffic surges without completely overpowering/overpaying for compute resources.
While you’re probably not going to go through this process yourself, it’s important to be aware of it as it’s one of the main aspects of performance and often gets overlooked.
It’s also relevant for sites using a shopping cart like WooCommerce because if you’re sending paid traffic or have a post go viral on TikTok, you want to make sure that you’re able to support a large number of concurrent checkouts
Tools we use for Load Testing:
loader.io – be sure to visit a few dynamic pages for best representation
- Easy to use
- Relatively cheap
- Suitable for basic load tests
k6 – scripting language to extract variables, submit ajax requests, etc
- More complex but more robust
- Free open source version available
Plugin Audit
The next one will sound a little obvious to some, but if you have an active site or you’ve already started building a site, I can’t recommend enough that you take a second look at your plugins.
As we solve various functionality problems on our sites, we tend to look for the fastest, easiest fix.
But we don’t always consider the performance impact.
So it’s wise to occasionally review the Application Benchmark tool and look for plugins with long load times that may not have critical functionality.
Look for small plugins that simply install tracking scripts or chat widgets and hard code those or embed them into your theme settings if they don’t have other dynamic or backend functionality.
The plugin will have backend and frontend code execution and database queries that runs to determine when and where it should hook in and what it should do.
Also find large plugins where you’re only using a small amount of the functionality and see if there’s a reputable alternative that provides a more focused feature set for less workload.
Get plugins up to date
A lot of performance improvements and bug fixes are released in smaller point releases.
Develop a habit of updating at least monthly, if not weekly.
Or better yet, outsource it to a company that provides update-only Care Plans with regression testing.
Use good plugins
Generally you want to use plugins with good ratings, timely responses from the plugin author, and a large number of installs.
We want to avoid relying on small, completely unknown solutions whenever possible.
When selecting your LMS plugin, choose from the best WordPress LMS plugins.
True, every plugin starts somewhere, but these are less likely to get the attention they deserve.
Consider plugins with paid support
A plugin developer who’s being paid for his efforts is generally going to be more eager to respond to various issues.
They’ll also be faster to resolve or improve performance issues since they have direct financial interest in doing so.
The takeaway here is to be intentional about your plugin selection.
I don’t believe in limiting yourself to a particular number of plugins.
That’s a fool’s errand.
Sites with dozens of plugins run lightning quick and others with 4 or 5 plugins are painfully slow.
There may be a trend with more plugins and slower performance, but it’s not a “one size fits all” situation.
Caching
Caching needs to be done carefully on LifterLMS sites or you risk breaking functionality and causing weird issues.
Let’s look at some of the caching approaches we like to take that work well on these types of sites.
OPCache is a somewhat under-appreciated yet extremely powerful caching technology.
OPCache is enabled by default on most hosts.
In fact, it’s in their best interest for maximum performance.
However, it may or may not be activated in your specific case so talk to your host to ensure it’s working.
The key to getting the most out of OPcache is to configure it correctly on the WordPress side.
So let’s take a look at a case where it’s enabled but not at all configured properly.
If it’s not enabled, by the way, you won’t see any of these stats and will see an error message instead.
The configuration in the screenshot below is somewhat wimpy.
The memory is not full.
I would like to see it closer to 80 or 85% to have some additional overhead.
Hit rate: we want this to be as close to 100% as possible.
Object Caching (Redis or similar)
Another caching technology we like is Redis.
It allows us to make 1/10th of the database queries vs an unoptimized application.
And it cuts about 0.2s off page load times.
Just by activating a plugin and making sure server-side configuration is correct we get a nice performance boost… low hanging fruit!
To activate object cache, ask your host to activate Redis.
Then install https://wordpress.org/plugins/redis-cache/
The Object Cache Pro plugin is here: https://objectcache.pro/
And if you’re on a Litespeed server use: https://wordpress.org/plugins/litespeed-cache/
Database optimization
There are a few database optimization tools we like to work with as well.
This tool adds indexes and other performance optimizations to your database.
- This is a nice little tool that will show database optimization opportunities
- bypass the need for root access to configure MySQL to this degree
DNS / Reverse Proxy with CloudFlare
The #1 way to “reduce” distance to your users is by using a CDN.
For this purpose we generally use CloudFlare.
CloudFlare provides optimized request routing whether or not you use the caching option.
It also provides security / WAF, DDoS protection, etc.
Conclusion
I’ve shared a smorgasbord of optimization tools and strategies with you today, but my main message to you would be to be intentional with your decisions.
I’ve used that word a few times, but that’s the point I really want to drive home.
Nothing here will apply universally to every application.
The only way to make the appropriate optimizations is for you (or a professional) to evaluate your unique scalable WordPress hosting situation and use case.
Your number one priority if you’re running a business of any decent size should be to choose appropriate scalable WordPress hosting.
I don’t want to say “good” because that’s subjective and depends on your use case.
But be honest with yourself and choose hosting that gives you the level of performance and support you think you’ll need for the next 6 months to a year.
With a solid infrastructure foundation to build on and hopefully a technical support partner you can depend on, you’re giving yourself the best chance for success as you work to grow your audience and your site.
About the Author
Vic Dorfman is a performance and hosting expert and the co-founder of scalable WordPress cloud hosting provider MemberHost.io. Contact Vic Dorfman here.
