CDN para Moodle: Cuándo Tiene Sentido

Un CDN no acelera tu Moodle para todo el mundo por igual, su beneficio es directamente proporcional a lo geográficamente distribuidos que estén tus alumnos respecto a tu servidor. Para un centro con todos sus alumnos en la misma ciudad que el servidor, el impacto puede ser modesto; para una academia con alumnado repartido por distintas regiones o países, puede marcar una diferencia notable en los tiempos de carga.

En esta guía vas a ver qué hace exactamente un CDN, cuándo el beneficio justifica configurarlo, y cómo montarlo sin romper partes dinámicas de Moodle.

Qué es un CDN y qué problema resuelve

Un CDN (Content Delivery Network) es una red de servidores distribuidos geográficamente que almacena en caché copias de tu contenido estático (imágenes, hojas de estilo, archivos JavaScript, fuentes) y las sirve desde el nodo más cercano a cada usuario, en vez de siempre desde tu servidor de origen. El resultado es una reducción de la latencia percibida, especialmente notable cuando los usuarios están lejos geográficamente del servidor donde vive Moodle.

La distancia física importa más de lo que parece. Cada archivo que carga una página (una hoja de estilos, media docena de iconos, un par de fuentes, las imágenes del curso) es una ida y vuelta hasta el servidor. Si tu servidor está en Madrid y el alumno abre Moodle desde Bogotá, cada una de esas idas y vueltas cruza el Atlántico. Con decenas de recursos por página, esos milisegundos se acumulan hasta convertirse en segundos de espera antes de que la página termine de pintarse. Un nodo del CDN en la región del alumno corta esa distancia: sirve la copia cacheada del recurso a pocos kilómetros de él, sin molestar a tu origen.

Conviene entender qué no hace un CDN. No hace que Moodle procese las peticiones más rápido, no reduce la carga de tu base de datos en las páginas dinámicas, y no arregla un servidor mal dimensionado o un Moodle sin caché interna. Si tu problema es que el panel de calificaciones tarda ocho segundos en generarse, un CDN no lo toca, eso es cálculo en el origen, no transporte de archivos. Por eso el CDN es la última capa que se añade, no la primera: primero se afina el servidor y la caché de Moodle (lo explicamos en rendimiento y optimización de Moodle) y solo después se pone un CDN delante para ganar en distribución geográfica.

Qué contenido de Moodle se beneficia de un CDN

• Imágenes de curso, iconos y elementos gráficos del tema.
• Hojas de estilo (CSS) y archivos JavaScript del tema y de plugins.
• Fuentes tipográficas.
• Archivos estáticos descargables que no cambian con frecuencia (documentos, plantillas).

Lo que no se beneficia directamente de un CDN son las partes dinámicas de Moodle: el contenido de un curso generado en cada petición según el usuario que lo consulta, los foros, las calificaciones o cualquier página que se genera de forma personalizada, esas peticiones siguen yendo directamente a tu servidor de origen.

La línea que separa una cosa de la otra no es un capricho técnico: es lo que hace que un CDN sea seguro o peligroso en Moodle. Esta tabla resume qué va por caché y qué debe seguir yendo al origen, con el riesgo de equivocarse.

Contenido	¿Cachear en CDN?	Por qué
CSS y JS del tema	Sí	Igual para todos, cambia poco, versionado por Moodle
Fuentes tipográficas	Sí	Estáticas, mismas para todo el mundo
Iconos y gráficos del tema	Sí	Estáticos, sin control de acceso
Imágenes y descargas públicas	Sí	Mismo archivo para cualquier visitante
Páginas de curso, foros, calificaciones	No	Se generan por usuario en cada petición
Archivos vía pluginfile.php	Con cuidado	Llevan control de acceso: distinto según quién pide
login, logout, sesión, formularios	Nunca	Cachear una sesión filtra la cuenta de otro alumno

pluginfile.php: el archivo que parece estático pero no lo es

Aquí está el matiz que más problemas causa y que casi nadie ve venir. Cuando subes un PDF a un tema de curso, una imagen a un foro o un entregable a una tarea, Moodle no lo sirve como un archivo suelto del disco. Lo sirve a través de pluginfile.php, un script que comprueba permisos antes de entregar el archivo: verifica que quien lo pide está matriculado en ese curso, que tiene el rol adecuado y que puede ver ese recurso concreto.

Eso significa que dos alumnos que piden la misma URL de pluginfile.php pueden recibir respuestas distintas (o uno recibir el archivo y el otro un 403) según sus permisos. Un CDN, por defecto, no entiende de permisos: cachea por URL. Si dejas que un CDN cachee pluginfile.php a ciegas, la primera respuesta que guarde (la de un alumno con acceso) se la servirá a todos los que pidan esa URL después, incluidos quienes no deberían verla. Ese es el escenario que hay que evitar a toda costa: un CDN mal configurado puede convertir un archivo con control de acceso en un archivo público, y filtrar la entrega de un alumno, un examen o un documento privado a quien no le corresponde.

La regla práctica es simple: nunca cachees pluginfile.php (ni ninguna otra ruta .php) salvo que sepas exactamente lo que haces. El contenido verdaderamente estático de Moodle (CSS, JS, fuentes, iconos del tema) no pasa por control de acceso y es el que puedes cachear sin miedo. Todo lo que entrega Moodle con lógica de permisos detrás debe seguir yendo al origen.

No existe un interruptor mágico de CDN en Moodle

Merece la pena decirlo claro porque circula la idea contraria: Moodle no tiene un ajuste tipo “activa el CDN y todo se sirve desde ahí”. No hay un $CFG->cdn que redirija tu contenido a una red de distribución. El CDN se monta fuera de Moodle (a nivel de DNS y servidor web), poniendo una capa delante que cachea lo que puede por las cabeceras HTTP.

Lo que sí puedes (y debes) afinar dentro de Moodle son dos ajustes que hacen que esa capa funcione bien:

• $CFG->slasharguments activado. Hace que Moodle sirva los archivos con URLs “limpias” (.../pluginfile.php/… en vez de ?file=…). Las URLs con parámetros de query las cachean peor muchos proxies y CDNs; con slasharguments el contenido estático se cachea de forma más fiable.
• Modo diseñador de temas (themedesignermode) desactivado en producción. Con ese modo activo Moodle regenera el CSS/JS del tema en cada carga y lo sirve sin cabeceras de caché largas (justo lo contrario de lo que quieres). Desactivado, Moodle versiona el CSS/JS y envía cabeceras de caché largas, que es exactamente lo que un CDN necesita para cachear el tema de forma agresiva y segura.

Con esos dos ajustes en su sitio, Moodle emite las cabeceras correctas y el CDN de delante hace su trabajo. Nada más “de Moodle” es necesario: el resto es configuración del CDN.

Dos formas de montarlo

A alto nivel hay dos maneras de poner un CDN delante de Moodle, y elegir bien depende de cuánto quieras arriesgar y cuánto control tengas del servidor.

• CDN/reverse-proxy delante de todo el sitio. Todo el tráfico pasa por el CDN, que cachea únicamente lo estático según las cabeceras y deja pasar el resto al origen. Es lo más común (es el modelo de Cloudflare y similares). Ventaja: se activa cambiando los nameservers, sin tocar la infraestructura. Riesgo: como todo pasa por el CDN, tienes que ser muy explícito en excluir de la caché lo dinámico, o te expones justo al problema de pluginfile.php que vimos arriba.
• Dominio separado solo para los assets del tema. Sirves el CSS/JS/fuentes/iconos desde un subdominio o dominio distinto (por ejemplo static.tudominio.com) enganchado al CDN, y dejas el Moodle principal fuera de la red de distribución. Ventaja: la separación es física (el contenido con control de acceso ni siquiera toca el CDN, así que el riesgo de fuga desaparece). Inconveniente: requiere más trabajo de configuración y no todos los temas/plugins reescriben sus URLs de forma limpia hacia otro dominio.

Para la mayoría de centros, el reverse-proxy delante del sitio con reglas estrictas es el punto de equilibrio. La separación por dominio de assets tiene sentido en instalaciones grandes o cuando quieres el máximo aislamiento del contenido privado.

Cómo configurar un CDN básico (ejemplo con Cloudflare)

1. Añade tu dominio al servicio de CDN.
2. Actualiza los servidores de nombres (nameservers) de tu dominio hacia los que indique el proveedor.
3. Configura el nivel de caché a “Estándar”, que cachea automáticamente los tipos de archivo estático más comunes.
4. Ajusta el TTL del navegador (por ejemplo, 4 horas) para equilibrar frescura del contenido frente a repetición de descargas.
5. Crea una regla de página que excluya de la caché las URLs que terminan en .php, para evitar que contenido dinámico generado por Moodle se sirva desde una copia en caché desactualizada.

El paso 5 es el que separa una configuración segura de una peligrosa, y por eso conviene comprobarlo en vez de darlo por hecho. Después de aplicar la regla, abre un archivo servido por pluginfile.php (un PDF de un curso, por ejemplo) y mira las cabeceras de respuesta: si ves una cabecera del CDN indicando HIT de caché sobre esa URL, la regla no está funcionando y hay que corregirla antes de dejar entrar a los alumnos. Debería marcar siempre BYPASS o DYNAMIC para lo que lleve control de acceso.

El error que rompe Moodle si se hace mal: cachear contenido dinámico

Configurar un CDN para cachear indiscriminadamente todo el tráfico, incluidas las peticiones PHP dinámicas, es el error más grave y menos visible al implementarlo mal. El síntoma es confuso: usuarios que ven contenido desactualizado, formularios que no procesan correctamente, o sesiones que se comportan de forma extraña, todo porque el CDN está sirviendo una versión en caché de una página que debería generarse de nuevo en cada petición. La solución es explícita: excluir del cacheo cualquier ruta que corresponda a peticiones dinámicas de Moodle, dejando la caché exclusivamente para archivos estáticos verdaderos.

Cuándo el beneficio de un CDN es claro

• Alumnado distribuido geográficamente, en distintas ciudades, regiones o países respecto al servidor.
• Cursos con mucho contenido gráfico o multimedia estático (imágenes de alta resolución, muchos recursos descargables).
• Picos de tráfico concentrados (inicio de curso, publicación de resultados) donde reducir la carga de contenido estático sobre el servidor de origen libera capacidad para el resto de peticiones dinámicas.

Cuándo el beneficio es más limitado

• Alumnado concentrado en la misma ciudad o región que el servidor, donde la latencia de red ya es baja de por sí.
• Instalaciones pequeñas con volumen de contenido estático modesto, donde la mejora no compensa la complejidad añadida de gestionar una capa adicional.

Y hay un error de diagnóstico que vemos entrar por soporte: gente que monta un CDN esperando arreglar una lentitud que en realidad no viene del transporte de archivos. Si tu Moodle va lento porque el servidor está justo de RAM, porque falta caché interna o porque un plugin pesado se ejecuta en cada página, el CDN no cambiará nada perceptible (el cuello de botella está en el origen, no en la distancia). Antes de plantearte un CDN merece la pena descartar esas causas; las repasamos una a una en por qué mi Moodle va lento. El CDN suma cuando el origen ya está sano y el problema real es la distancia geográfica.

CDN y rendimiento móvil

Los alumnos que acceden desde conexiones móviles, con ancho de banda variable e inferior al de una conexión de fibra doméstica, son de los que más notan la diferencia de un CDN bien configurado, cada recurso estático que se sirve desde un nodo cercano en vez de desde tu servidor de origen reduce el tiempo total de carga en una conexión que ya de por sí es más lenta y variable.

Errores comunes al configurar un CDN para Moodle

• Cachear rutas dinámicas (.php), provocando contenido desactualizado o comportamiento inconsistente.
• No ajustar el TTL del navegador, dejando contenido cacheado durante demasiado tiempo tras actualizar imágenes o estilos del tema.
• Asumir que el CDN acelera todo el sitio por igual, sin diferenciar entre contenido estático (que sí se beneficia) y dinámico (que no).
• No purgar la caché del CDN tras cambios visuales importantes (cambio de tema, actualización de imágenes de portada), dejando visible contenido antiguo durante el periodo de TTL configurado.

Preguntas frecuentes

¿Un CDN acelera todo mi Moodle o solo parte de él? Solo acelera el contenido estático (imágenes, CSS, JS, fuentes); las páginas dinámicas generadas por PHP en cada petición siguen sirviéndose directamente desde tu servidor de origen.

¿Necesito un CDN si todos mis alumnos están en la misma ciudad que el servidor? El beneficio será mucho más limitado que en una instalación con alumnado distribuido geográficamente, donde la reducción de latencia es más perceptible.

¿Qué pasa si el CDN cachea contenido dinámico por error? Puede mostrar contenido desactualizado o comportamiento inconsistente en formularios y sesiones, por eso es fundamental excluir explícitamente las rutas PHP de la configuración de caché.

¿Cómo purgo la caché del CDN tras un cambio visual? La mayoría de proveedores de CDN ofrecen una opción de purga manual de caché desde su panel, recomendable ejecutar tras cualquier cambio significativo de tema o imágenes.

¿El CDN mejora la experiencia en móvil? Sí, especialmente para alumnos con conexiones móviles de ancho de banda variable, donde cada recurso servido desde un nodo cercano reduce el tiempo total de carga de la página.

¿Cuánto cuesta implementar un CDN para Moodle? Existen opciones con niveles gratuitos suficientes para instalaciones pequeñas y medianas, aunque instalaciones con mucho volumen de tráfico estático pueden beneficiarse de planes de pago con más capacidad y funciones.

¿Necesito cambiar algo en Moodle para usar un CDN? Generalmente el CDN se configura a nivel de DNS y servidor web, sin requerir cambios específicos dentro de la configuración interna de Moodle, más allá de asegurar que las rutas dinámicas queden excluidas del cacheo. Sí conviene tener el modo diseñador de temas desactivado y slasharguments activado, para que Moodle emita cabeceras de caché correctas y URLs limpias que el CDN cachea mejor.

¿Puede un CDN filtrar archivos privados de un alumno a otro? Sí, si se configura mal. Los archivos que Moodle sirve por pluginfile.php llevan control de acceso: cachearlos a ciegas en el CDN haría que la primera respuesta guardada se sirviera a cualquiera que pida esa URL, saltándose los permisos. Por eso hay que excluir del cacheo todas las rutas .php y verificar que pluginfile.php nunca marca HIT de caché.

¿Sirve un CDN si mi Moodle va lento pero todos mis alumnos están en la misma región? Poco. Con el alumnado concentrado geográficamente, la latencia de red ya es baja y el CDN apenas la reduce. Si aun así va lento, el problema casi seguro está en el servidor o en la configuración de Moodle, no en la distancia, y ahí el CDN no ayuda. Conviene afinar primero el origen.

¿El CDN me sirve para cachear las páginas de curso completas? No de forma general. Una página de curso se genera según el usuario, su matrícula y su rol, así que no es cacheable como un archivo estático; cachearla mostraría a un alumno lo que ve otro. El CDN acelera los recursos estáticos que esa página incluye (tema, imágenes, fuentes), pero el HTML de la página sigue viniendo del origen en cada petición.

Conclusión

Un CDN no es una mejora universal de rendimiento, es una herramienta con un beneficio muy concreto (contenido estático servido más cerca del usuario) que se nota mucho en instalaciones con alumnado disperso geográficamente, y mucho menos en centros con audiencia concentrada. Configurarlo bien, excluyendo explícitamente las rutas dinámicas de PHP, es la diferencia entre una mejora real de velocidad y un problema de contenido desactualizado.

Si prefieres que alguien evalúe si tu caso concreto justifica un CDN y lo configure correctamente, en Avantys lo incluimos como parte de la optimización de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.

Artículos relacionados

• Mantenimiento y hosting Moodle: guía completa
• Por qué mi Moodle va lento: causas más comunes
• Moodle en móvil: cómo mejorar la experiencia
• Requisitos de servidor para Moodle (CPU, RAM, disco)

---