Weg A oder Weg B? Manchmal ist der kürzeste Weg zum Ziel der über einen Umweg.

Einleitung

Du baust eine Seite, die halbwegs gut lädt — und dann kommt der erste Kommentar aus Neuseeland: „Hier braucht der Header vier Sekunden.” Dein Server steht in einem Rechenzentrum in Frankfurt. Der physikalische Abstand ist kein Bug, er ist Gesetz. Ab hier teilt sich die Welt in zwei Lager: Werfe ein CDN davor, oder lass den Ursprung (Origin) die Arbeit machen. Beides funktioniert. Die Frage ist, wo du Komplexität kaufst und wo du sie sparst.

Ich habe beides in Produktion gefahren. Ein CDN ist kein Magie-Würfel, der alles schnell macht, und ein nackter Nginx ist kein Armutsvorrat, der automatisch langsam ist. Die Entscheidung hängt von Cache-Fähigkeit, Traffic-Profil und davon ab, wer nachts den Pager bekommt.

Kontext

Was auf dem Spiel steht: Latenz für geografisch verteilte Nutzer, Auslastungsspitzen beim Origin, Kosten pro Gigabyte ausgelieferter Bytes und die Fehleroberfläche, die du pflegen musst.

Constraints:

• Statische Inhalte (Bilder, CSS, JS, das gebaute dist/) dominieren das Volumen.
• Ein kleines Team, keine dedizierte SRE-Rolle.
• Budgetbewusst: „nie mehr können als nötig.”

Non-Goals:

• Kein Schutz vor DDoS als Primärziel (das ist ein Nebeneffekt, keine Entscheidung hier).
• Kein Video-Streaming mit Millionen gleichzeitiger Sessions.

Weg A: Origin direkt, dafür richtig konfiguriert

Der Ursprungsserver liefert alles selbst. Der Trick ist nicht Hardware, sondern Header. Ein sauber konfigurierter Nginx mit Cache-Control und Gzip/Brotli schafft für ein kleines Publikum oft genug.

server {
    listen 443 ssl;
    server_name redpandamonium.de;

    # Statische Assets: ein Jahr, immutable
    location /_astro/ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # HTML niemals cachen — sonst sieht der User den neuen Post nicht
    location / {
        try_files $uri $uri/ /index.html;
        add_header Cache-Control "no-cache";
    }

    brotli on;
    gzip on;
}

Pros: Keine zusätzliche Abstraktion, DNS zeigt direkt auf deine IP, Fehler sind lokal nachvollziehbar. Cons: Geografische Latenz bleibt, ein Traffic-Spike trifft direkt deinen Server, TLS-Ende und Zertifikats-Rollover liegen bei dir.

Weg B: CDN davor, Origin nur als Quelle

Ein CDN (Cloudflare, Bunny, jsDelivr, Fastly) terminiert TLS, cached am Edge und liefert aus der nächsten PoP. Dein Origin sieht nur noch Cache-Misses.

# Origin vertraut nur dem CDN, nicht dem offenen Internet
server {
    listen 443 ssl;
    server_name origin.redpandamonium.de;

    # Nur die IP-Ranges des CDN dürfen rein (Beispiel Platzhalter)
    allow 185.199.108.0/22;
    deny all;

    location / {
        try_files $uri $uri/ /index.html;
        add_header Cache-Control "public, max-age=60, stale-while-revalidate=300";
    }
}

Pros: Niedrige Latenz weltweit, DDoS-Dämpfung, der Origin atmet bei Spikes. Cons: Ein weiteres System im Pfad, Cache-Invalidation ist eine eigene Disziplin, und beim Debuggen fragst du dich manchmal, ob das Edge gerade deine neue CSS liefert oder die von vorgestern.

Entscheidung

Ich entscheide pro Projekt, nicht dogmatisch. Für redpandamonium.de, einer statischen Seite mit einem kleinen, aber geografisch verstreuten Publikum, ist Weg B (CDN) die bessere Wahl — aber als dünne Schicht, nicht als Plattform.

Die Trade-offs, die ich bewusst eingehe:

• Ich akzeptiere eine maximale Propagierungslatenz von Sekunden bis Minuten nach einem Deploy (kalkulierbar, weil HTML no-cache/max-age=60 ist).
• Ich verzichte auf komplexe Edge-Compute-Logik. Das CDN cached, mehr nicht.
• Der Origin bleibt weiterhin das alleinige Wahrheitszentrum; das CDN ist nur ein schneller Spiegel.

Implementierung

Die praktische Kombination: Origin liefert mit klaren Headern, das CDN cached aggressiv für Assets und kurz für HTML. Nach dem cp -a dist/. /var/www/redpandamonium.de/ ist der Origin aktualisiert; das CDN zieht die neuen Dateien beim nächsten Request. Entscheidend ist, dass Asset-Pfade (hier /_astro/) fingerprinted sind — Astro macht das automatisch, daher kann das CDN ein Jahr cachen, ohne dass Nutzer alte Versionen sehen.

Der Pager-Alarm reduziert sich, weil Spikes im CDN enden. Der Origin braucht kaum noch Kapazität. Das ist der Gewinn: nicht „schneller”, sondern „weniger wach”.

Fazit

CDN oder Origin ist keine Glaubensfrage. Wenn dein Publikum lokal bleibt und dein Traffic überschaubar ist, ist ein sauber konfigurierter Origin (Weg A) die ehrliche Wahl. Sobald die Karte größer wird als dein Rechenzentrum, holt Weg B den Punkt, an dem die Latenz messbar weh tut. Mess es: curl -sI https://deine-domain/ | grep -i cache-control sagt dir mehr über deine Architektur als jeder Blogpost.

Meine Metrik nach dem Umzug: Time-to-First-Byte für entfernte Nutzer von ~400 ms auf ~40 ms. Der Preis war eine zusätzliche DNS-Ebene und ein Invalidation-Gedanken, den ich vorher nicht hatte. Würde ich es wieder tun? Für diese Seite: ja. Für den internen Toolserver im selben Rack: nein.

Offene Frage an euch: Wo zieht ihr die Linie — ab wie vielen geografisch verteilten Nutzern lohnt sich das CDN für euch, und welche Cache-Invalidation-Strategie nutzt ihr, ohne dass euch nach jedem Deploy der kalte Schweiß kommt?

Siehe auch:

• Weg A oder Weg B: Selbst gehostet oder managed?
• Weg A oder Weg B: SQLite oder PostgreSQL
• Nginx oder Caddy? Eine Architekturentscheidung