Cómo usar un CDN para acelerar los assets del sitio de tu servidor de MU Online

Un servidor de MU Online vive y muere por la primera impresión del sitio: si la página tarda en cargar o la descarga del cliente se traba, el jugador desiste antes incluso de instalar el juego. Un CDN (Content Delivery Network) resuelve esto distribuyendo copias de tus archivos estáticos —imágenes, CSS, JavaScript, fuentes y hasta el instalador del cliente— en servidores repartidos geográficamente, cerca del jugador. El resultado es una carga más rápida, menos carga en tu servidor de origen y resiliencia frente a picos de acceso en lanzamientos y eventos. Este tutorial muestra cómo elegir un CDN, configurar el DNS, separar los assets estáticos de la aplicación dinámica y medir la ganancia real de rendimiento.

Por qué un CDN importa para un servidor de MU

El sitio de un servidor privado tiene un patrón de tráfico irregular: prácticamente vacío la mayor parte del tiempo y un pico brutal el día del lanzamiento (open beta, wipe, temporada nueva). Sin CDN, todo ese pico golpea directamente al servidor de origen —el mismo que tal vez corre el panel, el foro y hasta la base de datos del juego. Un CDN absorbe ese pico sirviendo los archivos estáticos desde una caché de borde (edge), sin llegar nunca a tu origen. Esto es especialmente crítico para el instalador del cliente, que puede pesar de 2 a 6 GB y ser descargado por cientos de personas en la misma hora.

Anatomía de los assets de un sitio de MU

No todo en el sitio necesita (o debe) pasar por el CDN de la misma forma. Vale la pena separar por tipo:

Mezclar todo en el mismo balde de caché es el error más común: cachear la página de ranking por un día deja el marcador visiblemente incorrecto, y eso mina la confianza de los jugadores en el sitio.

Eligiendo el proveedor de CDN

Para la mayoría de los servidores de MU, tres opciones cubren prácticamente todos los escenarios:

Cloudflare suele ser el punto de partida por ser gratuito y cubrir DNS, proxy y caché en un único panel. Bunny CDN entra en juego cuando el volumen de descarga del cliente ya es alto y el costo por GB de Cloudflare (en planes avanzados) empieza a pesar.

Paso 1 — Separar el dominio del sitio del dominio de descargas (opcional, pero recomendado)

Una práctica común es usar un subdominio dedicado para archivos estáticos, por ejemplo cdn.tuservidor.com o dl.tuservidor.com, apuntando a un bucket de objetos. Esto evita que el tráfico de descarga del cliente compita con las solicitudes del sitio principal y facilita configurar reglas de caché diferentes por subdominio.

sitio principal:  tuservidor.com          -> hosting del sitio (PHP/Node)
CDN de assets:     cdn.tuservidor.com     -> bucket + CDN (imágenes, CSS, JS)
descargas:        dl.tuservidor.com       -> bucket + CDN (cliente, parches)

Paso 2 — Apuntar el DNS y activar el proxy

En el panel de Cloudflare, agrega el dominio, apunta los registros A/CNAME a tu servidor de origen y activa el modo proxy (nube naranja) en los registros que deben pasar por el CDN. Los registros usados solo para correo o servicios internos deben quedar en modo DNS-only (nube gris), sin proxy.

Tipo   Nombre            Contenido             Proxy
A      tuservidor.com    203.0.113.10          Activado (naranja)
CNAME  www               tuservidor.com        Activado (naranja)
CNAME  cdn               bucket.ejemplo.com    Activado (naranja)
A      mail              203.0.113.11          Desactivado (gris)

Paso 3 — Configurar reglas de caché por tipo de contenido

En la sección de Page Rules o Cache Rules del CDN, crea reglas específicas en vez de confiar solo en la caché por defecto:

Regla 1: cdn.tuservidor.com/*
  Cache Level: Cache Everything
  Edge Cache TTL: 30 días

Regla 2: tuservidor.com/ranking*
  Cache Level: Bypass

Regla 3: tuservidor.com/api/*
  Cache Level: Bypass

Estas tres reglas ya cubren lo esencial: todo lo estático cachea de forma agresiva, todo lo dinámico (ranking, API) nunca es cacheado por el CDN.

Paso 4 — Alojar el cliente para descarga en un bucket de objetos

Subir el instalador del cliente directamente en la misma VPS que corre el sitio es un error común: además de consumir disco y ancho de banda del origen, un pico de descargas puede tumbar el servicio web. Migra el archivo a un bucket (Cloudflare R2, Backblaze B2, S3) y sírvelo mediante el CDN:

# ejemplo con AWS CLI compatible (R2/B2 usan la misma interfaz S3)
aws s3 cp mu-client-setup.exe s3://mi-bucket-mu/downloads/ \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com \
  --acl public-read

Luego, apunta un enlace del sitio a https://dl.tuservidor.com/downloads/mu-client-setup.exe, y el CDN se encarga de la distribución sin tocar tu servidor de origen.

Paso 5 — Cache busting para CSS y JS

Para evitar que el jugador vea una versión antigua del sitio después de un deploy, versiona los archivos estáticos por query string o hash en el nombre:

<link rel="stylesheet" href="/assets/style.css?v=20260731">
<script src="/assets/app.js?v=20260731"></script>

Cada vez que hagas deploy de cambios visuales, incrementa la versión. Esto es más confiable que depender de un purge manual de la caché, que suele olvidarse.

Paso 6 — Comprimir y optimizar antes de subir al CDN

El CDN acelera la entrega, pero no reemplaza la optimización de origen. Antes de subir imágenes y scripts:

• Comprime imágenes (WebP/AVIF cuando sea posible) — reduce hasta un 70% del tamaño sin pérdida visible.
• Minifica CSS y JS (elimina espacios, comentarios, código muerto).
• Activa Brotli o Gzip en el CDN para HTML/CSS/JS (la mayoría ya lo hace automáticamente).

Paso 7 — Medir la ganancia real

Usa herramientas de prueba de rendimiento antes y después de activar el CDN, comparando el mismo conjunto de páginas:

Los números varían según el servidor, pero la dirección es siempre la misma: menos carga en el origen y respuesta más rápida para el jugador, especialmente en picos.

Paso 8 — Configurar SSL/TLS correctamente

Activa el modo Full (Strict) de SSL en el CDN, garantizando que la conexión entre el CDN y tu servidor de origen también esté cifrada, no solo entre el CDN y el jugador. Esto evita advertencias de mixed content y mantiene el certificado válido de punta a punta.

Errores comunes y soluciones

Lista de verificación de configuración de CDN

• Dominio agregado al CDN con proxy activado en los registros web.
• Assets estáticos separados por subdominio o carpeta dedicada.
• Reglas de caché diferenciadas para estático, dinámico y API.
• Cliente para descarga migrado a un bucket de objetos.
• Cache busting implementado en el CSS/JS del sitio.
• SSL configurado en modo Full (Strict).
• Prueba de rendimiento hecha antes y después, con números registrados.

Con el CDN en marcha, el sitio aguanta picos de lanzamiento sin tumbar el servidor de origen —y ese mismo servidor de origen, liberado de esa carga, queda disponible para lo que realmente importa: hacer funcionar bien el servidor de MU Online y el panel administrativo.

Preguntas frecuentes