Why LMS Sites Slow Down and How to Speed Up LearnDash

A course site usually feels quick on launch day and slows down once real cohorts arrive. The reason is structural. Almost every page a learner opens is a logged-in page, so the page cache that carries a normal WordPress site steps aside, and each lesson view has to check enrollment, access rules and progress before it shows anything.

So LearnDash performance work has a different target from ordinary WordPress tuning. The aim is to make each uncached request cheap, and to keep the heavy jobs (reports, quiz submissions, notifications) from landing on everyone at once.

Why the page cache barely helps a course site

Page caching works by giving every visitor the same stored HTML. A lesson page cannot be the same for everyone. It shows this learner's progress, the completion state and the next step they are allowed to open. Caches therefore skip any request that carries the WordPress login cookie, and on an LMS that is most of the traffic.

Do not try to force it. Caching logged-in pages without a per-user design is how one learner ends up seeing another's name or quiz result. Keep the page cache for what it suits: the home page, the course catalog, sales pages and blog posts. Static files (CSS, JavaScript, images) can and should be cached and served from a CDN for everyone, logged in or not.

What a lesson page asks of the server

When a learner opens a lesson, LearnDash has to answer a series of questions. Is this user enrolled, directly or through a group? Which steps does the course contain, and in what order? Which has the user completed? Is the lesson held back by a prerequisite, a drip date or a required quiz? The answers come from several places:

• the course, lessons, topics and quizzes, which are WordPress posts with their settings in post meta
• each user's progress and quiz attempts, kept in user meta (_sfwd-course_progress and _sfwd-quizzes) as arrays that grow with every course and attempt
• LearnDash's activity tables, which record course, lesson and quiz activity with timestamps and feed the reports
• the quiz tables, which hold questions and, when statistics are enabled, the answers given in each attempt

None of this is a problem on a small site. It adds up when courses have hundreds of steps, when a profile page lists every course and every attempt, or when a theme's course grid calculates progress for the whole catalog on one page. Run Query Monitor on a lesson, a course page and the profile page to see which of these your site is paying for.

LearnDash performance starts with cheaper uncached requests

Add a persistent object cache

This is the first thing to fix on a slow LearnDash site. With Redis or Memcached behind WordPress, the results of repeated lookups (options, post meta, user meta) stay in memory between requests and are no longer fetched from the database on every page. LearnDash also uses the object cache for its own temporary data, controlled by the LEARNDASH_OBJECT_CACHE_ENABLED constant. Confirm that the host supports a persistent cache, and check afterwards that Tools > Site Health no longer recommends one.

Run a supported PHP version with enough workers

Uncached pages are built by PHP, so its speed is your speed. Move to a supported PHP branch after testing your add-ons on staging, make sure OPcache is on, and find out how many PHP workers the hosting plan provides. Each learner request occupies a worker until it finishes.

Strip the lesson template down

Lesson pages tend to inherit everything the marketing site loads: chat widgets, popups, sliders, tracking tags and a page builder's full front-end library. A learner in the middle of a course needs the content, the navigation and the video player. Dequeue the rest on the course post types. LearnDash's Focus Mode gives a cleaner layout to start from, and what loads inside it is still up to you.

Reports and exports are the heaviest queries

A report asks the opposite question from a lesson page. It reads progress for all users at once, across the activity tables, user meta and posts. On a site with years of history, a group leader opening a progress report or an administrator exporting a CSV can keep the database busy for long enough that learners feel it.

• Filter before you run: one group, one course, a date range.
• Run full exports outside teaching hours.
• Check the dashboard. Reporting widgets that recalculate totals every time someone opens the admin home screen are a common hidden cost.
• If managers need the same heavy report every week, build it once: a scheduled job that writes a summary table and a report screen that reads the summary. This is a typical piece of LearnDash customization.

Be careful with cleanup. Old activity rows look like dead weight, but they are often the completion evidence an employer or an accrediting body asks for later. Archive deliberately, and never delete records only to speed up a query.

Quizzes and the spike at submission time

A quiz submission is the most expensive single request on the site. It is an uncached POST that grades the answers, writes the attempt to user meta and the activity tables, stores per-question statistics if they are enabled, may complete the course, and then sets off everything attached to completion: certificates, notification emails, group progress, webhooks to a CRM or HR system.

Now picture a timed exam where a whole cohort submits within the same minute. To keep that moment survivable:

• Turn off quiz statistics on quizzes where nobody reads them. Practice quizzes rarely need a stored answer for every question.
• Send email through a transactional mail service, and keep integrations asynchronous. Queue the CRM call and let a background job deliver it, so the learner's request does not wait for a third party.
• Avoid very long single-page quizzes. Paginated questions spread the work.
• For scheduled exams, warn the host or scale up beforehand, and stagger start times across groups where the format allows it.

Sizing hosting for concurrent learners

Monthly visits are the wrong measure for an LMS. What matters is how many logged-in learners are clicking at the same moment at your peak, because each click needs a PHP worker and a set of database queries. A site with a modest number of users who all log in at nine on Monday morning for mandatory training needs more capacity than a much larger one whose learners drift in through the week.

To size it, measure the server response time of a lesson page and of a quiz submission, estimate peak concurrent learners from your enrollment and schedule, and test with scripted logged-in users on a staging copy. Our article on load testing before launch explains how to set that up. Shared plans with a handful of workers fail this test quickly.

Two more decisions belong here. Host video on a video platform and embed it, so your server never streams files. And keep the database on fast storage with enough memory, since user meta and activity tables only grow.

When tuning the stack is not enough

Object caching, a supported PHP version, a lean lesson template and sensible hosting solve most slow LearnDash sites, and a technically confident administrator can arrange all four with the host's help. If the site is still slow afterwards, the cause is usually in code: a theme or add-on that loops over every course for every user, a custom report with an unindexed query, or an integration that calls an external API while the learner waits.

Finding and rewriting that takes someone who knows how LearnDash stores its data. We have delivered more than 300 LMS and eLearning projects, and performance work on existing course sites is a regular part of what our LearnDash development team does, starting with a profile of the lesson, quiz and report requests. The wider method is described under our performance optimization service.

Frequently asked questions

Can I use a caching plugin with LearnDash?

Yes, for public pages and static files. Make sure logged-in users bypass the page cache and that course, lesson, topic and quiz pages are excluded. Leave JavaScript delay and combination off on those pages, because quiz timers and video progress tracking depend on scripts running in order.

How many concurrent learners can a LearnDash site handle?

There is no fixed figure. It depends on the PHP workers available, how long each lesson and quiz request takes, and whether an object cache is in place. A load test with logged-in test users on a copy of your site is the only reliable way to find the limit.

Does the number of courses slow LearnDash down?

Less than people expect. The number of steps per course, the number of users and the amount of stored activity matter more, along with any page that lists all courses with progress for the current user. A large catalog with a well-built course grid performs fine.

Should course videos be hosted on the same server?

No. Streaming video from the web server uses bandwidth and connections that learners need for the pages themselves, and it cannot adapt quality to the viewer's connection. Use a video hosting platform and embed the player in the lesson.