Eine typische Website lädt bei jedem Seitenaufruf Ressourcen von externen Servern: Fonts von Google Fonts, Icons von einem CDN, Analytics-Skripte von einem US-Dienst, Komponentenbibliotheken von unpkg oder cdnjs. Jeder dieser Requests überträgt die IP-Adresse des Nutzers an einen Drittanbieter – oft in die USA. Seit dem Schrems-II-Urteil ist das ein konkretes Compliance-Problem.
Das DSGVO-Problem externer Requests
Das Urteil des LG München (Az. 3 O 17493/20, Januar 2022) stellte klar: Das Laden von Google Fonts über Google-Server ohne Einwilligung verstößt gegen die DSGVO. Der Grund: Bei jedem Seitenaufruf wird die IP-Adresse des Nutzers an Google in den USA übertragen – ein personenbezogenes Datum nach Art. 4 Nr. 1 DSGVO, für das keine Rechtsgrundlage besteht.
Das Urteil betrifft nicht nur Google Fonts. Jeder externe Request – CDN-gehostete Bibliotheken, Icon-Services, Analytics-Pixel – überträgt die IP-Adresse an einen Drittanbieter. Wer konsequent DSGVO-konform sein will, muss alle Frontend-Assets selbst hosten.
Was Self-Hosting bedeutet
Self-Hosting bedeutet: Alle Ressourcen, die eine Website zum Rendern braucht, werden vom eigenen Server ausgeliefert. Keine externen DNS-Lookups, keine Datenübertragung an Dritte, keine Abhängigkeit von der Verfügbarkeit externer Dienste.
Konkret betrifft das: Fonts (statt Google Fonts CDN → selbst gehostete WOFF2-Dateien), Icons (statt Font Awesome CDN → lokal eingebundene SVGs oder Icon-Fonts), CSS-Frameworks (statt CDN-gehostetes Tailwind → lokaler Build), JavaScript-Bibliotheken (statt unpkg/cdnjs → npm install + Bundle), Analytics (statt Google Analytics → Plausible Cloud EU oder Matomo Self-Hosted), Bilder (statt externe Image-CDNs → eigenes Image-Processing).
Performance-Vorteil
Entgegen der gängigen Annahme ist Self-Hosting oft schneller als CDN-basierte Lösungen. Der Grund: Seit HTTP/2 werden alle Ressourcen vom gleichen Server über eine einzige TCP-Verbindung ausgeliefert. Der Overhead für DNS-Lookup, TCP-Handshake und TLS-Negotiation für jeden externen Host entfällt.
Besonders bei Fonts ist der Unterschied messbar: Selbst gehostete Fonts können über <link rel="preload"> frühzeitig geladen werden. Das font-display: swap-Verhalten ist kontrollierbar. Es gibt keinen DNS-Lookup zu fonts.googleapis.com und keinen zweiten Request zu fonts.gstatic.com.
Self-Hosting-Checkliste
Font-Subsetting + Self-Hosting
Die Kombination von Font-Subsetting und Self-Hosting minimiert sowohl die Dateigröße als auch die Abhängigkeit. Ein vollständiger Font enthält oft 500+ Glyphen für Sprachen, die nie benötigt werden. Subsetting reduziert einen 120-KB-Font auf 15–25 KB für Latin-only mit deutschen Umlauten.
Tools wie glyphhanger oder subfont analysieren den tatsächlich verwendeten Zeichenumfang und erzeugen optimierte WOFF2-Dateien. Das Ergebnis: Schnellere Ladezeiten, kleinere Bundles, null externe Abhängigkeiten.
Kernpunkte
- Jeder externe Request überträgt die IP-Adresse des Nutzers an einen Drittanbieter – ein konkretes DSGVO-Problem.
- Self-Hosting eliminiert externe Abhängigkeiten und ist durch HTTP/2 oft schneller als CDN-basierte Lösungen.
- Fonts, Icons, CSS-Frameworks und JS-Libraries sind mit geringem Aufwand selbst hostbar.
- Die Kombination von Self-Hosting mit Font-Subsetting minimiert Dateigröße und Abhängigkeit gleichzeitig.
- Plausible Cloud (EU-hosted) und Matomo sind DSGVO-konforme Analytics-Alternativen.
- Konsequentes Self-Hosting ist ein Grundpfeiler digitaler Souveränität im Frontend.
