Content Delivery Networks (CDNs) versprechen schnellere Ladezeiten durch geografisch verteilte Server. In der Praxis erzeugt jeder CDN-Request eine Abhängigkeit: vom CDN-Betreiber, von dessen Verfügbarkeit, von dessen Datenschutzpraxis und von der Stabilität der gehosteten Ressourcen. Für regulierte Organisationen und KRITIS-Betreiber sind diese Abhängigkeiten ein konkretes Risiko.

Was über CDNs geladen wird

Eine Analyse typischer SaaS-Websites zeigt, dass folgende Ressourcen häufig extern gehostet werden:

Fonts: Google Fonts (fonts.googleapis.com + fonts.gstatic.com), Adobe Fonts (use.typekit.net), Font Awesome (cdnjs.cloudflare.com). Bei jedem Seitenaufruf werden zwei DNS-Lookups, zwei TCP-Verbindungen und die vollständige IP-Adresse des Nutzers an Google, Adobe oder Cloudflare übertragen.

JavaScript-Bibliotheken: jQuery, React, Lodash über cdnjs, unpkg oder jsdelivr. Diese CDNs werden von Cloudflare (US), npm/GitHub (Microsoft, US) oder jsdelivr (Open Source, aber Cloudflare-hosted) betrieben.

CSS-Frameworks: Bootstrap, Tailwind oder Normalize.css über CDN-Links. Jeder Request überträgt Nutzerdaten.

Icons: Font Awesome, Material Icons, Heroicons über CDN. Oft werden vollständige Icon-Sets geladen (200+ KB), obwohl nur 20 Icons verwendet werden.

Analytics und Tracking: Google Analytics (analytics.js), HubSpot-Tracking, Intercom-Widget, Social-Media-Pixel. Diese Skripte laden oft weitere Ressourcen nach (Cascading Dependencies).

Verfügbarkeitsrisiko

Im Juli 2019 fiel Cloudflare für 30 Minuten aus – und mit ihm Millionen von Websites, die Ressourcen über Cloudflare-CDN luden. Das Problem: Die Websites selbst waren online, aber ohne ihre CDN-gehosteten Styles, Fonts und Skripte waren sie unbenutzbar.

Jeder externe CDN-Request ist ein potenzieller Single Point of Failure. Wer vier verschiedene CDNs nutzt, hat vier potenzielle Ausfallpunkte. Self-Hosting eliminiert dieses Risiko vollständig – wenn der eigene Server läuft, laufen auch alle Assets.

Datenschutz-Risiko

Seit dem LG München-Urteil (Januar 2022) zu Google Fonts ist klar: Jeder externe Request, der die IP-Adresse des Nutzers an einen Drittanbieter überträgt, ist DSGVO-relevant. Das gilt nicht nur für Google Fonts, sondern für jeden CDN-Request.

Die meisten CDN-Betreiber sind US-Unternehmen: Cloudflare (San Francisco), Fastly (San Francisco), AWS CloudFront (Amazon, Seattle), Akamai (Cambridge, MA). Selbst wenn die Edge-Server in Europa stehen, unterliegt der Betreiber dem CLOUD Act und dem US-Recht.

Performance-Mythos

Das klassische Argument für CDNs – „Der Nutzer hat jQuery schon im Cache, weil er es von einer anderen Website geladen hat” – stimmt seit der Einführung von Cache-Partitioning in allen modernen Browsern (Chrome seit v86, Firefox, Safari) nicht mehr. Jede Domain bekommt ihren eigenen Cache-Bereich. Das CDN-jQuery wird für jede Website neu geladen.

Zudem eliminiert Self-Hosting den Overhead für DNS-Lookup, TCP-Handshake und TLS-Negotiation für jeden externen Host. Mit HTTP/2 werden alle Ressourcen vom eigenen Server über eine einzige Verbindung ausgeliefert – oft schneller als die Summe der CDN-Requests.

Eliminierungsstrategie

Ressource
CDN-Quelle
Self-Hosted Alternative
Aufwand
Fonts
Google Fonts
WOFF2 in /fonts/ + @font-face
2 Stunden
Icons
Font Awesome CDN
SVG Sprite oder einzelne SVGs
4 Stunden
CSS Framework
CDN-Link
npm install + Build
1 Stunde
JS Libraries
unpkg/cdnjs
npm install + Bundle
1 Stunde
Analytics
Google Analytics
Plausible Cloud (EU)
2 Stunden
Maps
Google Maps Embed
MapLibre + eigene Tiles
2–5 Tage
Video
YouTube Embed
Bunny Stream / Self-Hosted
1–3 Tage

Der Großteil der CDN-Abhängigkeiten (Fonts, Icons, CSS, JS) lässt sich in einem Arbeitstag eliminieren. Maps und Video-Embeds erfordern mehr Aufwand, sind aber die Bereiche mit dem höchsten Datenübertragungsrisiko.

Automatisierte Erkennung

CDN-Abhängigkeiten können automatisiert erkannt werden: Browser DevTools (Network Tab) zeigt alle externen Requests. Lighthouse-Audits listen Third-Party-Requests mit Größe und Ladezeit. Tools wie bundlewatch oder webpack-bundle-analyzer identifizieren CDN-Imports im Build-Prozess. Ein Content Security Policy (CSP) Header kann als Monitoring-Tool genutzt werden, um neue externe Requests zu erkennen.

Kernpunkte

  • Jeder CDN-Request erzeugt eine dreifache Abhängigkeit: Verfügbarkeit, Datenschutz und Lizenz des CDN-Betreibers.
  • Cache-Partitioning in modernen Browsern hat den Performance-Vorteil von CDNs eliminiert.
  • HTTP/2 mit Self-Hosting ist in den meisten Szenarien schneller als multiple CDN-Requests.
  • Der Großteil der CDN-Abhängigkeiten (Fonts, Icons, CSS, JS) lässt sich in einem Arbeitstag eliminieren.
  • Cloudflare, Fastly, AWS CloudFront – die großen CDN-Betreiber sind alle US-Unternehmen unter CLOUD Act.
  • Automatisierte Erkennung über DevTools, Lighthouse und CSP-Header macht CDN-Abhängigkeiten sichtbar.