Was ist ein CDN?

Ein CDN, ein Netz zur Auslieferung von Inhalten, ist eine über die Welt verteilte Menge von Servern, die Kopien der Dateien einer Website vorhalten und sie vom nächstgelegenen Punkt ausliefern. Statt jedes Bild von einem einzigen Server zu holen, kommt es aus einem Knoten wenige Kilometer entfernt.

Der Gewinn liegt in der Entfernung. Daten reisen schnell, aber nicht sofort, und jede Runde zwischen Kontinenten kostet spürbar Zeit — besonders beim TTFB. Den Weg zu verkürzen ist der unmittelbarste Weg, ihn zu senken.

Neben dem Näherbringen der Dateien tun fast alle CDN zwei weitere Dinge: Sie fangen Spitzen im Traffic ab, die den Ursprungsserver umwerfen würden, und sie filtern bösartige Anfragen, bevor sie ankommen. Für viele Websites wiegt diese zweite Aufgabe so schwer wie die Geschwindigkeit.

Es gehört von zwei Dingen getrennt, mit denen es verwechselt wird. Es ist kein Hosting: Die Website lebt weiter auf einem Ursprungsserver, und das CDN steht davor. Und es ist keine Sicherung: Verschwindet der Ursprung, liefern die Knoten aus, was sie gespeichert haben, bis es abläuft — danach ist nichts mehr da.

Es muss auch nicht als eigenes Produkt gebucht werden. Viele Hoster liefern es mit, und manche CMS schalten es mit einem Häkchen ein. Das ist bequem und hat eine Falle: Wer es nicht selbst einrichtet, weiß leicht nicht, was gespeichert wird und wie lange — genau die beiden Fragen, auf die es ankommt.

Hier steckt die Einzelheit, an die kaum jemand denkt: Mit einem CDN davor gibt es nicht mehr die eine Antwort. Sie hängt davon ab, von wo gefragt wird, ob dieser Knoten eine Kopie hatte und wie lange er sie schon hat.

Für den Besucher ist das meist gut. Für den, der misst, nicht immer: Der Crawler von Google fragt von woanders und zu anderer Zeit, kann also eine andere Fassung bekommen als deine Kundschaft — eine schnellere oder eine langsamere.

Google sagt es in seiner Dokumentation zu mehrregionalen Websites unumwunden: Die meisten seiner Crawls kommen aus den Vereinigten Staaten, und es variiert den Standort nicht absichtlich, um Unterschiede zu entdecken. Wer je nach Region anderes ausliefert, muss das ausdrücklich kennzeichnen, statt darauf zu vertrauen, dass die Suchmaschine es bemerkt.

Ein dritter Umstand verändert die Antwort und steht in keiner Übersicht: der Zeitpunkt. Ein Knoten, der seine Kopie gerade verworfen hat, antwortet auf die erste Anfrage langsam und auf die folgenden schnell — zwei Messungen im Abstand von Minuten können also Gegenteiliges ergeben, ohne dass sich etwas geändert hat.

Deshalb sagt eine einzelne Prüfung wenig. Die Felddaten der Search Console und der Werkzeuge zu den Core Web Vitals mitteln echte Besuche über Wochen und sind hier deshalb mehr wert als jede Einzelmessung von einem Standort aus.

Ein CDN beschleunigt, was sich speichern lässt: Bilder, Stilvorlagen, Schriften, Dateien, die sich zwischen Besuchern nicht ändern. Das verbessert den Teil des Ladens, der am Netz hängt, und mit ihm Werte wie den LCP, wenn das größte Element ein Bild ist.

Was es von allein nicht beschleunigt, ist die Zeit, die der Ursprungsserver zum Bauen einer Seite braucht. Wird das HTML bei jeder Anfrage neu erzeugt, reicht das CDN die Frage nur weiter und wartet genauso, wie der Browser warten würde. Ein E-Commerce-Shop, der wegen schwerer Abfragen langsam ist, wird durch ein CDN also nicht schnell.

Dort sitzt die verbreitetste Verwechslung: Man erwartet eine Wirkung auf die Core Web Vitals, die erst eintritt, wenn zusätzlich das HTML im Knoten selbst gespeichert wird. Das ist möglich und wird gemacht, ist aber eine eigene Entscheidung mit eigenen Regeln darüber, welche Inhalte sich Besucher teilen dürfen und welche nicht.

Ein Blick auf die mobile Seite lohnt, denn dort wiegt die Entfernung am schwersten. Auf einer langsamen Verbindung kostet jede Runde deutlich mehr als über Glasfaser, ein kürzerer Weg zeigt sich also auf dem Mobilgerät früher als am Schreibtisch. Ein Argument für das CDN, das kaum genannt wird und meist das stärkste ist.

Und eine Genauigkeit zu Bildern: Viele CDN wandeln und verkleinern sie im Vorbeigehen. Das hilft wirklich, ist aber eine eigene Funktion neben der Verteilung, und man prüft besser, ob das Ergebnis den Alternativtext und die im HTML angegebenen Maße behält — gehen sie verloren, kommt der Layoutsprung zurück, den der CLS misst.

Zuerst gehört geprüft, dass die Header den Weg über den Knoten überleben. Manche Konfigurationen reichen nur eine bekannte Auswahl weiter und verwerfen den Rest — dann existiert eine Anweisung wie das X-Robots-Tag am Ursprung und erreicht den Crawler nie. Geprüft wird an der öffentlichen URL, nicht an der internen.

Zweitens die Protokolle. Mit einem CDN davor sieht der Ursprungsserver die meisten Anfragen nicht mehr, eine dort gemachte Logfile-Analyse bleibt also unvollständig; brauchbar sind dann die Protokolle des CDN selbst.

Und drittens die Adressen. Werden die statischen Dateien künftig von einer anderen Domain ausgeliefert, sollten Zertifikat und Pfade stabil bleiben, denn jeder Domainwechsel zieht Verweise im alten HTML, in fremden Verlinkungen und in der Bilder-Sitemap hinter sich her.

Ein vierter Punkt wird vergessen: die Weiterleitungen. Viele CDN erlauben, sie im Knoten selbst zu definieren, was schnell und bequem ist und mit der Zeit zwei Regellisten erzeugt — eine im CDN, eine am Ursprung —, die niemand vergleicht. Dort entstehen die am schwersten auffindbaren Weiterleitungsketten, weil jede Hälfte für sich richtig aussieht.

Und ein Rat zur Arbeitsweise: Halte fest, was gespeichert wird, wie lange und wer es verwerfen darf. Das ist eine Einstellung, die einmal gesetzt und jahrelang geerbt wird; ohne diese Notiz sucht der Nächste, der eine veraltete Seite sieht, die Ursache stundenlang im CMS, bevor er den Knoten verdächtigt.

Der erste ist, es zu buchen in der Erwartung, es behebe eine Langsamkeit, die nicht vom Netz kommt. Braucht der Ursprung lange zum Antworten, liefert das CDN die Bilder früher und der Besucher wartet weiter auf das HTML.

Der zweite ist, zu speichern, was nicht gespeichert gehört. Eine Seite mit Benutzernamen, Warenkorb oder persönlichen Preisen aus dem Zwischenspeicher zeigt am Ende jemandem die Daten eines anderen; das ist ein Datenschutzfehler, kein Leistungsproblem, und er kommt häufiger vor, als man denkt.

Und der dritte ist, das Verwerfen zu vergessen. Behält der Knoten tagelang eine alte Fassung, erreichen veröffentlichte Änderungen weder Besucher noch Crawler — und das wird fast immer falsch gedeutet: Man sucht die Ursache bei der Indexierung, während der neue Inhalt schlicht nicht ausgeliefert wird.

Ein vierter Fehler ist, es für eine endgültige Entscheidung zu halten. Knoten, Regeln und Tarife ändern sich, und eine Konfiguration, die vor drei Jahren gut war, speichert womöglich Dinge, die sie nicht mehr speichern sollte. Sie verdient eine jährliche Durchsicht wie jedes andere Stück Infrastruktur.

Und der letzte, leiseste: nie von außerhalb des Büros zu prüfen. Das ganze Team arbeitet aus derselben Stadt, über dieselbe Leitung und vermutlich am selben warmen Knoten; die dort gemessene Erfahrung ist die beste aller möglichen. Der echte Traffic kommt von Orten, die niemand aus dem Team je ausprobiert hat.