Sind Google Fonts wirklich noch ein DSGVO-Risiko 2026?

Ja, das LG-München-Urteil von Januar 2022 ist nicht aufgehoben worden. Die Abmahnwelle der Jahre 2022/2023 hat zwar nachgelassen, aber das rechtliche Grundproblem bleibt: Übermittlung der IP-Adresse an Google ohne Einwilligung verstößt gegen DSGVO. Wer rechtssicher arbeiten will, hostet selbst — oder bindet Google Fonts erst nach Cookie-Accept ein, was technisch fragiler ist als Self-Hosting.

Wie viel LCP-Verbesserung bringt Self-Hosting konkret?

Aus 8 Migrations-Audits: durchschnittlich 100–250 ms LCP-Verbesserung, in Spitzen bis 400 ms bei Sites mit mehreren Schriftfamilien und langsamer Server-Antwort. Das wirkt sich direkt auf Core-Web-Vitals aus, weil Schriften oft das LCP-Element rendern (Hero-Headline). Pro 100 ms LCP-Verbesserung sind nach Akamai-Studie ~7 Prozent Conversion-Lift möglich.

Was ist mit Adobe Fonts (Typekit)?

Adobe Fonts hat ähnliche DSGVO-Bedenken wie Google Fonts — Einbindung über use.typekit.net führt zu IP-Übermittlung an Adobe. Plus: Adobe Fonts können typisch nicht selbst gehostet werden, das verbietet die Lizenz. Wer Adobe-Fonts nutzt, braucht zwingend einen Cookie-Banner mit Adobe-Consent-Pfad. Workaround: Adobe-Font-Lizenz für Self-Hosting kaufen (separate Lizenz-Variante, teurer aber DSGVO-sauber).

Variable Fonts in allen Browsern unterstützt?

Ja, seit 2022/2023 in allen relevanten: Chrome, Edge, Firefox, Safari (auch iOS), Samsung Internet, Opera. caniuse.com listet 96+ Prozent globale Browser-Unterstützung 2026. Für ältere Browser (IE11, Safari < 10): Fallback auf Static Fonts via @supports-Block, aber das relevante Marketing-Site-Publikum ist 2026 zu 99 Prozent auf modernen Browsern.

Welche Variable Fonts sind kostenlos und gut?

Top-Picks für Marketing-Sites: Inter Variable (Body, geometrische Sans-Serif, technisch wirkend), Geist Variable (Body, sehr modern, Vercel-eigene Schrift), Fraunces Variable (Display, Serif mit weichen Zügen), Source Sans 3 Variable (Adobe-Open-Source), JetBrains Mono Variable (Code). Alle auf fontsource.org oder den Original-Quellen direkt verfügbar.

Wie groß darf eine Schriftfamilie maximal sein?

Performance-Budget-Faustregel: alle Schriftfamilien zusammen unter 100 kB. Eine Variable Font typisch 60–90 kB für Latin-Subset — also reicht das Budget für eine Body- plus eine Display-Variante. Mehr braucht eine Marketing-Site selten. Code-Mono-Schrift ist nur auf Code-Snippets nötig — wer keine Code-Blöcke hat, lässt sie weg.

Was tun, wenn der Designer eine spezielle Schrift will, die nicht selbst-hostbar ist?

Erste Frage: ist die kommerzielle Lizenz mit Web-Hosting-Recht erhältlich? Bei Pangram Pangram, Klim Type Foundry, Grilli Type usw. gibt es Web-Lizenz-Pakete für 100–500 € einmalig. Wenn nicht: Designer überzeugen, dass Performance-Effekt + DSGVO-Sauberkeit die Schriftwahl beeinflussen muss. Faustregel: alternative Schrift mit ähnlicher visueller Charakteristik findet sich immer.

Funktioniert Self-Hosting auch in WordPress?

Ja, mit Plugins wie OMGF (Optimize My Google Fonts) automatisch — sucht alle Google-Fonts-Referenzen, lädt die Files, hostet sie selbst, ändert die CSS-Referenzen. Manuell: WOFF2 in /wp-content/themes/ /fonts/ legen, im Theme-CSS @font-face-Regel definieren, Font-Familie in Theme-Customizer einbinden. Aufwand vergleichbar mit Next.js, nur weniger Tooling.

← Blog·Web Performance·19. August 2026·11 Min Lesezeit

Webfonts ohne CDN — Self-Hosting für DSGVO und Performance

Google Fonts via CDN ist 2026 doppelt problematisch: DSGVO-Risiko (LG-München-Urteil 2022 ist weiterhin Grundlage für Abmahnungen) und 100–300 ms LCP-Strafe pro Schriftfamilie. Self-Hosted Variable Fonts kosten zwei Stunden Setup, sparen Sekunden Ladezeit, sind DSGVO-konform ohne Cookie-Banner-Gymnastik. Wie das Setup mit `next/font/local` konkret aussieht — plus die fünf Fallstricke, die selbst erfahrene Devs treffen.

Von Andrea Otten·Geschäftsführerin · Tagleuchte

Warum CDN-Fonts ein doppeltes Problem sind

Wenn ein Browser eine Website lädt, die Google Fonts via fonts.googleapis.com einbindet, sendet er die IP-Adresse des Besuchers an Google. Das LG München hat 2022 festgestellt: das ist eine personenbezogene Datenübermittlung an einen US-Anbieter, die ohne explizite Einwilligung gegen DSGVO verstößt. Seitdem laufen Abmahnwellen, deren Risiko-Spitze 2024–2025 etwas abgekühlt ist, aber das Grund-Problem bleibt: ohne Einwilligung kein Google-Fonts-CDN, mit Einwilligung läuft die Schrift erst nach Cookie-Accept, was Layout-Shifts verursacht.

Performance-seitig ist die CDN-Variante 100–300 ms langsamer als Self-Hosting: zusätzlicher DNS-Lookup für fonts.googleapis.com, Cross-Origin-Connection-Setup, render-blockendes CSS-Stylesheet bevor die Font geladen wird, dann die Font-Datei selbst. Self-Hosted Fonts laden vom selben Origin wie HTML — keine zusätzlichen Netzwerk-Hops, plus Browser kann Preload-Hints setzen.

Self-Hosting löst beide Probleme in einem Setup. Aufwand: 2–4 Stunden für eine bestehende Site mit 1–3 Schriftfamilien. ROI: schneller LCP und keine DSGVO-Diskussion mehr.

Variable Fonts statt vier Static-Files

Variable Fonts sind seit 2018 standardisiert, seit 2022 in allen modernen Browsern unterstützt — und 2026 die einzige sinnvolle Wahl für Marketing-Sites. Eine Datei statt vier, kleinere Gesamt-Bytes, alle Weights und Styles in einem File.

Warum ein File statt vier

Klassisches Setup: Regular (400), Medium (500), Semibold (600), Bold (700) jeweils als separate WOFF2-Datei. Pro Datei ~25–40 kB, summiert 100–160 kB nur für eine Familie. Plus jeweils ein eigener HTTP-Request, Browser muss vier Connection-Slots aufmachen.

Variable Fonts speichern alle Achsen (Weight, Width, Slant, optische Größe) in einer einzigen Datei. Inter Variable z. B. ist 75 kB für alle Weights von 100 bis 900. Damit fallen drei Requests weg, Total-Bytes sinken um 30–50 Prozent, und Sie haben Zugang zu Zwischen-Weights (etwa 550 für eine Display-spezifische Optimierung).

Welche Variable Fonts sich für Marketing-Sites eignen

Open Source und Production-Ready: Inter Variable, Geist Variable, Fraunces Variable (Display), JetBrains Mono Variable (Code), Source Sans 3 Variable, Roboto Flex. Alle als Single-File-Variable-Variante auf rsms.me/inter, vercel.com/font/geist, fontsource.org verfügbar.

Kommerziell: PP Neue Montreal Variable, Migra Variable (Pangram Pangram), GT Walsheim Variable. Variable-Versionen kosten oft etwas mehr als das Static-Set, aber lohnen sich für Marketing-Sites mit hoher Performance-Priorität.

Setup mit next/font/local in 6 Schritten

Für Next.js-Projekte ist `next/font/local` das offizielle API. Wer auf einer anderen Plattform ist (WordPress, plain HTML), braucht die zugrundeliegende `@font-face`-CSS-Variante — die Logik bleibt identisch.

01
Variable Font herunterladen
Beispiel Inter Variable: rsms.me/inter → Latest Version → InterVariable.woff2 herunterladen (~75 kB). Ins Projekt unter `app/fonts/` oder `public/fonts/` kopieren. WOFF2 ist Pflicht, WOFF als Fallback nur für IE11-Support — den braucht 2026 niemand mehr, also weglassen.
02
next/font/local einrichten
In `app/fonts.ts` (oder direkt in `layout.tsx`): `import localFont from 'next/font/local'` und Variable mit `src`, `variable: '--font-body'`, `display: 'swap'`, `preload: true`. Next.js generiert automatisch Subset-Variants und CSS-Variablen, plus optimale Preload-Hints im HTML-Head.
03
CSS-Variable in Tailwind-Theme einbinden
In `globals.css` unter `@theme`: `--font-body: var(--font-body), system-ui, sans-serif;`. Tailwind v4 generiert daraus die `font-body`-Utility automatisch. Stack mit System-Fonts als Fallback verhindert Flash-of-Unstyled-Text während die Variable Font lädt.
04
Font-Variable im html-Tag setzen
In `app/layout.tsx`: `<html className={fontBody.variable}>`. next/font setzt die CSS-Variable auf alle Children, und Tailwind nutzt sie automatisch. Ein einziger Strich Code, keine separaten link-Tags im Head — Next handled das.
05
display: swap aktivieren
`display: 'swap'` ist Pflicht: Browser zeigt Fallback-Text sofort, swappt zur richtigen Schrift sobald sie geladen ist. Verhindert FOIT (Flash of Invisible Text), wo der Browser einen unsichtbaren Block zeigt bis die Font da ist. swap ist UX-besser als FOIT, auch wenn es einen sichtbaren Schrift-Wechsel gibt.
06
Critical Weights preloaden
Nur die zwei kritischsten Weights preloaden — Regular (400) für Body-Text, der Display-Weight (z. B. 600 oder 700) für H1/Hero. Mehr Preload-Hints konkurrieren um Connection-Slots und schaden mehr als sie nützen. Bei Variable Fonts ist Preload von einer Datei für alle Weights ausreichend.

Fünf Fallstricke beim Self-Hosting

Selbst erfahrene Devs treffen diese. Sortierung nach Häufigkeit der gemachten Fehler in unseren Audits.

01Cache-Header zu konservativ gesetzt — Self-Hosted Fonts sollten mit `Cache-Control: public, max-age=31536000, immutable` ausgeliefert werden — sie ändern sich nie. Default-Vercel-Cache für /public-Assets ist eher konservativ, das verhindert Browser-Caching über Site-Sessions hinweg. Vercel: in `next.config.ts` Headers für `/_next/static/media/*` setzen.
02Falscher Subset, doppelte Bytes — next/font/local hat einen `subset`-Parameter — bei deutscher Site reicht `latin`, optional `latin-ext` für Umlaute außerhalb DACH (Polnisch, Ungarisch). Wer subset weglässt, lädt oft Hindi und CJK-Glyphen mit, die nie genutzt werden. Bei Inter Variable: 75 kB latin, 200 kB+ all-subsets.
03Fallback-Font zu unterschiedlich — Wenn die Custom-Font lädt und der Fallback `Times New Roman` war, gibt es einen sichtbaren Layout-Shift wegen unterschiedlicher Glyphen-Breiten. next/font hat dafür `adjustFontFallback: true` (Default) — generiert einen exakten Metrics-angepassten Fallback. Wichtig für CLS unter 0,05.
04Zu viele Schrift-Familien gleichzeitig — Display + Body + Mono ist Standard, mehr ist Performance-Kosten ohne Design-Gewinn. Wer 4–5 Familien lädt, hat oft 250+ kB nur für Schriften — 25 Prozent eines aggressiven Performance-Budgets. Lösung: maximal drei Familien, alle Variable.
05Font-Display vergessen oder auf block gesetzt — `display: 'block'` (alter Default in einigen Frameworks) versteckt Text bis Font geladen ist — wirkt wie Site-Hänger. `display: 'optional'` ist eine Variante, die nur bei sehr schneller Verbindung swappt — meist zu strikt. `display: 'swap'` ist der Standard-Wert für Marketing-Sites mit guter UX.

Wie Sie den Effekt messen

Vorher/Nachher-Vergleich auf einer typischen Marketing-Site, gemittelt aus 8 Migrations-Audits 2024–2025. Werte sind Median, nicht Best-Case.

Metrik	Vorher (Google CDN)	Nachher (Self-Hosted Variable)
Total-Bytes Schriften	120–180 kB	60–90 kB
LCP-Beitrag	+150–300 ms	+50–120 ms
Anzahl HTTP-Requests Schriften	4–8	1–2
DNS-Lookups	+1 (fonts.googleapis.com)	0 zusätzlich
DSGVO-Risiko ohne Consent	Hoch	Keines
Cookie-Banner-Pflicht für Schriften	Ja	Nein
FOIT-Risiko	Hoch (display:block-Default)	Niedrig (display:swap)

Quellen & weiterführend

Häufige Fragen zu Web Performance

Sind Google Fonts wirklich noch ein DSGVO-Risiko 2026?
Ja, das LG-München-Urteil von Januar 2022 ist nicht aufgehoben worden. Die Abmahnwelle der Jahre 2022/2023 hat zwar nachgelassen, aber das rechtliche Grundproblem bleibt: Übermittlung der IP-Adresse an Google ohne Einwilligung verstößt gegen DSGVO. Wer rechtssicher arbeiten will, hostet selbst — oder bindet Google Fonts erst nach Cookie-Accept ein, was technisch fragiler ist als Self-Hosting.
Wie viel LCP-Verbesserung bringt Self-Hosting konkret?
Aus 8 Migrations-Audits: durchschnittlich 100–250 ms LCP-Verbesserung, in Spitzen bis 400 ms bei Sites mit mehreren Schriftfamilien und langsamer Server-Antwort. Das wirkt sich direkt auf Core-Web-Vitals aus, weil Schriften oft das LCP-Element rendern (Hero-Headline). Pro 100 ms LCP-Verbesserung sind nach Akamai-Studie ~7 Prozent Conversion-Lift möglich.
Was ist mit Adobe Fonts (Typekit)?
Adobe Fonts hat ähnliche DSGVO-Bedenken wie Google Fonts — Einbindung über use.typekit.net führt zu IP-Übermittlung an Adobe. Plus: Adobe Fonts können typisch nicht selbst gehostet werden, das verbietet die Lizenz. Wer Adobe-Fonts nutzt, braucht zwingend einen Cookie-Banner mit Adobe-Consent-Pfad. Workaround: Adobe-Font-Lizenz für Self-Hosting kaufen (separate Lizenz-Variante, teurer aber DSGVO-sauber).
Variable Fonts in allen Browsern unterstützt?
Ja, seit 2022/2023 in allen relevanten: Chrome, Edge, Firefox, Safari (auch iOS), Samsung Internet, Opera. caniuse.com listet 96+ Prozent globale Browser-Unterstützung 2026. Für ältere Browser (IE11, Safari < 10): Fallback auf Static Fonts via @supports-Block, aber das relevante Marketing-Site-Publikum ist 2026 zu 99 Prozent auf modernen Browsern.
Welche Variable Fonts sind kostenlos und gut?
Top-Picks für Marketing-Sites: Inter Variable (Body, geometrische Sans-Serif, technisch wirkend), Geist Variable (Body, sehr modern, Vercel-eigene Schrift), Fraunces Variable (Display, Serif mit weichen Zügen), Source Sans 3 Variable (Adobe-Open-Source), JetBrains Mono Variable (Code). Alle auf fontsource.org oder den Original-Quellen direkt verfügbar.
Wie groß darf eine Schriftfamilie maximal sein?
Performance-Budget-Faustregel: alle Schriftfamilien zusammen unter 100 kB. Eine Variable Font typisch 60–90 kB für Latin-Subset — also reicht das Budget für eine Body- plus eine Display-Variante. Mehr braucht eine Marketing-Site selten. Code-Mono-Schrift ist nur auf Code-Snippets nötig — wer keine Code-Blöcke hat, lässt sie weg.
Was tun, wenn der Designer eine spezielle Schrift will, die nicht selbst-hostbar ist?
Erste Frage: ist die kommerzielle Lizenz mit Web-Hosting-Recht erhältlich? Bei Pangram Pangram, Klim Type Foundry, Grilli Type usw. gibt es Web-Lizenz-Pakete für 100–500 € einmalig. Wenn nicht: Designer überzeugen, dass Performance-Effekt + DSGVO-Sauberkeit die Schriftwahl beeinflussen muss. Faustregel: alternative Schrift mit ähnlicher visueller Charakteristik findet sich immer.
Funktioniert Self-Hosting auch in WordPress?
Ja, mit Plugins wie OMGF (Optimize My Google Fonts) automatisch — sucht alle Google-Fonts-Referenzen, lädt die Files, hostet sie selbst, ändert die CSS-Referenzen. Manuell: WOFF2 in /wp-content/themes/<theme>/fonts/ legen, im Theme-CSS @font-face-Regel definieren, Font-Familie in Theme-Customizer einbinden. Aufwand vergleichbar mit Next.js, nur weniger Tooling.

Wir helfen bei Web Performance mit ehrlicher Einschätzung.

Schriftliche Einschätzung in zwei Werktagen — kostenlos, ohne Verkaufsgespräch.

Erstanalyse anfordernhallo@tagleuchte.de