10 Ways to Optimise Your Moodle Performance in 2026
A slow Moodle site is more than just an inconvenience. When page load times extend beyond 3 seconds, you may lose students. When quiz windows crash under load, you damage institutional trust. When instructors wait 8 seconds for grade books to render, you reduce platform confidence.
The real question isn't whether you should optimise Moodle, but which optimisations provide the most value for the effort and cost involved. This guide outlines ten proven strategies, each showing expected performance improvements, implementation effort, and deployment timelines based on real-world systems supporting between 100 and 10,000+ concurrent users.
Performance Optimisation ROI at a Glance
Benchmark note: the gains below are indicative ranges from Moodle tuning work on representative sites. They are useful for prioritization, but they are not universal guarantees. Always capture a baseline and rerun the same test after each change.
| Optimisation | Performance Gain | Implementation Time | When to Implement |
|---|---|---|---|
| PHP OPcache | Page load: up to 60-70% faster in test cases | 15-30 minutes | Day 1 (non-negotiable) |
| Redis for Sessions | Session-related database load: up to 80%; supports more concurrent users | 1-2 hours | Before 100 concurrent users |
| Database Tuning | Query time: up to 40-60% average in bottlenecked sites | 2-4 hours | When DB CPU > 60% |
| Nginx + PHP-FPM | Concurrent connections: 500 -> 2,000+ | 4-6 hours | 200+ concurrent users |
| Image Optimization | Bandwidth: up to 50-70%; page weight: up to 40% | Ongoing process | Immediately and then ongoing |
| CDN Integration | Load time for global users: up to 30-60% | 2-3 hours | When users span multiple continents |
| Plugin Audit | Overall load time: up to 10-30% | 2-3 hours | Quarterly maintenance |
| Lightweight Theme | Initial render: up to 20-40% | 1-8 hours | When a performance bottleneck is identified |
| Cron Scheduling | Peak-hour CPU: up to 15-25% | 1 hour | When peak and off-peak loads differ |
| NVMe Storage | Database I/O wait: up to 70-85% in disk-bound sites | 1-4 hours + migration | When disk I/O > 20% wait |
Hardware Foundation: Invest in the Right Order
Before tuning any configuration file, confirm your hardware is not the bottleneck. The underlying resources cap configuration gains. The investment priority must be RAM first, then fast storage, then CPU.
1. RAM (Memory): The Single Most Effective Upgrade
You need RAM for database caching, PHP-FPM worker pools, Redis/Memcached stores, and operating system buffers.
| RAM | Approximate Concurrent Capacity | Cache Behaviour |
|---|---|---|
| 8 GB | Up to ~200 concurrent users | Frequent cache misses; disk reads likely under load |
| 16 GB | Up to ~500 concurrent users | Good hit rate for typical course workloads |
| 32 GB | Up to ~1,000 concurrent users | Most active tables fit in memory |
| 64 GB | 2,000+ concurrent users | Near-complete in-memory caching is achievable |
When to upgrade: When your database buffer pool can't fit in RAM (check innodb_buffer_pool_size against available memory).
2. NVMe SSD Storage: Eliminate I/O Bottlenecks
Moodle typically runs 200-500 database queries for each page load. When the required data is not available in memory, the server must read it from disk. NVMe SSDs significantly reduce this delay.
| Storage Type | Relative Throughput | Relative Latency | Expected I/O Wait Under Load |
|---|---|---|---|
| HDD (spinning) | Lowest | Highest (tens of ms) | Very high -- serious bottleneck |
| SATA SSD | Moderate | Low (single-digit ms) | Moderate -- manageable at small scale |
| NVMe SSD | Highest | Minimal (sub-ms) | Low -- rarely the bottleneck |
3. CPU: Important but With Diminishing Returns
Once you have sufficient RAM and fast storage, the CPU becomes the bottleneck. Adding cores beyond 8-16 vCPUs rarely delivers proportional gains for typical Moodle workloads.
Sizing by concurrent users:
- 100 concurrent: 2-4 vCPUs sufficient
- 500 concurrent: 4-8 vCPUs recommended
- 1,000 concurrent: 8-16 vCPUs optimal
- 2,000+ concurrent: Multi-server architecture, no more CPUs
Top 10 Moodle Performance Optimisations
1. Enable PHP OPcache (Required, Not Optional)
Enabling OPcache alone is typically the fastest and largest single improvement you can make to page load times. Do this before anything else.
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0 # Production only
opcache.save_comments=1 # Required for MoodleImplementation time: 15-30 minutes | Cost: $0 (built into PHP 5.5+)
2. Configure Redis for Sessions and Caching
By default, Moodle stores user sessions in the database or on disk. Moving sessions to Redis reduces bottlenecks under concurrent load. Beyond sessions, Redis can also back Moodle's MUC (Moodle Universal Cache) stores, further reducing database reads.
$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';
$CFG->session_redis_port = 6379;Implementation time: 1-2 hours | Cost: $0 self-hosted; ~$15-50/month managed
3. Tune Your Database Server (The Most Common Bottleneck)
The most impactful single change is correctly sizing innodb_buffer_pool_size, which controls how much of the database can be held in memory.
innodb_buffer_pool_size = 26G # 80% of 32GB RAM
innodb_buffer_pool_instances = 8
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
query_cache_size = 0 # Deprecated, disable| Deployment Type | Buffer Pool Target | Minimum Recommended |
|---|---|---|
| Dedicated database server | 70-80% of total RAM | 4 GB for small deployments |
| Shared server (web + DB) | 30-40% of total RAM | Leave headroom for PHP-FPM workers |
When to act: When DB CPU is consistently above 60%, or when slow query logs show I/O-bound queries. Implementation time: 2-4 hours.
4. Use a Modern Web Server Stack (Nginx + PHP-FPM)
Apache with mod_php spawns a complete PHP interpreter for every incoming connection. Nginx with PHP-FPM uses a persistent pool of PHP worker processes that serve requests efficiently without the per-connection overhead.
Worker pool sizing principle:
pm = static
pm.max_children = available_RAM_MB / avg_PHP_process_MB
# Typical PHP-FPM process: 40-80 MB
# Example: 12,000 MB available / 60 MB per process = 200 workersImplementation time: 4-6 hours (install, configure, migrate & test)
5. Optimise Your Media Content Aggressively
Unoptimised media is one of the most common--and most preventable--causes of slow Moodle pages.
| Asset Type | Approach | Tools / Notes |
|---|---|---|
| Images | Compress before uploading. Set maximum dimensions. Use WebP where possible (Moodle 4.0+). | TinyPNG, Squoosh, ImageOptim -- all free |
| Videos | Never upload video files directly to Moodle. Host on YouTube or Vimeo and embed via iframe. | YouTube: free. Vimeo: free tier available. |
Apply to all new content immediately. Schedule a quarterly review of existing course content.
6. Use a Content Delivery Network (CDN)
A CDN caches static assets -- images, CSS, JavaScript, and fonts -- on edge servers globally. Users are served assets from the closest edge node, reducing latency. The benefit is proportional to the geographic spread of your users.
| CDN Option | Cost | Best Suited For | Key Benefit |
|---|---|---|---|
| Cloudflare Free | $0 | Most Moodle sites | Reduces origin server bandwidth and CPU |
| Cloudflare Pro | ~$20/mo | Sites needing advanced cache rules | Custom page rules, more cache control |
| AWS CloudFront / Fastly | $50-200/mo | Enterprise deployments | Programmable edge, detailed analytics |
Cloudflare setup: add domain -> update nameservers -> Cache Level: Standard -> Browser TTL 4 hours -> create a page rule to bypass cache for *.php URLs.
Implementation time: 2-3 hours
7. Keep Moodle and Plugins Updated (Security and Performance)
Moodle releases contain not just security patches but genuine performance improvements. Running an outdated version means leaving those improvements on the table.
| Update Type | Recommended Cadence | Notes |
|---|---|---|
| LTS version upgrades | Once per LTS cycle | Moodle 4.5 is current LTS (security support to October 2027). Next LTS: 5.3, October 2026. |
| Security patches | Within 2 weeks of release | Apply without waiting if severity is high |
| Plugin updates | Monthly check | Update during low-traffic windows; test on staging first |
| Major version upgrades (non-LTS) | Optional | Moodle 5.0 introduced Bootstrap 5, PHP 8.2+, and query bank restructuring. Compatibility testing required. |
8. Reduce Plugin and Block Bloat Ruthlessly
Every enabled plugin adds processing time to every page load -- even if not actively used on that page. Moodle calls plugin hooks throughout the page lifecycle regardless.
Audit process: Site administration -> Plugins -> Plugins overview. Identify plugins with no activity in the past 90 days. Disable, test for regressions, then uninstall if stable.
| Plugin Category | Typical Overhead Pattern | Recommended Action |
|---|---|---|
| Heavy analytics or reporting plugins | Adds processing on every page | Disable if not actively used |
| Complex third-party integrations | May make outbound API calls or additional DB queries per page | Audit carefully; disable if not in active use |
| Unused authentication methods | Checked on every login attempt | Disable all auth methods not in use |
9. Choose a Fast and Clean Theme
Themes control the volume of CSS and JavaScript loaded on every page. Feature-rich themes often bundle large JavaScript libraries and complex layout engines that add render time regardless of whether those features are used.
| Theme | Type | Asset Footprint | Best For |
|---|---|---|---|
| Boost | Free (default) | Lightest | Fastest baseline; recommended starting point |
| Moove | Free | Light | Clean look with modest additional features |
| Adaptable | Free | Moderate | High configurability; test performance impact |
| Premium themes (e.g., RemUI) | Paid ($79-169/yr) | Heaviest | Only worthwhile if features are actively needed |
Avoid changing themes mid-semester. Test any theme change on staging first. Implementation time: 1-2 hours.
10. Configure Cron to Run During Off-Peak Hours
Moodle's cron system handles forum digests, grade reports, course backups, and file cleanup. Heavy background tasks scheduled during peak hours compete with live user traffic for CPU and I/O.
| Task | Default Behaviour | Recommended Schedule | Notes |
|---|---|---|---|
| Core cron runner | Every minute | Keep at every minute | Required for Moodle to function -- do not change |
| Course backups | During the day (varies) | 2-4 AM | Disable during high-stakes exam weeks |
| User enrollment sync | Every 5 minutes (typical) | Once daily at 3 AM | Frequent sync is rarely necessary |
| Statistics processing | Varies | Weekly, 2 AM Sunday | Can be very CPU-heavy on large sites |
| File cleanup tasks | Varies | Daily at 4 AM | -- |
Manage via: Site administration -> Server -> Scheduled tasks. Implementation time: ~1 hour.
Hardware Sizing Guide by User Scale
| Small (up to 500 users) | Medium (500-2,000) | Large (2,000-10,000+) | |
|---|---|---|---|
| Architecture | Single server | Separate web + database servers | Load-balanced web cluster + dedicated DB cluster |
| Web/app server | 4-8 vCPU, 16-32 GB RAM, NVMe | 8 vCPU, 16 GB RAM, NVMe | 3-5 nodes, 8-16 vCPU each, NVMe |
| Database server | Shared (on web server) | 8 vCPU, 32 GB RAM, NVMe | 16+ vCPU, 64-128 GB RAM, NVMe; add read replica |
| Redis | Same server, small allocation | Dedicated 4 GB instance | HA Redis cluster, 16 GB+ |
| Optimisations required | OPcache, Redis sessions, basic DB tuning, image optimisation | All above + Nginx/PHP-FPM + CDN | All optimisations mandatory; add auto-scaling, monitoring, and read replicas |
| Estimated monthly cost | $80-200 | $300-600 | $1,500-5,000+ |
Performance Guarantees You Can Test
- 99.9% Uptime SLA
- Sub-500ms Page Load Target: 95th percentile for authenticated users under normal load
- Performance Monitoring Dashboard
Example JMeter Results (500-User Plan):
- 200 concurrent users: Average response time 420ms, 0% errors
- 400 concurrent users: Average response time 680ms, 0% errors
- 600 concurrent users (120% capacity): Average response time 1.2s, 0.3% errors
Migration to Optimised Infrastructure
What We Handle:
- Full site migration (code + database + files)
- Performance baseline testing on your current host
- Post-migration performance testing
- Side-by-side comparison report
Typical Migration Performance Gains:
- From overloaded shared hosting: page loads often improve by multiple times after moving to dedicated, tuned infrastructure
- From AWS DIY: gains depend on the starting configuration, especially PHP-FPM, database, Redis, and storage tuning
- From MoodleCloud: performance and plugin-support improvements depend on the plan limits and workload profile you are leaving
Migration Timeline: 24-48 hours for standard sites; 3-5 days or more for enterprise sites with testing, custom plugins, and large data volumes.
Why Our Approach Works
Generic hosting providers treat Moodle the same as WordPress or any other PHP application. Moodle's architecture -- with its session management, course module structure, and caching framework -- requires specialised optimisation.
Moodle-Specific Expertise:
- PHP-FPM pools tuned for Moodle's memory patterns
- Redis configured for Moodle's MUC cache structure
- Database indexes optimised for Moodle's most common queries
- Cron jobs scheduled based on CPU load metrics (not fixed schedules)
Continuous Optimisation:
- Weekly performance reviews on all enterprise plans
- Proactive alerting when cache hit rates drop below 90%
- Quarterly optimisation reports with specific recommendations
- Pre-exam load testing for high-stakes assessment periods
Start With Performance Built In
You can spend months learning to optimize Moodle yourself, or you can start with a platform where these optimizations are already configured and validated against the selected hosting plan.
MooDIY Cloud provides:
- All optimizations active from day one
- Scaling that grows with you from small cohorts to larger institutional workloads
- Performance monitoring and proactive support
- Free migration from your current host with performance comparison
Ready to see the performance difference? Contact us for a pre-migration performance audit.