Das juristische Problem ist seit Jahren geklärt: Bindet eine Website Google Fonts über fonts.googleapis.com ein, überträgt der Browser bei jedem Seitenaufruf die IP-Adresse des Besuchers an Google — ohne Einwilligung, ohne Notwendigkeit. Das LG München I hat genau das 2022 als Rechtsverletzung eingestuft (Az. 3 O 17493/20) und einem Betroffenen Schadensersatz zugesprochen. Es folgte eine Abmahnwelle gegen zehntausende Website-Betreiber. Der Kern der Entscheidung gilt unabhängig vom Einzelfall weiter: Für die externe Einbindung gibt es keine technische Rechtfertigung, weil dieselben Schriften problemlos vom eigenen Server geladen werden können.
Der Performance-Mythos vom schnellen Google-CDN
Lange galt die externe Einbindung als Performance-Vorteil: Die Schrift liege ja „wahrscheinlich schon im Cache", weil andere Websites sie auch nutzen. Dieses Argument ist seit Jahren technisch tot — Browser partitionieren ihre Caches pro Website, ein bei anderer Gelegenheit geladener Font wird für Ihre Domain nicht wiederverwendet. Übrig bleiben nur die Kosten: DNS-Auflösung, TCP-Verbindung und TLS-Handshake zu zwei zusätzlichen Domains, bevor überhaupt ein Font-Byte fließt. Auf einer mobilen Verbindung sind das schnell 100 bis 300 Millisekunden — Zeit, in der Text unsichtbar bleibt oder springt und die direkt in Largest Contentful Paint und Layoutstabilität einzahlt. Lokal gehostete Fonts laufen dagegen über die bereits offene Verbindung, lassen sich per Preload priorisieren und beliebig lange cachen.
Die Umsetzung in vier Schritten
- Fonts besorgen: Die benötigten Schnitte als WOFF2 herunterladen — Werkzeuge wie der Google-Webfonts-Helper liefern Dateien und fertiges CSS in einem Schritt. WOFF2 genügt, ältere Formate braucht kein aktueller Browser
- Schnitte reduzieren: Jede Strichstärke ist eine eigene Datei. Regular, ein Semibold/Bold und allenfalls eine Kursive reichen fast immer — sechs geladene Gewichte sind ein Designfehler, kein Feature
- CSS umstellen: Eigene @font-face-Regeln mit font-display: swap anlegen, damit Text sofort in einer Ersatzschrift erscheint, und den kritischen Font per preload im Head anmelden
- Altlasten entfernen: Die externen Link- und Preconnect-Zeilen löschen und im Netzwerk-Tab prüfen, dass keine Anfrage mehr an fonts.googleapis.com oder fonts.gstatic.com rausgeht — Themes und Plugins schleppen solche Aufrufe gern durch die Hintertür ein
Der Zwei-Minuten-Selbsttest: Entwicklertools öffnen, Netzwerk-Tab, Seite neu laden, nach „fonts" filtern. Jede Zeile mit einer fremden Domain ist ein Datenabfluss und eine Verbindung zu viel. Dieser Test gehört in jeden Website-Audit — er findet auch die Fonts, die ein Page-Builder ungefragt nachlädt.
Subsetting und Variable Fonts: die Kür
Wer weiter optimieren will, setzt auf zwei Hebel. Subsetting entfernt alle Zeichen, die die Website nie braucht — Kyrillisch, Vietnamesisch, Sonderalphabete. Ein auf Latin reduzierter Font schrumpft oft um die Hälfte; für deutsche Websites ist das Subset „latin" plus „latin-ext" die sichere Wahl. Variable Fonts packen alle Strichstärken in eine einzige Datei: Statt vier Dateien für vier Gewichte lädt der Browser eine, die stufenlos von Light bis Black skaliert. Bei Schriftfamilien mit vielen genutzten Schnitten ist das netto fast immer kleiner — und Design-Feinheiten wie Zwischengewichte gibt es gratis dazu.
Auch an die anderen Dienste denken
Google Fonts ist der bekannteste Fall, aber nicht der einzige: Adobe Fonts (Typekit), Icon-Fonts von CDNs, extern geladene Skripte von Kartendiensten oder Video-Embeds folgen derselben Logik — jede Drittanbieter-Ressource, die vor der Einwilligung lädt, ist ein potenzielles Datenschutzproblem und eine zusätzliche Verbindung. Die Grundregel für schnelle und saubere Websites lautet deshalb: Alles, was zum Rendern der Seite nötig ist, kommt vom eigenen Server. Externe Dienste laden erst nach Einwilligung — oder gar nicht. Das Ergebnis ist eine Website, die schneller malt, weniger erklärt werden muss und keinen Anlass für unangenehme Post vom Anwalt bietet.