How to Use a CDN to Speed Up Your MU Online Server Website's Assets

An MU Online server lives and dies by its website's first impression: if the page takes too long to load or the client download stalls, the player gives up before even installing the game. A CDN (Content Delivery Network) solves this by distributing copies of your static files — images, CSS, JavaScript, fonts, and even the client installer — across geographically spread servers, closer to the player. The result is faster loading, less load on your origin server, and resilience against traffic spikes during launches and events. This tutorial shows how to choose a CDN, set up DNS, separate static assets from the dynamic application, and measure the real performance gain.

Why a CDN matters for an MU server

A private server's website has an irregular traffic pattern: practically empty most of the time, with a brutal spike on launch day (open beta, wipe, new season). Without a CDN, that entire spike hits the origin server directly — the same one that may also run the panel, the forum, and even the game database. A CDN absorbs that spike by serving static files from an edge cache, never reaching your origin. This is especially critical for the client installer, which can be 2 to 6 GB and get downloaded by hundreds of people within the same hour.

Anatomy of an MU website's assets

Not everything on the site needs (or should) go through the CDN the same way. It's worth splitting by type:

Mixing everything into the same cache bucket is the most common mistake: caching the ranking page for a day leaves the leaderboard visibly wrong, which erodes players' trust in the site.

Choosing a CDN provider

For most MU servers, three options cover practically every scenario:

Cloudflare is usually the starting point since it's free and covers DNS, proxying, and cache in a single dashboard. Bunny CDN comes in when client download volume is already high and Cloudflare's per-GB cost (on advanced plans) starts to add up.

Step 1 — Separate the site domain from the download domain (optional, but recommended)

A common practice is to use a dedicated subdomain for static files, for example cdn.yourserver.com or dl.yourserver.com, pointing to an object bucket. This prevents client download traffic from competing with requests to the main site and makes it easier to set different cache rules per subdomain.

main site:       yourserver.com          -> site hosting (PHP/Node)
asset CDN:       cdn.yourserver.com       -> bucket + CDN (images, CSS, JS)
downloads:       dl.yourserver.com        -> bucket + CDN (client, patches)

Step 2 — Point DNS and enable the proxy

In the Cloudflare dashboard, add the domain, point the A/CNAME records to your origin server, and enable proxy mode (orange cloud) on the records that should go through the CDN. Records used only for email or internal services should stay in DNS-only mode (gray cloud), without proxying.

Type   Name              Content               Proxy
A      yourserver.com    203.0.113.10          Enabled (orange)
CNAME  www               yourserver.com        Enabled (orange)
CNAME  cdn               bucket.example.com    Enabled (orange)
A      mail              203.0.113.11          Disabled (gray)

Step 3 — Configure cache rules by content type

In the CDN's Page Rules or Cache Rules section, create specific rules instead of relying solely on the default cache:

Rule 1: cdn.yourserver.com/*
  Cache Level: Cache Everything
  Edge Cache TTL: 30 days

Rule 2: yourserver.com/ranking*
  Cache Level: Bypass

Rule 3: yourserver.com/api/*
  Cache Level: Bypass

These three rules already cover the essentials: everything static caches aggressively, everything dynamic (ranking, API) is never cached by the CDN.

Step 4 — Host the downloadable client in an object bucket

Uploading the client installer directly to the same VPS that runs the site is a common mistake: besides consuming origin disk space and bandwidth, a download spike can take down the web service. Move the file to a bucket (Cloudflare R2, Backblaze B2, S3) and serve it through the CDN:

# example using S3-compatible AWS CLI (R2/B2 use the same S3 interface)
aws s3 cp mu-client-setup.exe s3://my-mu-bucket/downloads/ \
  --endpoint-url https://<account-id>.r2.cloudflarestorage.com \
  --acl public-read

Then point a link on the site to https://dl.yourserver.com/downloads/mu-client-setup.exe, and the CDN handles distribution without touching your origin server.

Step 5 — Cache busting for CSS and JS

To prevent players from seeing an outdated version of the site after a deploy, version your static files via query string or hash in the filename:

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

Whenever you deploy visual changes, bump the version. This is far more reliable than relying on manual cache purges, which tend to get forgotten.

Step 6 — Compress and optimize before uploading to the CDN

A CDN speeds up delivery, but it doesn't replace origin-side optimization. Before uploading images and scripts:

• Compress images (WebP/AVIF when possible) — cuts up to 70% of size with no visible loss.
• Minify CSS and JS (strip whitespace, comments, dead code).
• Enable Brotli or Gzip on the CDN for HTML/CSS/JS (most CDNs already do this automatically).

Step 7 — Measure the real gain

Use performance testing tools before and after enabling the CDN, comparing the same set of pages:

The numbers vary by server, but the direction is always the same: less load on the origin and faster responses for the player, especially during spikes.

Step 8 — Configure SSL/TLS correctly

Enable Full (Strict) SSL mode on the CDN, ensuring the connection between the CDN and your origin server is also encrypted, not just between the CDN and the player. This avoids mixed content warnings and keeps the certificate valid end-to-end.

Common errors and fixes

CDN setup checklist

• Domain added to the CDN with proxy enabled on web records.
• Static assets separated by subdomain or dedicated folder.
• Differentiated cache rules for static, dynamic, and API content.
• Downloadable client migrated to an object bucket.
• Cache busting implemented for the site's CSS/JS.
• SSL configured in Full (Strict) mode.
• Performance test done before and after, with numbers recorded.

With the CDN live, the site can withstand launch spikes without taking down the origin server — and that same origin server, freed from that load, stays available for what really matters: running your MU Online server and admin panel smoothly.

Frequently asked questions