Self-hosted Fonts mit next/font — der DSGVO-Fall gelöst

Würdigung — der Font-Fall, der viele Seiten betrifft#

Es klingt nach einer Lappalie: eine Schriftart. Aber die Art, wie eine Website ihre Schriften lädt, ist datenschutzrechtlich relevant. Der häufigste Fall: Eine Seite bindet Google Fonts auf die in unzähligen Anleitungen beschriebene Weise ein — über einen Link zu Googles Font-CDN. Bei jedem Seitenaufruf fordert der Browser des Besuchers die Schrift direkt von Google an. Dabei übermittelt er zwangsläufig seine IP-Adresse an einen US-Server — ohne dass der Besucher zugestimmt hätte und ohne dass die Schrift zwingend von dort kommen müsste.

Das LG München I hat am 20.01.2022 (Az. 3 O 17493/20) entschieden, dass genau diese dynamische Einbindung gegen das Datenschutzrecht verstößt, und einem Kläger Schadenersatz zugesprochen. Seitdem ist das ein bekanntes Abmahn-Thema. Für eine Steuerkanzlei, die Datenschutz nach außen ernst nimmt, ist eine über das Google-CDN geladene Schrift ein vermeidbarer Widerspruch — und oft kommt sie unbemerkt über ein Theme oder Plugin mit.

Was beim üblichen Einbinden passiert#

Die typische Einbindung sieht im Quelltext aus wie ein Verweis auf fonts.googleapis.com oder fonts.gstatic.com. Der Ablauf: Der Browser lädt die HTML-Seite, findet den Verweis, und stellt eine eigene Anfrage an den Google-Server, um die Schrift zu holen. In dieser Anfrage steckt die IP-Adresse des Besuchers — und damit ein personenbezogenes Datum, das ohne Rechtsgrundlage an einen Dritten in einem Drittland geht.

Das Problem ist nicht Google als Anbieter, sondern der dynamische Abruf zur Laufzeit. Solange die Schrift bei jedem Besuch von einem fremden Server geholt wird, entsteht der Datenabfluss. Die Lösung muss also genau diesen Abruf beseitigen.

Self-Hosting mit next/font — die Schrift wandert in den Build#

Die saubere Lösung ist, die Schrift nicht zur Laufzeit von Google zu holen, sondern sie zur Build-Zeit in die eigene Seite einzubetten. Genau das macht next/font. Beim Bauen der Seite werden die Schrift-Dateien heruntergeladen, optimiert und als Teil des eigenen Build-Artefakts ausgeliefert. Im fertigen Ergebnis kommt die Schrift von der eigenen Domain — der Browser des Besuchers stellt keine einzige Anfrage mehr an einen Google-Server. Damit fließt keine IP ab, und das Abmahn-Risiko ist strukturell beseitigt, nicht nur kaschiert.

Auf fahoch2.de nutzen wir die lokale Variante (next/font/local): Die Schrift-Dateien liegen im Projekt, werden zur Build-Zeit eingebettet und mit ausgeliefert. Das ist derselbe Mechanismus, der unsere cookielose Architektur trägt — kein Drittanbieter im Lade-Pfad, kein Banner nötig.

Ein angenehmer Nebeneffekt: Die Schrift kommt aus derselben Quelle wie der Rest der Seite, über dieselbe schon offene Verbindung. Das ist oft sogar schneller als der Umweg über ein fremdes CDN, für das der Browser erst eine neue Verbindung aufbauen müsste.

FOUT und FOIT — das Schrift-Flackern sauber lösen#

Beim Laden von Web-Schriften gibt es zwei sichtbare Effekte, die man kennen sollte:

• FOUT (Flash of Unstyled Text): Der Text erscheint zuerst in einer System-Schrift und springt dann auf die Web-Schrift um.
• FOIT (Flash of Invisible Text): Der Text bleibt unsichtbar, bis die Schrift geladen ist.

Gesteuert wird das über font-display. Der Wert swap zeigt sofort eine Ersatz-Schrift und tauscht sie aus, sobald die Web-Schrift da ist — der Text ist also nie unsichtbar. next/font setzt sinnvolle Defaults und kann die Größen-Unterschiede zwischen Ersatz- und Web-Schrift ausgleichen, sodass beim Umschalten möglichst wenig springt. Das ist nicht nur Kosmetik: Ein springendes Layout verschlechtert den CLS-Wert der Core Web Vitals und damit die Google-Bewertung. Self-Hosting plus sauberes font-display löst Datenschutz und Layout-Stabilität in einem Schritt.

Für eine vollständige Prüfung von Schriften, Drittanbieter-Abflüssen und der Konsistenz zur Datenschutzerklärung empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Google Fonts über das CDN sind ein konkretes, durch das LG München I bestätigtes Abmahn-Risiko, weil bei jedem Aufruf die Besucher-IP an einen Google-Server in den USA wandert. Der Ausweg ist Self-Hosting: Mit next/font wird die Schrift zur Build-Zeit eingebettet und kommt im fertigen Ergebnis von der eigenen Domain — kein Abruf bei Google, kein Datenabfluss, kein Banner nötig. Sauber gesetztes font-display verhindert dabei das Schrift-Flackern und stabilisiert das Layout (CLSCLS · zum GlossarCumulative Layout Shift — wie stark Inhalte beim Laden „springen“.). Das Tückische ist, dass die Google-Einbindung oft unbemerkt über ein Theme oder Plugin kommt — der erste Schritt ist deshalb, die eigene Seite überhaupt darauf zu prüfen.

Quellen#

• Next.js — Font Optimization (next/font) — abgerufen 2026-05-29
• LG München I, Urteil vom 20.01.2022 – 3 O 17493/20 (Google Fonts) — abgerufen 2026-05-29
• MDN — font-display — abgerufen 2026-05-29
• TDDDG § 25 — Schutz der Privatsphäre bei Endeinrichtungen — abgerufen 2026-05-29

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung — keine Rechtsberatung im Einzelfall. Die datenschutzrechtliche Bewertung einer konkreten Einbindung gehört in die anwaltliche Prüfung.