Ein CDN hält Kopien Ihrer Dateien an vielen Orten und bedient jeden Besucher vom nächstgelegenen aus. Das beseitigt Entfernung, und Entfernung ist real: Eine Anfrage aus Kairo an einen Server in Deutschland kostet rund 60 ms, bevor überhaupt etwas berechnet wird — und zwar bei jeder einzelnen Datei.

Was es wirklich behebt

  • Die Latenz bei statischen Dateien — Bildern, CSS, JavaScript, Schriften — für Besucher weit weg von Ihrem Server.
  • Bandbreitenspitzen, weil der Ursprung jede Datei einmal ausliefert statt einmal pro Besucher.
  • Einen groben, aber wirksamen Schild gegen Traffic-Fluten.
  • Den TLS-Handshake, der beim Besucher stattfindet statt über einen Ozean hinweg.

Was es nicht behebt

  • Eine langsame Abfrage. Das HTML kommt weiterhin von Ihrem Server, und es ist weiterhin langsam.
  • Eine Seite, die sich nicht zwischenspeichern lässt, weil sie persönlich für den Besucher ist.
  • Einen ersten Aufruf an einem kalten Knoten, der die volle Strecke ohnehin bezahlt.

Was es verdeckt

Das ist der Teil, der Menschen Zeit kostet. Mit einem CDN davor sind Ihre eigenen Tests schnell, weil Sie immer wieder eine zwischengespeicherte Kopie treffen, während ein angemeldeter Kunde auf einer nicht cachebaren Seite die echte, langsame Antwort bekommt. Messen Sie direkt am Ursprung, wenn Sie einen Engpass suchen.

curl -sS -o /dev/null -w 'origin ttfb %{time_starttransfer}\
' \
     --resolve yourdomain.com:443:203.0.113.10 https://yourdomain.com/

Zwei Dinge, die vom ersten Tag an stimmen müssen

  • Die echte Besucher-IP. Jedes Protokoll und jede Ratenbegrenzung sieht das CDN, solange Sie es nicht einrichten — siehe Cloudflare und die echte Besucher-IP.
  • Das Leeren des Caches. Wissen Sie, wie man eine einzelne Datei und wie man alles leert — bevor ein Deployment es braucht.
Setzen Sie kein CDN vor ein Verwaltungspanel oder eine API, die sich über einen Header authentifiziert. Zwischenspeichern ist dort ein Datenleck, kein Geschwindigkeitsgewinn.