Content Delivery Networks nur bei echtem Nutzen

Der bekannteste Vorteil eines CDN existiert seit 2020 nicht mehr. Bis dahin galt die Rechnung: Wer jQuery über ein öffentliches CDN einbindet, profitiert davon, dass die Datei beim Besucher schon von einer anderen Website im Browser-Cache liegt. Genau diesen geteilten Cache haben die Browser abgeschafft. Chrome partitioniert den HTTP-Cache seit Version 86 pro aufgerufener Website, Safari trennt noch länger, Firefox zog kurz darauf nach. Dieselbe Datei wird heute für jede Domain neu geladen. Der Vorteil ist weg, der Umweg über den fremden Server ist geblieben. Das W3C hat daraus Konsequenzen gezogen: Die Guideline hieß früher „CDNs angemessen einsetzen“ und hatte fünf Erfolgskriterien. Heute heißt sie „CDNs einsetzen, wenn sie nützen“ und hat drei.

Info

Die drei Erfolgskriterien von Guideline 4.10 (meine Übersetzung des Originals):

Globale CDNs: Nutze ein Content Delivery Network (CDN) für statische Inhalte, Assets und andere nur lesend genutzte Ressourcen ausschließlich dort, wo es klare Vorteile bringt. Bewerte dabei Performance-Gewinne und Umweltwirkung im Einzelfall und im Einklang mit Deinen übrigen Hosting-Entscheidungen. Wenn Du ausschließlich ein lokales Publikum bedienst, prüfe, ob ein CDN überhaupt notwendig ist, und bevorzuge stattdessen geografisch nahes Hosting.

Nachhaltigkeitsverpflichtung: Wähle CDN-Anbieter, die glaubwürdige und belegbare Verpflichtungen zur Nachhaltigkeit im Web nachweisen.

Ungeeignete Ressourcen: Vermeide es, dynamische oder häufig wechselnde Ressourcen über ein CDN auszuliefern. Browser-Mechanismen wie Cache-Partitionierung und Cross-Origin Resource Sharing (CORS) können die Caching-Vorteile und die Interaktionsperformance begrenzen und dadurch die Ressourceneffizienz verschlechtern, während Umgehungslösungen Sicherheits- oder Datenschutzrisiken erzeugen können.

Meine Einordnung

Auffällig ist die Sprache. Kein „nutze ein CDN“, sondern „ausschließlich dort, wo es klare Vorteile bringt“. Der Leitsatz der Guideline formuliert es noch schärfer: strategisch einsetzen, nur wenn Effizienz und Nachhaltigkeit dadurch besser werden, und unnötige Verteilung vermeiden. Das ist keine Empfehlung, das ist eine Beweislastumkehr. Nicht das Weglassen muss begründet werden, sondern der Einsatz.

Rechne das für Deine Seite durch. Ein Roundtrip von Deutschland nach Virginia kostet typischerweise um die 90 Millisekunden, innerhalb Deutschlands liegst Du unter 20. Diese Differenz ist real, und ein CDN beseitigt sie. Nur entsteht sie überhaupt erst, wenn Server und Publikum weit auseinanderliegen. Wenn 90 Prozent Deiner Besucher aus dem deutschsprachigen Raum kommen und Dein Server in Nürnberg oder Falkenstein steht, löst das CDN ein Problem, das Du nicht hast. Es fügt nur eine Ebene hinzu. Genau deshalb steht die Prüffrage jetzt direkt im ersten Kriterium und nicht mehr als eigener Nebenpunkt weiter hinten.

Das dritte Kriterium ist das technisch interessanteste. Cache-Partitionierung und CORS begrenzen die Gewinne ausgerechnet dort, wo viele sie vermuten. Und wer sie mit großzügigen CORS-Headern überlistet, handelt sich neue Angriffsflächen ein. Statische Bilder, Schriften und JSON-Dateien: sinnvoll. HTML aus einem CMS, personalisierte Fragmente, alles was sich stündlich ändert: fragwürdig.

Der entscheidende Punkt fehlt in der Guideline aber ganz. Ein CDN transportiert Daten schneller, es reduziert sie nicht. 1 MB weniger pro Seitenaufruf spart bei einer Million Aufrufen rund 400 Kilogramm CO₂. Ein CDN verkürzt den Weg dieses Megabytes. Gelöscht hat es noch keines.

Wo ich weiter gehe

Ich bin generell kein Freund davon, Infrastruktur an eine Blackbox auszulagern. Jedes CDN ist ein zusätzliches Ausfalltor. Wenn ein großer Anbieter Probleme hat, sind binnen Minuten Zehntausende Websites nicht erreichbar, obwohl jeder einzelne Ursprungsserver einwandfrei läuft. Das ist in den vergangenen Jahren mehrfach passiert, und es wird wieder passieren. Verfügbarkeit, die Du nicht selbst kontrollierst, ist geliehene Verfügbarkeit.

Dazu kommt die Kontrollfrage. Nicht ohne Grund führt die aktuelle Fassung als neue Schlagworte ausgerechnet KI und Barrierefreiheit. Mehrere große Anbieter blockieren KI-Crawler inzwischen standardmäßig, teilweise mit Bezahlmodellen für den Zugriff. Diese Entscheidung trifft der Anbieter, nicht Du. Wer nicht weiß, was in seiner Edge-Konfiguration steht, weiß auch nicht mehr, wer seine Inhalte überhaupt noch lesen darf.

Achtung
Ein CDN entscheidet mit, wer Deine Inhalte bekommt. Blockierte KI-Crawler, aggressive Bot-Regeln oder ein Challenge-Screen vor jedem Abruf sind Voreinstellungen des Anbieters, keine Naturgesetze. Prüfe nach jeder Aktivierung, welche Crawler noch durchkommen. Sonst verschwindest Du unbemerkt aus genau den Antworten, in denen Du vorkommen wolltest.

Wer seine Seite konsequent optimiert, braucht das alles seltener. Statisch generiertes HTML, saubere Cache-Header, komprimierte Bilder, keine Fremdskripte: Dann liefert ein einzelner Server in Deutschland Antwortzeiten, für die andere ein weltweites Edge-Netz aufziehen. Effizienz kauft man ein, Suffizienz baut man sich. Der schnellste Edge-Knoten ist der, der nichts ausliefern muss.

Dein erster Schritt heute

Bevor Du über ein CDN nachdenkst, brauchst Du zwei Zahlen: woher Deine Besucher kommen und wie schnell Dein Server ihnen antwortet.

Tipp
Schau in Deine Statistik und notiere den Anteil der Zugriffe aus Deutschland, Österreich und der Schweiz. Miss dann mit PageSpeed Insights die Serverantwortzeit. Liegt der DACH-Anteil über 80 Prozent und die Antwortzeit unter 200 Millisekunden, brauchst Du kein CDN, sondern kleinere Seiten. Liegst Du unter 60 Prozent DACH mit echtem internationalem Publikum, sieht die Rechnung anders aus.

Und wenn Du Dich für ein CDN entscheidest, dann bewusst: nur für statische Assets, mit einem Anbieter, der seine Emissionen belegbar offenlegt, und mit einer Konfiguration, die Du selbst gelesen hast.

Ein CDN verkürzt den Weg der Daten. Erspart wird der Weg nur durch Daten, die gar nicht erst entstehen.

Quelle: W3C-Fassung von Guideline 4.10