LearnDash Hosting: What Actually Makes It Fast

A fast LearnDash site comes down to four things: fast CPU cores rather than simply a lot of them, enough PHP workers for your concurrent logged-in learners, OPcache and Redis object caching tuned correctly, and no full-page caching plugin sitting in front of course pages that can’t be cached in the first place. Plugin audits, Cloudflare, and front-end tuning matter too, but they’re the last 20% of the work, not the first 80%.

We know this because we co-hosted an official webinar with LearnDash, “Hosting & Optimizing Heavy LearnDash Sites for Great Performance” (the recording now lives on Nexcess Docs), where MemberHost co-founders Vic Dorfman and Denny Cave walked through why LearnDash sites slow down and what fixes it, with real server data on screen. This post is that talk, cleaned up and expanded. The numbers below are the ones shown live in the webinar, and the thresholds are rules of thumb, not guarantees.

Why LearnDash is transactionally heavy, and why page caching can’t save logged-in learners

Every WordPress performance conversation starts with caching, and for a normal marketing site that’s the right instinct. It’s the wrong instinct for LearnDash.

As Denny Cave put it in the LearnDash webinar, “The main thing we run into with LearnDash is that it’s what we call transactionally heavy. There are a ton of PHP files running behind the scenes, lots of action hooks and filters, and a ton of database reads and writes happening as users take actions throughout their course experience. This is happening for almost every single page view you generate.”

A course listing, a lesson page, a quiz submission, a progress update, a certificate download: each one has to check who you are, what you’ve completed, what you’re allowed to see, and write back to the database when you finish something. None of that can be served from a static, pre-generated file, because none of it is the same for two different learners.

Denny made the point concrete during the live Q&A when someone asked about server-side caching: “When we’re logging in, the top of the site says Denny, it says my name at the top: welcome, here’s your course listing. We can’t cache that and show it to the next visitor. Then it’s exposing all of my information. It’s going to be useless to them, and it’s going to violate my privacy.” Page caching works by generating a page once and serving that same copy to everyone. The moment the page has to say “Denny” instead of a generic greeting, that model breaks.

It rarely stops at LearnDash, either. Most LearnDash sites are running WooCommerce for course sales, a membership plugin for access control, or BuddyBoss for community, and each of those adds its own database reads and writes on top.

CPU speed matters more than core count

The instinct is to look at core count when comparing hosting plans. For a single learner loading a single page, that’s the wrong metric.

For a single page request, unless the whole server is overloaded with visitors at that moment, the number of cores makes no difference to that request’s speed. What matters is the speed of a single core, since more cores only help once many people hit the server at the same time.

Raw gigahertz isn’t the whole story either. A newer processor generation running at a lower clock speed can outperform an older one running faster, and most hosts won’t say which generation you’re on. As Denny Cave put it in the LearnDash webinar, “Most of the major managed web hosts are not going to give you specs on CPUs. I think part of it is that anybody asking that information is probably going to be disappointed by the answer they get.”

Server distance from your audience matters less than most people assume, especially when the power gap between hosts is large. As Vic Dorfman put it, describing MemberHost’s own client work, “We’ve deployed servers for customers that are not local to their user base, but it still outperformed their local hosting provider, because that local host was just grossly underpowered.” A fast, distant server can beat a slow, nearby one.

PHP workers: your grocery store checkout lanes

Once you’ve got CPU speed sorted, the next question is how many requests your server can handle at the same time. That’s PHP workers.

Denny’s analogy from the webinar is the clearest way to explain this to a non-technical site owner: “I like to think about it as a checkout at the grocery store. The speed with which a cashier can check you out is kind of like your processor performance. The number of lanes and the number of cashiers we have is a good analogy for the number of PHP workers or CPU cores we have.”

A fast cashier (fast CPU) checks each shopper out quickly. More open lanes (more PHP workers) let more shoppers get checked out at the same time. If you only have two lanes open and fifty people show up, they queue, no matter how fast each individual cashier is. That queue, on a LearnDash site, is what turns into a slow page load or, at the extreme, a Gateway Timeout.

The two scale together. Adding cores without adding workers doesn’t help, and adding workers without the CPU behind them just means more requests competing for the same processing power. Most hosts don’t publish worker counts clearly, and fewer explain how workers scale as traffic grows, so ask before you commit to a plan.

OPcache and object cache: the demo numbers that matter

The webinar’s clearest before-and-after numbers show up here, and for many LearnDash sites this is one of the most effective server-side changes you can make.

OPcache stores the compiled version of your PHP files in memory so the server doesn’t have to reopen, reinterpret, and recompile the same files on every request. Denny: “This can have a pretty dramatic effect whenever we are inside of something like LearnDash or BuddyBoss, where we have just tons and tons of files that are being loaded every request.”

In the live demo, a poorly tuned OPcache setup ran a 60% hit rate while sitting at 100% of its allocated memory (128 of 128 MB), so the 40% of file lookups that missed the cache were being processed live on every request. Denny’s targets were two separate numbers. The hit rate should be as close to 100% as possible. Memory use should sit below the limit, and for that he gave a ballpark: “I like 85% as kind of a ballpark. It gives us some room to add files and plugins and grow a little before we hit the memory limit.” A properly configured example in the demo hit a 100% hit rate, though its memory use was still high enough that he would raise the allocation to bring it back toward 80 to 85%.

Object cache (Redis) does the same thing for database queries: instead of hitting the database every time, repeated queries get served from memory. Without Redis active, a WordPress dashboard page ran 171 database queries and took 0.8 seconds to generate, with the database queries alone consuming 0.2 seconds. With Redis object caching turned on, the same page dropped to 17 queries, and the database query time fell to 0.0038 seconds.

Denny was clear about how small the actual change was: “That was literally just by activating the Redis object cache. That’s the only difference, the only change we made. Redis was already installed, we just turned it on at the server level.” There were no code changes and no rebuild. Turning on a caching layer that was already installed did it. If your host supports Redis and it isn’t active, that’s the first thing to check.

Why WP Rocket, Breeze, and Cache Enabler are not the fix at scale

Plugin-based page caching tools are useful for a static brochure site. They do not solve the LearnDash problem, because the pages that hurt (lessons, quizzes, dashboards) are logged-in pages that no page cache should serve.

Denny didn’t hedge on this in the webinar: “If you’re using anything like a WP Rocket, Breeze, or Cache Enabler, that’s something you should look at pulling out. All the requests still go through PHP, and it still has a big performance impact at scale when you have lots of concurrent users. You can get a lot further with server-side page caching.”

How much this costs depends on how the plugin delivers its cache. In a typical setup, requests still pass through PHP and WordPress before the plugin decides to serve a cached copy, which is the overhead Denny was describing. Some plugins can hand cached files straight to the web server through rewrite rules, which avoids PHP for those requests, but only if the server is configured for it. Server-side page caching (through your web server or a tool like LiteSpeed Cache, configured correctly) intercepts requests before PHP loads by design. Before you remove a plugin, check how your site actually serves cached pages and that logged-in pages are excluded. Most logged-in LearnDash pages can’t be full-page cached anyway, so the plugin ends up adding overhead to serve the handful of pages that could have been cached at the server level for free.

There is one nuance Denny raised in the Q&A. LiteSpeed can cache certain pieces of a logged-in page separately from the rest, but “it generally just doesn’t work automatically unless the template and the plugin are configured to work with that technology.” That takes real setup work to get right.

We’ve seen this failure mode play out on other membership platforms as well. Our Brittany Lynch case study covers a site running two membership plugins where the previous host’s blanket caching caused login failures, redirect loops, and broken checkouts, the exact symptoms you get when a caching layer doesn’t understand which pages are actually unique per user.

Hosting tiers: shared, VPS, dedicated, and cloud

Shared hosting is the cheapest and most common starting point, and for a LearnDash site it should stay a starting point. You can’t configure much, artificial limits get placed on things like PHP workers, and the underlying hardware tends to pair large core counts with slow CPUs because the provider is optimizing for volume, not performance. In Denny’s words, it’s “really only suitable for proof of concept,” and any real number of active learners exposes the limits fast.

VPS (virtual private server) hosting divides one physical server into isolated slices, giving you real control, sometimes full root access, at a real cost in required expertise. You’ll typically pair it with a control panel (GridPane, RunCloud, SpinupWP) on a provider like DigitalOcean or Linode, or use something like Cloudways, which bundles the control panel with the virtual machine itself. A reasonable middle ground if you know what you’re doing.

Dedicated servers hand you an entire physical machine, good for performance but with no support net. Most dedicated providers hand you the box and stop there: if it’s plugged in and online, that’s the extent of their responsibility, and everything above that is on you.

Cloud and premium managed hosting is where multiple servers work together, sometimes a database server and an application server running as separate nodes, built for high availability and scale. Support changes here too: instead of infrastructure-only (AWS, Google Cloud, DigitalOcean) or standard managed WordPress (better defaults, general troubleshooting), you get application-level support from people who understand LearnDash-specific problems, proactive monitoring, and 24/7 access to someone who can dig into a slow query. Denny placed MemberHost in this tier explicitly during the webinar, alongside the higher tiers of WP Engine, Kinsta, Pantheon, and Pagely, calling it “the type of environments that we do on a daily basis.” That’s where our LearnDash hosting sits: fast CPUs, OPcache and Redis object caching, and page caching applied surgically instead of left as a generic WordPress default. It’s the same performance approach we apply across every heavy plugin stack we host, LearnDash included.

How to benchmark a host yourself

The webinar covered specific, mostly free tools for checking what you’re running on, rather than taking a sales page’s word for it.

WordPress Hosting Benchmark Tool scores CPU, memory, and database performance quickly. The number matters less than the trend: run it now, run it again in six months, and see if you’re moving in the right direction.

WP Performance Tester measures database queries per second, the number Denny called the clearest signal of whether a host can handle a dynamic site. In a live comparison during the webinar, a managed WordPress host scored 98 queries per second, “abysmal” in Denny’s words, against a MemberHost setup that scored at least an order of magnitude higher. His rule of thumb: aim for 1,500 to 2,000 queries per second on a dynamic site like LearnDash, and treat anything under 1,000 as a reason to talk to your host. It is one signal among several, since query speed says nothing about how the server behaves with hundreds of learners logged in at once.

Code Profiler, Query Monitor, and New Relic dig into the application itself. Code Profiler (free and pro) shows what’s loading on a given page request and how long each piece takes, plugin by plugin, often surfacing a small utility plugin quietly eating a disproportionate share of load time. Query Monitor tells the same story from the database side, including duplicate or slow queries: it’s the tool Denny used on stage to produce the 171-versus-17-query object cache comparison above. New Relic goes deeper, tracking performance continuously over days or weeks instead of a single snapshot, but it needs root server access and more effort to read.

Load testing with loader.io (simple, cheap, good for a baseline login-and-browse test) or k6 (scriptable, open source, built for simulating real learner behavior) shows how your site holds up under concurrent users instead of a single request. The webinar’s k6 example simulated 1,000 users logging in and stepping through a course over five minutes. Run two versions: one at your expected traffic level, and one that keeps increasing load until something breaks, so you know both how it performs normally and where the ceiling is.

Diagnosing Gateway Timeout errors

A Gateway Timeout means the server didn’t respond within the time allotted, and it’s one of the more frustrating errors to chase because it doesn’t tell you why on its own.

Denny fielded exactly this question during the live Q&A, from an attendee dealing with frequent timeouts on a high-traffic site. His answer: it usually comes down to the database side, a long-running query that isn’t executing fast enough, or the server chewing through too much PHP code to respond before the clock runs out.

He also flagged PHP worker saturation as a distinct cause from raw server overload: with two workers and requests arriving faster than they can be processed, later requests sit in a queue and can time out even on a server that isn’t otherwise struggling. And sometimes it’s neither: a single admin trying to load a report on thousands of users at once can time out even a powerful server, because that one request is asking for too much in one shot.

The fix starts with the same tools covered above. Run Code Profiler or Query Monitor on the page or action that’s timing out, identify whether it’s a slow query, a worker bottleneck, or an oversized request, and address that specific cause rather than guessing.

Should you separate your course site from your marketing site?

For anything past a small setup, the webinar’s answer was yes. Denny’s reasoning: separating the two gives you more flexibility to work on your marketing site without touching your membership and course content, and the performance angle runs both directions. A heavy LMS plugin stack can drag down your marketing site’s own admin performance too, when they share one install.

This isn’t an absolute rule. If your marketing footprint is limited to a homepage and a sales page, running everything on one domain is fine. Once you’re actively maintaining a real marketing site alongside a growing course platform, separating them means you can update, redesign, or troubleshoot one without any risk to the other.

LearnDash hosting checklist

What to check	How to check it	Good sign	Time to worry
CPU generation and speed	Ask your host directly (rarely published)	Host names a specific, modern-generation processor	Host won’t answer, or only gives vague “high performance” language
Database throughput	WP Performance Tester	1,500 to 2,000+ queries per second	Under 1,000 queries per second
OPcache hit rate and memory	WP OPcache plugin (or ask your host)	Hit rate close to 100%, memory use around 80 to 85% of the allocation	Memory at 100%, or a hit rate well below 100% (the bad demo showed 60%)
Object cache (Redis)	Query Monitor, before and after test	Redis active, repeat database queries drop sharply	No object cache installed, or dashboard pages running 100+ queries
PHP workers	Ask your host how workers scale with traffic	Workers increase with your plan or usage tier	Fixed, low worker count regardless of growth
Page caching setup	Check what’s actually caching your pages	Server-side caching, or none on logged-in areas	A plugin like WP Rocket, Breeze, or Cache Enabler covering course pages
Overall server score	WordPress Hosting Benchmark Tool	Strong, stable CPU, memory, and database scores	Declining scores over repeated tests
Behavior under load	loader.io or k6, simulating login and course steps	Handles expected concurrent learners without errors	Errors or slowdowns well below your expected peak
Gateway Timeouts	Server logs, Code Profiler	Rare, tied to unusual requests	Recurring during normal traffic, logins, or quiz submissions

Frequently Asked Questions

What actually makes a LearnDash site fast?

Four things, in order of impact: fast, modern CPU cores rather than just many of them, enough PHP workers to match your concurrent logged-in learners, OPcache and Redis object caching tuned correctly (an OPcache hit rate close to 100% with memory headroom to spare, Redis active for database queries), and no full-page caching plugin in front of pages that are unique per user. Plugin cleanup, Cloudflare, and front-end optimization help, but they’re refinements on that foundation, not substitutes for it.

Can I use WP Rocket, Breeze, or another caching plugin on a LearnDash site?

You can, but it won’t fix logged-in performance, because lessons, quizzes and dashboards are unique per learner and should not be page cached at all. For your public pages, server-side page caching usually goes further than a plugin, since many plugin setups still route requests through PHP. Some plugins can serve cache files through web server rewrite rules, so check how yours is configured, and make sure logged-in pages are excluded, before you remove it.

How many PHP workers do I need for LearnDash?

There’s no fixed ratio. It depends on how many learners are logged in and active at once, and how many CPU cores back those workers. Workers and cores need to scale together: adding workers without more CPU just creates more requests competing for the same processing power. Ask your host directly how workers scale as traffic grows, since most plans don’t publish this.

What database queries per second should a LearnDash host deliver?

As a rule of thumb from the webinar, aim for 1,500 to 2,000 queries per second, tested with a tool like WP Performance Tester. Anything under 1,000 is worth a direct conversation with your host. Below that range, dynamic pages such as lesson views, quiz submissions and dashboards tend to slow down, especially as concurrent users increase.

What causes Gateway Timeout errors on a LearnDash site?

Usually one of three things: a long-running database query, too much PHP code executing for a single request, or PHP worker saturation, where requests arrive faster than your available workers can process them and start queuing. A single oversized request, like an admin report pulling data on thousands of users at once, can also cause it even on a powerful server. Profile the specific page or action with Code Profiler or Query Monitor to find the actual cause before changing anything.

Should my LearnDash course site live on its own domain, separate from my marketing site?

For anything beyond a small setup (a homepage and a sales page), yes. Separating them gives you room to update and troubleshoot your marketing site without risk to your course platform, and keeps the heavier database load of your LMS and membership plugins from dragging down your marketing site’s own performance. If your marketing footprint is minimal, one domain is fine.

Does Cloudflare speed up a LearnDash site?

It helps with network routing between data centers and adds security benefits like a web application firewall and DDoS protection, but it doesn’t cache the logged-in, dynamic pages that make up most of a LearnDash site. In some cases it can even route traffic through points of presence further from a visitor than your origin server already was. Worth having for security, not a substitute for server-side performance work.

If you’ve read this far and you’re not sure where your own site stands on any of this, that’s exactly what we built our free site speed audit to answer. We look at how your site performs today and tell you where the real bottleneck is, whether or not you end up hosting with us.