“Moodle es lento” es casi siempre una conclusión, no un diagnóstico. Detrás de esa frase hay, casi siempre, una causa concreta y localizable, solo que rara vez es la primera que se sospecha (el servidor “necesita más potencia”) y casi siempre es algo de configuración que se puede resolver sin cambiar de infraestructura.
En esta guía vas a ver las causas más frecuentes de lentitud en Moodle, ordenadas por probabilidad real, para que sepas por dónde empezar a investigar antes de asumir que hace falta más hardware.
Caché funcionando en disco en vez de en memoria
Por defecto, buena parte de la información que Moodle cachea con frecuencia se guarda en disco, significativamente más lento que la memoria RAM, especialmente si el almacenamiento no es NVMe. Esta es, según la experiencia de administradores que ya han hecho el cambio, una de las causas de lentitud más comunes y también de las mejoras más grandes al resolverse: mover las cachés de sesión y de aplicación a Redis. Lo tratamos en detalle en Redis para Moodle: caché en memoria explicado.
OPcache desactivado o mal configurado
Sin OPcache activo, PHP tiene que volver a analizar y compilar el código de Moodle en cada petición, miles de archivos PHP procesados una y otra vez sin necesidad. Activarlo correctamente suele ser la mejora individual más rápida en tiempo de carga que se puede aplicar. Lo cubrimos en OPcache en Moodle: qué es y cómo configurarlo.
El cron no se está ejecutando (o se ejecuta con poca frecuencia)
El cron de Moodle procesa notificaciones, informes, limpieza de sesiones y otras tareas de fondo. Si no se ejecuta con la frecuencia adecuada, o directamente ha dejado de funcionar, esas tareas se acumulan, y en algunos casos, esa acumulación puede generar picos de carga cuando finalmente se procesan de golpe. Un cron mal configurado es un problema silencioso: el sitio sigue funcionando de cara al usuario mientras el problema se acumula por detrás. Lo tratamos en el cron de Moodle: por qué es crítico.
Base de datos sin afinar
Moodle ejecuta habitualmente entre 200 y 500 consultas a base de datos por cada carga de página. Si el motor de base de datos no está configurado para mantener los datos más consultados en memoria (a través de un buffer pool bien dimensionado), cada una de esas consultas puede implicar una lectura de disco, multiplicando el tiempo de respuesta de la página. Profundizamos en esto en optimizar la base de datos de Moodle.
Plugins activos sin usar
Moodle ejecuta los “hooks” de cada plugin instalado en el ciclo de vida de cada página, aunque ese plugin no se esté usando activamente en esa página concreta. Cuantos más plugins acumulados con el tiempo, más procesamiento añadido a cada carga, incluso si la mayoría de ellos apenas se usan. Una revisión periódica de plugins realmente necesarios frente a los simplemente instalados es una limpieza de rendimiento que se suele pasar por alto.
Contenido multimedia sin optimizar
Imágenes pesadas sin comprimir, vídeos alojados directamente en el servidor sin streaming adecuado, o documentos sin optimizar son de las causas más comunes y más evitables de páginas lentas. Aplicar buenas prácticas a todo el contenido nuevo, y hacer una revisión trimestral del contenido existente, evita que este problema se acumule con el tiempo.
Servidor infra-dimensionado para la concurrencia real
El dimensionamiento correcto depende de usuarios concurrentes, no de cuentas totales registradas. Un Moodle con miles de cuentas pero baja concurrencia real puede funcionar perfectamente en un servidor modesto; uno con pocas cuentas pero picos de acceso simultáneo alto (un examen, por ejemplo) puede necesitar bastante más capacidad de la que su volumen total sugeriría a primera vista.
Versión de Moodle desactualizada
Cada versión de Moodle no solo trae parches de seguridad, también incluye mejoras de rendimiento reales sobre versiones anteriores. Quedarse en una versión antigua significa, literalmente, dejar sobre la mesa mejoras de velocidad ya disponibles.
Tabla resumen: causa y cómo confirmarla
| Causa | Cómo confirmar que es tu problema |
|---|---|
| Caché en disco | Revisar configuración de cache stores en Site administration > Plugins > Caching |
| OPcache desactivado | Comprobar opcache.enable en la configuración de PHP del servidor |
| Cron sin ejecutarse o poco frecuente | Revisar la última ejecución en Site administration > Server > Scheduled tasks |
| Base de datos sin afinar | Revisar el ratio de aciertos del buffer pool y activar el registro de consultas lentas |
| Plugins innecesarios | Auditar la lista completa de plugins activos frente a los realmente usados |
| Contenido sin optimizar | Revisar tamaño de imágenes y vídeos en cursos con más quejas de lentitud |
| Servidor infra-dimensionado | Medir usuarios concurrentes reales en picos, no solo cuentas totales |
| Versión desactualizada | Comparar tu versión contra el calendario oficial de releases |
Cómo diagnosticar sin adivinar
- Mide antes de cambiar nada. Captura tiempos de carga reales en los flujos que más importan: login, inicio de un cuestionario, envío de una tarea.
- Revisa un elemento de la tabla a la vez, empezando por los más probables (caché, OPcache, cron), antes de asumir que hace falta más servidor.
- Vuelve a medir tras cada cambio, para confirmar que la modificación realmente tuvo impacto, en vez de acumular varios cambios a la vez sin saber cuál funcionó.
Preguntas frecuentes
¿Mi Moodle va lento porque tengo demasiados alumnos matriculados? No necesariamente: lo que determina la carga real es cuántos están conectados simultáneamente, no el total de cuentas registradas en la plataforma.
¿Necesito más servidor si mi Moodle va lento? No siempre. La mayoría de causas de lentitud (caché en disco, OPcache desactivado, cron mal configurado) se resuelven con configuración, no con más hardware.
¿Cómo sé si el problema es el cron? Revisa la última ejecución registrada en Site administration > Server > Scheduled tasks, si lleva mucho tiempo sin ejecutarse o se retrasa constantemente, es una señal clara.
¿Los plugins que no uso realmente afectan al rendimiento? Sí, Moodle ejecuta los hooks de cada plugin instalado en cada carga de página, independientemente de si se usa activamente en esa página concreta.
¿Actualizar de versión mejora el rendimiento por sí solo? Puede aportar mejoras reales, ya que cada versión suele incluir optimizaciones internas, además de los parches de seguridad habituales.
¿Cuánto tiempo debería tardar en cargar una página normal de Moodle? No hay un número universal, pero cualquier medición muy por encima de tu línea base histórica, sin cambios evidentes de uso, es señal de que algo se ha degradado y merece investigarse.
¿Por dónde debería empezar a investigar la lentitud? Por las causas más frecuentes y más baratas de confirmar: estado de la caché, OPcache y ejecución del cron, antes de considerar cambios de infraestructura más costosos.
Conclusión
La lentitud de Moodle casi nunca tiene una única causa, y casi nunca es “el servidor es pequeño” como primer sospechoso correcto. Caché en disco, OPcache desactivado, cron mal configurado, base de datos sin afinar y plugins acumulados son, en ese orden aproximado de frecuencia, las causas que resuelven la mayoría de casos reales que vemos.
Si prefieres que alguien diagnostique esto por ti antes de gastar en más servidor sin necesidad, en Avantys lo revisamos como parte de la auditoría de rendimiento de cada Moodle que gestionamos. Puedes pedirla gratis en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Redis para Moodle: caché en memoria explicado
- OPcache en Moodle: qué es y cómo configurarlo
- El cron de Moodle: por qué es crítico
- Optimizar la base de datos de Moodle
- Requisitos de servidor para Moodle (CPU, RAM, disco)
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
