Why Moodle performance is a different problem
Moodle isn't a typical brochure website — it's a database-heavy application that gets hammered at predictable peak times: the start of a term, an exam window, or the hour before an assignment deadline, when hundreds of students hit the same pages at once. Fixes that work for a simple website often miss the parts of Moodle that actually slow down under that kind of load.
These are the factors that consistently make the biggest difference on real Moodle installations, from hosting through to what's actually inside the courses.
1. Size hosting for concurrent users, not average load
Peak load, not the daily average
A Moodle site that feels fine most of the day can fall over completely during an exam window, because the number of logged-in, actively-clicking users spikes far above the average. Sizing hosting around average traffic, rather than realistic peak concurrency, is one of the most common root causes of "Moodle is slow" complaints.
PHP workers and memory limits
Each simultaneous request needs its own PHP worker and enough memory to run Moodle's code. If the server runs out of available workers during a busy period, requests queue up and pages appear to hang — even though the server itself isn't technically "down."
2. Configure caching properly
Moodle Universal Cache (MUC)
Moodle's own caching layer (MUC) can use APCu, Redis, or Memcached as a store, and configuring an actual cache store — instead of leaving it on the default file-based fallback — has an outsized effect on page-load times across the whole site.
OPcache for PHP
PHP's OPcache keeps compiled PHP bytecode in memory instead of recompiling Moodle's large codebase on every request. It's a server-level setting rather than a Moodle setting, but it's one of the highest-leverage things a host can enable.
Caching static assets at the web server
Theme CSS, JavaScript, and images should be cached aggressively at the web server or reverse proxy level, so Moodle itself isn't re-serving the same unchanged files on every page view.
3. Watch what's inside your courses
Course content is an often-overlooked source of slowness. Large video files hosted directly in Moodle, oversized H5P interactions, and bulky SCORM packages all add real load time on top of whatever the server itself is doing.
Most of this is easy to fix once you know to look for it, and it doesn't require any server-side changes at all.
- Host large video externally (YouTube, Vimeo, or a dedicated streaming service) rather than uploading it directly into a course
- Keep H5P and SCORM packages reasonably sized, and check them after export
- Avoid embedding very large files or images directly on course pages that every student loads
4. Keep the database and cron jobs healthy
Moodle relies on its cron job to process notifications, completion tracking, scheduled tasks, and more. A cron job that isn't running often enough — or isn't running at all — causes a backlog that eventually shows up as generally sluggish behavior, not just missing notifications.
The database itself also needs routine attention as a Moodle site grows and accumulates years of logs and activity data.
- Run the Moodle cron job on schedule, typically every minute, and monitor that it's actually completing
- Periodically clean up old logs, temporary files, and stale backups
- Watch for slow database queries as usage grows, and add indexes where they're missing
5. Watch theme and plugin bloat
Every additional theme and plugin adds its own code, and not all of it is written with performance in mind. A heavy custom theme or a handful of rarely-used plugins can add up to a meaningful, if quiet, drag on every page load.
Periodically reviewing what's installed — and removing anything that isn't actively used — keeps the codebase Moodle has to execute on every request as lean as possible.
6. Use a CDN for static assets
Theme files, images, and other static assets benefit from a CDN in the same way they would on any other site, serving them from a location close to each student rather than a single origin server.
For institutions with students spread across different regions, this can noticeably improve load times without touching Moodle's configuration at all.
Putting it together
Hosting sized for peak concurrency, proper caching (MUC, OPcache, static assets), lean course content, a healthy cron job and database, and a light footprint of themes and plugins cover almost every real Moodle performance complaint I've come across. If you'd like a second opinion on a specific installation, feel free to get in touch or read more about my Moodle work.